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 reads history — call logs and transcripts, AI call analyses, voicemails, recording audio — or needs a stable inventory of phone-system topology — phones, phone numbers, extensions, Call Assistants, call groups, and call menus — the version 1 operations cover it: see Use the customer API operations for the flow and the generated reference in this section for every parameter and response. Changing configuration on demand is not published yet. Talk to your Steer Phones contact about data you need beyond the published surface, 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.

The contract as a file

The published operations are also available as an OpenAPI 3.1 document: download the customer API contract. Point a client generator, a Postman or Insomnia import, or your own tooling at it.

It is the same reviewed contract the reference pages in this section are generated from, published in the same immutable documentation release, so the file and the pages can never describe different operations. Its single server is https://api.steerphones.com/v1, and it contains only approved operations — an operation absent from the reference is absent from the file. Regenerate your client when a release adds operations.

Authentication in brief

Approved operations authenticate with a secret API key sent in the X-API-Key request header. A key is issued for one grant target — a phone system, a group of phone systems, or an organization — and carries a fixed set of scopes, so a key issued for a reporting integration cannot change your call routing. Once a key is deployed, GET /v1/customer/phone-systems is the “does it work” call: it needs no scope and lists the phone systems the key covers. 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.
• Use the customer API operations.
• API versioning and errors.
• Receive events with webhooks.
• Review account activity and changes.