Migration guide

If you’re currently using another WhatsApp Cloud API provider, GoSendAPI is designed for drop-in compatibility. Most migrations take under 1 day with no application redesign.

What stays the same

GoSendAPI uses industry-standard conventions for the WhatsApp Cloud API integration layer:

Pattern	GoSendAPI	Most other Tech Providers
Message endpoint	`POST /messages`	Same
Phone identifier	`phone_number_id` (Meta’s ID)	Same
Recipient format	E164 without `+`	Same
Message payload structure	Mirror of Meta’s Cloud API shape	Same
Webhook event names	`whatsapp.message.received`, etc. (dotted naming)	Same convention
HMAC webhook signing	`X-Signature` header with `sha256=<hex>`	Similar (header name may differ)
Templates structure	`name` + `language` + `components`	Same (Meta-defined)
Conversations 24h rule	Enforced by Meta, not us	Same

Since the WhatsApp Cloud API itself is the underlying source of truth, most Tech Providers wrap it similarly. Migration is mostly swapping API URLs + key + signature header name.

What changes

Item	GoSendAPI
Base URL	`https://cloud.gosendapi.com/v1`
Auth header	`X-API-Key: gsk_live_...`
Webhook signature header	`X-GoSendAPI-Signature: sha256=<hex>`
Dashboard	`https://app.gosendapi.com`

That’s it. Three URLs/headers need updating in your code.

Migration checklist

Create an account at app.gosendapi.com/signup. Choose a project name (e.g. “MyApp Production”). You’ll get a sandbox API key for testing.

2. Onboard your existing WABA(s)

You have two paths:

Path A — Embedded Signup again (recommended if your customer is reachable):

Generate a Setup Link per customer
Customer clicks → re-authorizes (Meta supports multiple Tech Providers per WABA)
We provision the WABA + phones automatically

This takes ~5 min per customer and gets you a fresh access token via our system user.

Path B — Bring Your Own Token (if you can’t reach customers):

⚠️

You cannot unilaterally migrate a WABA without one of the above. Meta requires explicit customer authorization for each Tech Provider.

3. Update your code

Replace 3 things:

// BEFORE (other provider)
const PROVIDER_BASE = 'https://other-provider.com/v1';
const PROVIDER_KEY = process.env.OTHER_KEY;
const SIG_HEADER = 'X-Other-Signature';
 
// AFTER (GoSendAPI)
const PROVIDER_BASE = 'https://cloud.gosendapi.com/v1';
const PROVIDER_KEY = process.env.GOSENDAPI_KEY;
const SIG_HEADER = 'X-GoSendAPI-Signature';

The request/response payloads are identical (since both wrap Meta Cloud API). Your existing message-sending code keeps working.

4. Configure webhooks

Add a webhook in app.gosendapi.com → Webhooks:

URL: your existing webhook endpoint
Events: same events you were subscribed to before
Type: gosendapi_events (normalized payload, recommended)

If your endpoint currently verifies HMAC with X-Other-Signature, update to read X-GoSendAPI-Signature instead. The signing algorithm (HMAC-SHA256 of raw body) is the same.

5. Test in sandbox

Use your sandbox key first. Send a test message to a verified phone:

curl https://cloud.gosendapi.com/v1/messages \
  -H "X-API-Key: $GOSENDAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "phone_number_id": "...", "to": "...", "type": "text", "text": { "body": "Migration test" } }'

6. Cutover

Once everything works in sandbox, swap your prod env vars from the old provider’s key to your gsk_live_* key. Deploy. Done.

The old provider’s webhook will keep firing for ~24h until you remove it from Meta’s webhook config — that’s fine, both can coexist temporarily.

Webhook payload differences

If you used a provider with a custom payload shape, there may be small differences. The most common:

Inbound message event

{
- "event": "message_received",
+ "event": "whatsapp.message.received",
 
- "tenantId": "42",
+ "tenant_id": "42",
 
  "message": {
-   "messageId": "wamid....",
+   "id": "wamid....",
    "from": "...",
    ...
  }
}

Our payloads use snake_case (matches Meta’s Cloud API convention). If your code was reading camelCase, you’ll need a small adapter:

function adaptEvent(payload) {
  return {
    eventType: payload.event,
    tenantId: payload.tenant_id,
    phoneNumberId: payload.phone_number_id,
    messageId: payload.message?.id,
    // ... map other fields
  };
}

For most teams this is ~50 lines in one file.

Coexistence period

You can run both providers in parallel during migration:

Keep old provider sending for inbound message handling
Send NEW messages via GoSendAPI
After validating GoSendAPI handles everything correctly, deactivate the old provider’s webhook
Optionally, drop the old provider’s WABA token (after Meta admin step)

This avoids “big bang” deployment risks. We recommend at least 7 days of coexistence for production traffic.

Common questions

”Do I lose history?”

Yes — by default, your past messages stay with the old provider. We don’t have access to their DB. If you need to import history:

Option A: Export from old provider via their API, write to our messages table via a migration script
Option B: Keep history in your own DB (you should anyway — every send should be persisted on your side)

Most teams choose Option B.

”Will the user see anything?”

No. The phone number stays the same, the WABA stays the same. To the WhatsApp end-user, nothing changes.

”What about pending templates?”

Templates live on Meta’s side per WABA. They stay approved. You can sync them into GoSendAPI’s DB via POST /v1/wabas/{wabaId}/templates/sync — see Templates concept.

”Pricing comparison?”

We charge per connected phone number + message quota per phone. Final pricing tiers (Sandbox / Pro / Enterprise) being finalized post Meta App Review approval. Sandbox is free.

Email hello@gosendapi.com for a quote based on your volume.

Migration support

Open a ticket at hello@gosendapi.com with:

Your current provider name
Approximate number of WABAs / customers / msg volume
Webhook URL(s) currently in use

We’ll review and provide a tailored migration plan within 24h.

The one-click WABA onboarding flow

Setup Links

Wire up event delivery

Webhooks

Rate limits API Reference