AgenticCX exposes a separate, internal-only API surface called intra-api, for first-party Sestek services that need to talk directly to the platform. Today that means the AI Agent (Virtual Agent) that answers and handles calls; in the future it will include the telephony switchboard itself.
Why a Third Surface
AgenticCX already has two API layers: the internal application API used by the Agent Desktop and Admin screens (session-based, for logged-in users), and ext-api, published for customers integrating their own systems (see External API). intra-api is a third, separate trust boundary: only services Sestek itself operates can call it. The separation is not the URL path, it is the token's audience claim. A token issued for ext-api (audience AgenticCXExternal) is rejected here, and a token for intra-api (audience AgenticCXIntra) is rejected everywhere else.
This is not a customer-facing integration surface. It exists so AgenticCX's own AI Agent can read call context before a conversation starts and write back what it produced once the call ends, and so it can check queue availability before handing a call to a human agent.
Authentication
A client_credentials OAuth flow, audience AgenticCXIntra, role AiAgent. Each tenant is issued its own client id and secret; the tenant is resolved from the signed token itself, never from a header or query parameter.
POST /connect/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&client_id=<tenant's intra-api client id>
&client_secret=<secret>
&scope=AgenticCXIntra
Send the returned token as Authorization: Bearer <token> on every request.
Session API: Reading and Writing Call Context
GET intra-api/v1/session/{sessionId} and PATCH intra-api/v1/session/{sessionId} are addressed by the same identity: the SIP Call-ID header of the call itself, URL-encoded.
GET, called as a conversation starts, reads what the AI Agent needs: the wrap-up (closing) codes it may choose from, who the contact is, and a short summary of the conversation the call belongs to. Which pieces come back is controlled by an include parameter; the default set (wrapUpCodes, contactInfo, conversationShortInfo) is returned automatically, while a previously written note is opt-in only (?include=note), since reading it means an extra query.
PATCH, called after the conversation ends, writes back what the AI Agent produced: a wrap-up code and a free-text note. The response reports exactly what was applied and what was rejected and why, per field, independently, so a bad wrap-up code never blocks a valid note from being saved.
Queue API: Reading Handoff Capacity
GET intra-api/v1/queues returns every one of the tenant's queues along with how many agents assigned to that queue are, right now, logged in and in an Available state (not on a call, not in wrap-up, not offline). The AI Agent calls this immediately before handing a conversation over to a human agent, to decide which queue to hand off to.
Who This Is For
intra-api is documented here for completeness, since it is a real, versioned part of the platform's API surface, not because it is something a customer integrates against directly. If a project ever needs a first-party service other than the AI Agent to talk to AgenticCX this way, this is the pattern it follows.