Migrate in two lines.

The whole migration

Two lines, and nothing else changes. The version segment is yours: we validate it and forward it verbatim, so a client pinned to an older Graph version keeps working.

// the entire migration
- POST https://graph.facebook.com/v26.0/{phone_number_id}/messages
+ POST https://api.cosend.app/v26.0/{phone_number_id}/messages

- Authorization: Bearer EAAG…      // Meta system-user token
+ Authorization: Bearer csk_live_…  // Cosend connection key

The request body is forwarded byte for byte and Meta's response comes back byte for byte, including its status code and its error envelope. One thing is added on the way through: appsecret_proof is computed server-side, so you get a security control you would otherwise have to build, and our app secret never leaves our side.

What we proxy

An allowlist, never a denylist — otherwise every Graph endpoint Meta ships next month is exposed by default, including the ones that mutate account structure. An unlisted path returns a 404 in Meta's own envelope shape.

What we refuse, and why

Three refusals are worth naming individually, because each one exists to stop a key destroying the connection it is calling through:

POST /{WABA}/subscribed_apps

A single call would unsubscribe Cosend from your own webhooks. Every automation, every inbox update and every delivery receipt stops — silently, with no error anywhere, and neither of us knows why. Cosend owns this subscription.

POST /{PNID}/deregister

Meta forbids it on a connected coexistence number, and on a Cloud API number it destroys the connection we are holding open. Disconnecting is a first-class operation on our own API instead.

POST /{PNID}/smb_app_data

This is the coexistence history sync, and it is one-shot with a 24-hour deadline. Firing it by hand burns your only history import. Cosend owns the timing.

Path validation is the other half of it. A Graph request names its target by the phone-number ID in the path — and that segment never selects a connection. The key already identifies one, and the path is checked against it. A mismatch returns 404, not 403, because a 403 would confirm that somebody else's phone-number ID exists.

Not proxied yet — with the reason

These are real WhatsApp endpoints a passthrough could carry. They are excluded with a stated reason rather than silently omitted:

Flows

A Flow is a stateful UI artefact with its own versioning and encryption. Proxying its creation would give you a Flow whose lifecycle we do not track and whose responses arrive on a webhook we have no model for.

Calling

Calls are on Meta’s coexistence exclusion list, so this would be a feature that silently does nothing for most of our customers.

Groups

Meta’s general-availability announcement and the coexistence exclusion list contradict each other. An endpoint whose availability we cannot state is worse than not having it.

Product catalog and commerce

Also on the coexistence exclusion list. Your catalog keeps working in the WhatsApp Business app; the API cannot drive it.

Marketing Messages

Some accounts already route marketing sends down a different path, and fail with a specific Meta error when they do not. Our own send endpoint abstracts that, so this becomes a routing decision rather than a second public surface.

Payments

Regional, regulated and moving. Money endpoints are the last thing to proxy blindly.

A send, end to end

The same request you are sending today, against a different host. Nothing in the body changes.

curl -X POST https://api.cosend.app/v26.0/106540352242922/messages \
  -H "Authorization: Bearer csk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "messaging_product": "whatsapp",
    "to": "+5511999482222",
    "type": "text",
    "text": { "body": "On our way — 10 minutes." }
  }'

{
  "messaging_product": "whatsapp",
  "contacts": [{ "wa_id": "5511999482222" }],
  "messages": [{ "id": "wamid.HBgLNTUxMTk5NDgyMjIVAgARGBI3" }]
}

Timeouts are 30 seconds to Meta, and a POST /messages that times out is never retried. A duplicate WhatsApp message to a real person is worse than an error.

What the proxy fills in while you use it

Every proxied send is recorded afterwards, asynchronously, and never on the critical path: a message row, the contact, the conversation. So a week after pointing a hostname at us, there is a working shared inbox, a contact list and a spend breakdown that nobody built.

If the recording fails, your send still succeeded. It happened at Meta and you got Meta's response; our bookkeeping is not your problem.