When a DripTell workspace has more than one WhatsApp number, choose the sender from the connections authorised for that API key. Call GET /api/v1/whatsapp/connections, map the intended number to its immutable uuid, and pass that value as connection_uuid when sending. If the field is omitted, DripTell uses the workspace default. If an explicit UUID is invalid or unauthorised, the request is rejected rather than silently using another number.
The safe design is discover first, map once, send explicitly and stop when the mapping is no longer valid. The public DripTell developer reference documents this live behaviour.
Start with the sender decision
Do not begin by copying a phone number into application code. Define which business context owns the message: for example, the Dubai reservations team, the service department or the Spanish-language support line. Then decide whether that workflow may use the workspace default or must use one named connection.
The default suits one stable sender. Explicit selection is safer when several workflows share a key or a customer should recognise a particular branch. Authorization still belongs to the API key.
Discover what this API key may use
Request the connection list during setup and at controlled refresh points. The response contains authorised connections and immutable UUIDs. It omits provider access tokens and Meta phone-number IDs, so your integration does not need those secrets to choose a sender.
- 1DiscoverList the connections this key may use.
- 2MapStore the intended immutable connection UUID.
- 3SendPass the UUID when sender identity matters.
- 4RejectStop if the authorised sender is unavailable.
A key initially sees only the workspace default connection. A workspace owner can grant additional numbers under Settings → API keys. If the intended number is missing, ask the owner to review the key rather than borrowing another credential. See DripTell security for the broader access model.
Choose the UUID, not a position
Store a mapping between your durable business label and the returned uuid. Do not choose “the first connection”, depend on display order or match a formatted number for every send. Lists can change; an immutable identifier remains the stable selection.
| Workflow condition | Sender choice | Safe application behaviour |
|---|---|---|
| One approved sender and default is intentional | Omit connection_uuid | Log that the default was chosen deliberately |
| Branch or brand must control identity | Pass its mapped UUID | Send only after it matches the authorised list |
| Requested UUID is absent | Do not substitute | Stop and send the item to operational review |
| Owner changes API-key access | Refresh the mapping | Re-test before resuming production sends |
Default or explicit sender
Omitting connection_uuid selects the workspace default. This is compatibility, not routing intelligence: DripTell does not infer the branch from a booking, order or lead.
An explicit UUID makes the choice auditable. An invalid or unauthorised sender is rejected without fallback. Treat that as protection; a quiet fallback could send the correct message from the wrong brand or service line.
Build a safe sender mapping
Compare the authorised list with the small set of mappings your application expects. Mark missing or duplicate labels as configuration errors, and cache the result only for a defined period because permissions can change.
Validate the trusted workflow context before each send. A free-text customer field should not choose a sender. Record the business label, connection UUID and request result in protected logs without copying message content unnecessarily. The conversation can still reach the shared inbox and CRM context according to workspace setup.
Run an acceptance test
Use test recipients who expect the messages. Confirm that the list contains only intended numbers, then send once with each approved UUID. Test the default path only if production will use it.
In a non-production check, remove a test number's access or use a deliberately invalid UUID. Confirm that the request fails and no message leaves another number. Verify the visible sender, ownership and error handling. Repeat after permission, branch or number changes.
Keep permission separate
Selecting the correct sender does not create permission to contact someone. Apply the WhatsApp Business Messaging Policy and respect stop requests. Sender choice, consent, template eligibility and the active service window are separate decisions.
For multi-number availability or commercial limits, check DripTell pricing and your workspace rather than assuming every account has the same setup. Bring one real workflow to a technical walkthrough and verify the key, mapping and failure path before production traffic.
Frequently Asked Questions
How does the DripTell API list WhatsApp senders
Call GET /api/v1/whatsapp/connections with the API key. It returns only the connections that key is authorised to use.
What happens if I omit the sender UUID
DripTell uses the workspace default WhatsApp connection. Use that path only when the default is intentional.
Can an API key use every workspace number
Not automatically. It initially sees the default connection; a workspace owner must explicitly grant additional connections.
Does DripTell expose provider access tokens
No. The connection list omits provider access tokens and Meta phone-number IDs. Use the DripTell connection UUID for sender selection.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy
