Act as a client

Your reseller key acts on your own account by default. To act on one of your clients, add user_id naming that client. The call then runs on the client's account, with the client's agents, numbers, balance, and concurrency.

This is how you manage everything for a client without issuing it a key: create and edit its agents, run its campaigns, read its call logs, manage its knowledge base and integrations, import and attach its numbers, and dispatch its calls.

GET  /api/v1/agents?user_id=CLIENT_ID
POST /api/v1/calls/dispatch        { "user_id": CLIENT_ID, "agent_id": 42, "phone_number": "+15551234567" }
GET  /api/v1/calls/logs?user_id=CLIENT_ID

Where to put it

• user_id is a query parameter on GET and DELETE.
• It is a JSON body field on POST, PUT, and PATCH.

It is optional on every call that accepts it. Leave it out and the call acts on your own account, exactly as before.

What counts as "the caller"

These all mean your own account, so nothing changes for an existing integration:

• user_id left out.
• user_id as null, an empty string, 0, or false.
• user_id equal to your own user id.

Any other value that is not a client id is a 400.

What you cannot do

• A key that is not a reseller's cannot name another user. It gets a 403.
• A user that is not one of your direct clients, a staff user, an inactive user, or a user in another tenant gets a 404. All of these return the same answer, so no one can probe for other tenants' users.
• A client that is blocked or expired gets a 403. Restore it first, or act on it after the expiry.

Which calls accept it

Any call that acts on an account's data takes user_id: agents and their versions, calls and call logs, sessions, bulk campaigns, the knowledge base, integrations, number import and attach, phone number search, purchase, and release, and the KYC and credit calls. Each operation page in the API reference lists the parameter when it applies.