You built the agent. This is the part underneath it.
Numbers, carrier routes, branded caller ID, recordings, SMS and per-tenant isolation: the telephony and trust layer a voice-AI product needs, over one API. Access is invite-based while the program is small.
- Surface
- 39 endpoints, v1
- Auth
- bearer key, 3 scopes
- Rate limit
- 100 req/min per key
- Concurrency
- 10 live calls / account
- Access
- by request
- Number provisioning
- Outbound dial
- Branded caller ID
- SMS
- Sub-entity isolation
- Usage metering
What you get a key to
- 39Endpoints on the v1 APINumbers, calls, SMS, caller trust
- 3Key scopesUser, organization, sub-entity
- 0Carrier contracts you signRoutes and registrations are ours
- 1Bill, whatever you buildMetered per minute and per message
The six months you don't spend
None of this is the interesting part of your product, and all of it is the part that decides whether your calls connect.
- Building it yourselfOne API call
- NumbersA carrier account, a compliance packet, and a porting process per marketSearch, buy, configure and release numbers programmatically
- ReputationYour outbound gets flagged and you find out from a customerCaller-ID registration, CNAM status and reputation checks as endpoints
- Placing a callSIP, media, retries and hangup semantics you now own foreverOne dial call, with recording and status readable from the same resource
- Multi-tenantHomegrown scoping that leaks across customers the first time it's rushedSub-entities with server-side isolation and per-tenant keys you can revoke
- MessagingA second vendor, a second registration, a second set of rulesSMS on the same number and the same key as the voice leg
- MeteringReconciling three invoices to bill one customerUsage pulled per account or per number, on demand
How access works
The program is deliberately small right now, so keys are issued by hand and each build gets a look before it goes live.
Read the API reference →- 01
Request access
Tell us what you're building and roughly what volume looks like. There's no self-serve key for the API yet; a person reads every request.
- 02
Get scoped keys
Keys are issued at user, organization or sub-entity scope. Vendor-managed or per-customer workspaces get their own key that revokes on its own.
- 03
Provision and register
Search and buy numbers, register the caller ID your product will display, and check CNAM state, all before your first outbound call.
- 04
Ship inside the limits
100 requests per minute per key and 10 concurrent calls per account are the published ceilings. Talk to us before you plan a launch that needs more.
What the API actually covers
The same surface the dashboard runs on. Nothing here is a preview shim around a product we haven't shipped.
Numbers
Search inventory, buy, patch configuration, read CNAM status and release. The number is a resource with a lifecycle rather than a support ticket.
Calls
Place an outbound call, read its state, pull the dual-channel recording, or hang it up. Your agent stays your agent; we carry the leg.
Caller trust
Brand registration, enterprise records with LOA generation and signing, plus reputation lookups per number, so your calls arrive labelled correctly.
SMS
Send from the same numbers the voice agent calls from, so a conversation that starts on a call can continue as a message.
Sub-entities
Create isolated workspaces per customer with their own numbers, calls and keys. Isolation is enforced server-side on every endpoint, not in your query layer.
Usage and accounts
Read usage per account or per number to meter your own customers, and inspect the account and identity behind a key.
The terms of the layer
Your stack stays yours
Bring whatever model, orchestration and prompt layer you already run. This is telephony and trust infrastructure, not an agent framework you have to adopt.
Isolation is server-side
A sub-entity key cannot read across to a sibling workspace or up to the parent's private resources. The check lives on the endpoint, not in the caller.
Limits are published, not discovered
Rate and concurrency ceilings are documented, and keys are hashed at rest. If a launch needs headroom, that's a conversation before it, not an incident during it.
Asked before signing
01Why is access invite-based?
Because outbound reputation is shared infrastructure. A single badly-configured caller ID on our routes affects delivery for everyone on them, so every build gets read before it gets a key.
Tell us the use case and the shape of the volume. The review is about how the numbers will be used, not about how big you are.
02Can I use my own model and orchestration?
Yes. The API is the telephony and trust layer: numbers, routes, caller identity, recordings, messaging and tenancy. What speaks on the call is entirely your side.
Teams that want the whole agent instead can use the platform product; the two share the same account and the same bill.
03How do I keep my customers separated?
Provision a sub-entity per customer and issue that customer a sub-entity-scoped key. It sees only its own numbers, calls and contacts, and revoking it touches nothing else.
Caller-trust reads walk up to the parent registration, so a sub-entity inherits brand standing without inheriting access.
04What are the real limits?
100 requests per minute per API key, and 10 concurrent calls per account. Those are the documented ceilings today and they apply to every key in the program.
If your launch needs more concurrency, raise it with us first; it's a capacity and reputation question, not a plan toggle.
05What does it cost to build against?
Usage is metered per minute and per message on the same rates as the rest of the platform, and you can read usage back per account or per number to bill your own customers on top.
There is no separate API licence; the key is the same account, scoped.
Tell us what you're building
Send the use case and the rough volume and we'll scope keys, numbers and caller-ID registration on the call. Read the reference first if you'd rather see the surface before you talk to anyone.