Customer API overview

Understand what the Steer Phones customer API offers today, how operations are approved for publication, and how to get started.

The Steer Phones customer API lets an integration read and change one phone system’s data over HTTPS with a secret API key instead of a signed-in browser session. It is the same platform the Steer Phones dashboard runs on, exposed through a deliberately smaller, reviewed contract: an operation reaches customers only after it has been approved for publication, and every approved operation is reachable with a key scope Steer Phones can actually issue.

Two things are worth settling before you plan an integration. First, what is available to build against right now. Second, how anything new arrives — because the answer to “can my integration call this?” is decided by the published reference, not by what the dashboard happens to do.

What is available today

If your integration only needs to react to calls and voicemail as they happen — a screen pop, a CRM activity record, a follow-up task — webhooks cover that today and need no API key at all. See Receive events with webhooks.

If your integration needs to read history or change configuration on demand, that depends on published operations. Talk to your Steer Phones contact about the specific data you need, so the operation you depend on is part of the review that publishes it.

How an operation becomes available

Publication is a two-part gate, and both parts are required:

1. The operation is marked for customers in the service that implements it, with a stable operation identifier that will not change once published.
2. That identifier is listed in a reviewed approval record naming the reviewer, the approval date, and the lifecycle stage — stable, beta, or deprecated.

Only operations that pass both checks appear in the customer reference. Each one must also carry a summary, a description, documented success and error responses, and a request example, and must be reachable with a scope that can be granted to a customer key. An operation that exists in the platform but fails any of these is deliberately absent, not merely undocumented — treat its absence as “not part of the contract”, and do not call a path you discovered another way.

Base URL and version

The production base URL is https://api.steerphones.com/v1. The major version is part of the URL.

Version 1 can receive additive changes — new operations, and new fields on existing responses — so build a client that ignores response fields it does not recognize. A change that would break an existing client requires a new major version in the URL, published alongside migration guidance. See API versioning and errors.

Authentication in brief

Approved operations authenticate with a secret API key sent in the X-API-Key request header. A key belongs to exactly one phone system and carries a fixed set of scopes, so a key issued for a reporting integration cannot change your call routing. Full detail, including how keys are requested and rotated, is in Customer API authentication.

Keys are issued by Steer Phones rather than self-served from the dashboard. There is no page in the dashboard that mints an API key, and any tool or message that asks you to paste an existing key into a web form is not part of Steer Phones.

How this documentation behaves

This site never executes a request against your phone system. There is no built-in “try it” console, no request proxy, and no field that collects a credential. Examples use placeholders such as sk_phones_… and a sample phone-system identifier, and you fill them in locally.

That is a deliberate boundary: a documentation page that accepts a live secret becomes a place secrets leak. Keep keys in your own secret store and send them only to https://api.steerphones.com.

Related guidance

• Customer API authentication.
• API versioning and errors.
• Receive events with webhooks.
• Review account activity and changes.