The identities this workspace can send from, on any channel
One list of everything an outbound conversation can leave from: WhatsApp numbers, SMS numbers, outbound caller IDs and email addresses. Every entry has the same shape — only identifier changes meaning (a phone number, or an email address).
When to use it. Before starting a new outbound conversation, so the operator chooses what the customer sees. A workspace usually owns several numbers, they need not belong to the same WhatsApp Business Account, and contacting somebody from a number they have never seen — while an open thread sits on another one — is how outbound goes wrong.
What to send with. agent_uuid is the send identity for whatsapp, sms and call: it is what POST /whatsapp/template takes as agentId, and what GET /whatsapp/templates?agent_uuid= narrows the catalogue by. Email is the exception — there the send identity is the mailbox itself, so pass endpoint_uuid as from to POST /email/messages. Both fields are always present, so a caller can hold one field per channel without special-casing the rest of the object.
Why WhatsApp needs the number chosen first. Templates are approved per WABA. Picking the number and then listing templates for that same agent_uuid is what stops a send being rejected by Meta after the operator has already written the message.
sendable. True when the sender can actually originate: it is bound to an agent, has what the provider needs (a Meta phone number id, a number, an address), and is not in a state that blocks sending. A receive-only endpoint comes back sendable: false with agent_uuid: null — show it disabled rather than hiding it, so the gap stays visible to whoever administers the workspace. Statuses we do not recognise count as sendable, so an unfamiliar provider value never hides a working sender.
Channels covered. whatsapp, sms, call, email. Facebook and Instagram are deliberately absent — the sender there is a page identity, not something an operator picks.
Who can call it, and how much of it they see. A workspace API token, or a per-user JWT holding loop.templates.send. A workspace token — and an admin or the workspace owner on a JWT — gets every sender. Any other per-user JWT gets only the senders routed to an ACTIVE queue that user is a member of: the same membership rule the inbox reads by, so an operator is never offered a number whose replies would land in somebody else’s queue. A sender routed to no queue at all is workspace/admin-only, exactly like an unassigned conversation.
Authorizations
Use a Bearer token to access these API endpoints. Example: "Bearer {your-token}"
Query Parameters
Restrict to one channel. Omit for every channel at once.
whatsapp, sms, call, email Only senders that can originate a message
Only senders routed to this queue
identifier collapses the list to one row per address. Use it when the picker is about the number the customer sees rather than which agent sends — on voice a caller ID can be bound to several agents. The surviving row is chosen by a fixed rule (sendable first, then the agent the queue designer routes that endpoint to, then the oldest binding), so the same address always resolves to the same agent_uuid. Collapsed rows carry an agents array listing everyone bound to that address.
identifier