Moving to SambungAPI from another WhatsApp provider

SambungAPI never owns your WhatsApp Business Account and never runs the move for you: you hold the Meta assets, you decide when your source provider leaves the number, and this guide tells you what to do on each side of the boundary.

The facts about Meta below come from Meta's own documentation. The facts about each provider come from that provider's public pages, and every provider block says the date its pages were read.

Has Meta moved your business yet

Meta moves businesses to its new account model in stages, from September 23, 2026 to mid-October 2026. To check, open your business settings in Meta Business Suite. A business that Meta has moved shows two tabs, WhatsApp Accounts and Messaging Accounts, where it showed one.

If you see one tab, Meta has not moved your business yet, and Meta does not yet let a second provider onto your number. Wait for Meta's move, then follow this guide. Do not start a number migration in the meantime: Meta ends that path for every business that it moves.

What moves and what does not

Six things a reader always asks about. Each row is what Meta and the source provider's own documentation establish, and nothing more. A Warta key is the credential your software uses to send WhatsApp messages through SambungAPI. It belongs to your organization, it can be limited to one business phone number, and SambungAPI shows it only once.

What	What actually happens
Number identity	Nothing moves. The number stays in your own Meta business portfolio, with its display name, phone quality rating, messaging limit and Official Business Account status. While your source provider and SambungAPI are both on the number, they share its throughput and its messaging limit.
Message templates	None come across. Meta keeps each template in the account where it was made, so the WhatsApp Business Account that Meta gives SambungAPI starts with none. Create each one again here and submit it for approval.
Inbox and history	None. Export from your source provider before you remove it. Chats starts at the first message that reaches SambungAPI.
Credentials	No swap. Mint a Warta key. Your source provider's key, app secret, and channel id are inputs to nothing.
Webhooks	You can keep your URL. You rewrite the handler: the envelope, the signature header, and the event names are SambungAPI's. Nothing the source provider received is replayed here.
Billing	Meta bills each message to the WhatsApp Business Account of the provider that sends it, before and after the move. The account that Meta gives SambungAPI needs your own payment method before it can begin messaging. Your source provider's subscription, balance and invoices are settled with that provider, separately.

One Meta rule is worth knowing before you plan the move. Any provider on your number can deregister it, and a deregistered number stops sending through every provider on it, SambungAPI included. Remove your source provider's access yourself, in step 6, and do not ask it to deregister the number.

Meta says that a share does not interrupt your conversations. This page prints no estimate of how long a move takes. Providers publish their own; they are that provider's operating observation about its own product, never a Meta guarantee and never a promise from here.

Before you start, prove the journey once

Do the whole journey on Meta's test account first, so that the first real send after the move is not the first send you have ever made through SambungAPI.

Send a first WhatsApp message walks a test WhatsApp Business Account from your own Meta app to a reply arriving, signed, at an endpoint you control. It uses the same instruments step 5 below uses: a Warta key, one gateway send, a subscription, and a signed delivery. Nothing in it touches your production number, and the account it uses is free of the checks a real one must pass.

When you have done that once, every instrument in step 5 is something you have already seen work, and a failure after the move is a fact about the move rather than about your code.

Step 1 — Inventory before you touch anything

Write down the business phone number, its Meta phone number id, your Meta business portfolio id, the display name, the phone quality rating, the Official Business Account status, the messaging limit, and every message template with its name, language, category, components, status and quality. The templates are the list you create again in step 3, and the rest is the set you check again in step 5.

Then export what your source provider will let you export: conversations, media, contacts, template definitions, webhook logs and billing records. Do this before you remove anything. Providers delete on retention schedules, some document export and no import at all, and Meta states plainly that historical webhook payloads cannot be fetched later.

What you do in SambungAPI: nothing yet. SambungAPI holds no row for an account it has never connected, so every field above is read from Meta and from your source provider's product.

Step 2 — Connect the same number

Open Business accounts (/app/business-accounts), select Connect a WhatsApp Business Account, then Connect with Meta. In Meta's window, enter or pick your number and select your business portfolio, in the order that Meta asks for them. Do not add it as a new number, and do not disconnect it from your source provider.

Meta then gives SambungAPI its own WhatsApp Business Account on your number (Meta calls it a Messaging account), and your source provider keeps its own. The number does not move. Meta documents this path, and SambungAPI has not yet connected a number that another provider serves.

If Meta's window asks you to disconnect or deregister your number, do not do it: a deregistered number stops sending through your source provider too. Close the window, and on Signup not finished select Use Meta's standard signup. If Meta refuses the number there too, contact us with Meta's words.

If your number is also in the WhatsApp Business app. Some providers serve a number that stays in the WhatsApp Business app, which Meta calls coexistence. Meta's window then enters its coexistence flow, and Meta's documentation says that this flow refuses a number that already has a partner: it asks you to disconnect the current partner in the WhatsApp Business app first, and to connect the new one after that. That disconnect stops your source provider at once, and nothing reaches SambungAPI until the new connection is complete, so do step 1 first and choose a quiet moment. Do not select Use Meta's standard signup for this number, and never delete the WhatsApp Business app account to connect it: its chat history is lost.

What you do in SambungAPI: this step is the connect. The completion card registers the number for Meta's WhatsApp Cloud API, and Meta accepts the registration of a number that is already registered. SambungAPI subscribes the account to Meta's webhooks itself. If the completion card says that Meta asks for this number's PIN, enter the PIN that the number has; if your source provider set it, ask your source provider for it. Set a new PIN gives the number a PIN that nobody keeps, SambungAPI included, and the PIN that you or your source provider holds stops working.

Step 3 — Add a payment method and create your templates

In Meta Business Suite, open Messaging Accounts, select the account that Meta made for SambungAPI, and add a payment method. Meta does not let that account begin messaging until it has one.

Then create each message template from your step 1 list again, and submit it for approval. Meta's Template Migration API can copy approved templates between two accounts that your own business owns. On Templates, Copy templates from another account asks Meta for that copy, and shows what Meta copied and what it did not. SambungAPI has not yet seen Meta copy from a source provider's account into the account that Meta made for SambungAPI. If Meta refuses, create each template again. A copied template's quality rating starts again from Meta's baseline.

What you do in SambungAPI: create each template on Templates (/app/templates) with New template, or with POST /v1/messaging/wabas/{waba_id}/templates. To ask Meta for the copy over the API, send POST /v1/messaging/wabas/{waba_id}/templates/copy with the Meta id of the source account as source_meta_waba_id. A template that you copy with Meta's API outside SambungAPI appears here after the account-level pull:

curl -sS -X POST \
  "https://sabi.metatech.id/v1/messaging/wabas/wb_xxxxxxxx/templates/sync" \
  -H "Authorization: Bearer cpt_xxxxxxxxxxxxxxxx"

It answers with what it found: how many templates Meta reported, how many rows were created, updated, unchanged or skipped, and how many pages it read. The console does the same from Get templates from Meta on the Templates page. It is explicit rather than automatic, because each page of that read spends the account's Meta budget.

Step 4 — Rebuild on SambungAPI

Everything provider-local is built again here. The old bearer token, per-number API key, app id and secret, channel id, signing secret, and the wrapper the old provider put around Meta's events are not migration artifacts; they are inputs to nothing.

What you do in SambungAPI:

• Mint a Warta key at whole-organization scope, on the connected account. Over the API the same mint is POST /v1/messaging/wabas/{waba_id}/keys. Scope sets what the key's subscription receives: a key at whole-organization scope registers a subscription for every business phone number of the organization, and a key scoped to one business phone number registers a subscription that is narrowed to its own number.
• Register your endpoint with POST /v1/messaging/subscriptions. The 201 carries a whsec_… signing secret shown exactly once. Deliveries are signed with X-Sambungapi-Signature-256, an HMAC-SHA256 over the raw body bytes, and carry the event id as Idempotency-Key. That signature has the same shape as Meta's own X-Hub-Signature-256, so whatever already verifies Meta's webhook verifies this one.

Step 5 — Send your messages to SambungAPI, and validate

Open Conversation Routing in Meta Business Suite. When more than one provider is on a number, Meta uses it to choose which provider gets each incoming message, and connecting SambungAPI can create its first configuration. That first configuration keeps your source provider as the receiver: Meta does not let a new provider replace the current one by itself.

• If you see a configuration, make SambungAPI the primary for the four messaging settings under Message routing: Service, Click to WhatsApp, Utility Response and Marketing Message Response. Leave Incoming Call as it is: it routes WhatsApp calls, and SambungAPI does not handle them. The change reaches each conversation in turn. A conversation that your source provider already holds stays with it until 24 hours pass with no message from the person who wrote, and only then does Meta give it to SambungAPI.
• If you see none, Meta sends every incoming message to both providers. Turn off your source provider's automatic replies, so that nobody gets two answers.

Then validate. Do not remove anything until the new path has been observed working end to end. Meta accepting your share is not evidence that a message reached somebody.

What you do in SambungAPI: the same four instruments the try path proves, now against the real number.

1. One gateway send. POST /v1/messaging/gateway/{phone_number_id}/messages with the Warta key. Send a template: while your source provider holds a conversation, Meta refuses any other message to it from SambungAPI. The gateway is a forwarder: your body reaches Meta unchanged and Meta's status and body come back unchanged. A 200 is acceptance, not delivery.
2. One inbound message. Write from a phone that has not written to your number in the last 24 hours, and confirm that the message lands in Chats (/app/chats). A phone that wrote more recently can still be held by your source provider. If the message does not land, check Conversation Routing first, and the webhook line on Business accounts next. The rest of this list cannot pass without it.
3. The two local reads, which answer without calling Meta at all. POST /v1/messaging/gateway/{phone_number_id}/messages/validate checks one payload and stores nothing; GET /v1/messaging/gateway/{phone_number_id}/contacts/{contact} reports whether the customer service window is open for one contact, from stored inbound messages only.
4. One signed delivery at your own endpoint, verified against the whsec_… secret, with the delivery log (/app/deliveries) showing the attempt.

Check the Meta-level facts too, against the list from step 1: the display name, the quality rating, the messaging limit, the Official Business Account status, and every template's status.

Step 6 — Remove your source provider

Meta also lets you keep your source provider on the number, and skip this step: the next section says what that means. To finish a move, remove it.

In Meta Business Suite, open Messaging Accounts and remove your source provider from its account. Then open WhatsApp Accounts and remove your source provider from the account that holds your number. Remove its access yourself, and do not ask it to deregister the number. From then on, SambungAPI is the only provider on your number, and Meta sends it every incoming message. Write once more from any phone, and confirm that the message lands in Chats. If your source provider answered your WhatsApp calls, that ends here too: SambungAPI does not handle WhatsApp calls.

Then cancel the source provider's subscription, ask for whatever refund that provider documents, and remove the old credentials and webhook subscriptions. Keep the export from step 1: it is the record of that period, and neither Meta's share nor this connection is an archive import.

What you do in SambungAPI: nothing, unless the number was deregistered. If it was, register it again with POST /v1/messaging/wabas/{waba_id}/phones/{phone_number_id}/register. Without pin, SambungAPI sends a PIN that it mints for that call and keeps nowhere, and a number that has no two-step verification PIN takes it as its PIN. To hold the number's PIN yourself, send your own 6 digits as pin. If the answer is Messaging_PinRequired, the number has a two-step verification PIN that SambungAPI does not hold: send {"reset_pin": true} to set a new PIN and register. The PIN that the number had then stops working, and SambungAPI keeps the new PIN nowhere. To keep the PIN that the number has, send it as pin instead. If WhatsApp Manager later asks for the number's PIN, select Turn off two-step verification there and open the link that Meta emails you.

Keeping your source provider beside SambungAPI

Meta also lets two providers serve one number. If you keep your source provider after step 5, Meta's Conversation Routing gives each conversation to one of them. Meta can refuse a reply from the other one, and it accepts a template.

• Who gets a new conversation. In Conversation Routing in Meta Business Suite, you choose the primary provider for each way a conversation starts. Meta gives a new conversation to that primary, and the conversation stays with the provider that holds it until 24 hours pass with no message from the person who wrote.
• What SambungAPI shows. Chats marks a chat that another provider holds with Another app answers this chat. Meta can refuse a reply from SambungAPI to such a chat. Meta accepts it when SambungAPI is the escalation partner in Conversation Routing, and the reply then takes the chat over. You can still send a template.
• Moving a chat. Take over in Chats works when SambungAPI is the escalation partner and you have accepted the Meta Business Agents and Platform Terms in Meta Business Suite. Release gives a chat that SambungAPI holds back to Conversation Routing.
• What the two providers share. The number's throughput and its messaging limit. Meta bills each message to the account of the provider that sends it.

Keep the two providers' automatic replies apart, so that nobody gets two answers.

Coming from Kirimdev

Kirimdev's public documentation was read on 2026-09-11.

Kirimdev's platform model describes a business connecting its own WhatsApp Business number through Meta's Embedded Signup and keeping its own inbox, contacts and message history. What is Kirimdev's own is its organization-scoped bearer key, its signed webhook subscription, the messages and media it stores, and its plan retention: disconnecting is documented as a best-effort unsubscribe of Meta's webhooks, a soft delete of the account, and a scheduled data purge.

Two consequences for a move. First, Kirimdev's retention policy can permanently delete older messages and downloaded media, so the export in step 1 is time-sensitive rather than a formality. Second, Kirimdev documents a template sync that pulls the inventory from Meta and upserts its own records: that is evidence that Meta is the source of template state. It is not evidence of any Kirimdev-to-SambungAPI import contract, and none exists.

What the fetched documentation did not contain is a dedicated cross-provider offboarding procedure. That is a gap in what is published, not proof that Kirimdev refuses a move.

Coming from Qiscus

Qiscus's public documentation was read on 2026-09-11, and its migration page again on 2026-10-03.

Qiscus publishes a scheduled number migration rather than a self-serve one: it asks for advance notice, works within office hours, requires the same Meta Business Manager id, and asks for two-step verification to be disabled. Its page, read again on 2026-10-03, still describes that migration. For a business that Meta has moved, the share in step 2 replaces it.

What is Qiscus's own is its channel and app ids, its API credentials, its webhook forwarding, and its channel credit. Its own documentation does not state that its chat history, credentials, channel balance or billing records transfer to another provider, and this page does not assume they do.

One conflict is worth carrying into the conversation. Qiscus's article on coexistence says one Business Platform may be connected at a time and reports a lower throughput limit than Meta's own page states for the same arrangement. Treat Meta's constraint as the authoritative one and ask Qiscus to explain its own figure.

Coming from WATI

WATI's public documentation was read on 2026-09-11, and its migration page again on 2026-10-03.

WATI's migration page, read again on 2026-10-03, still describes a number migration between official providers. For a business that Meta has moved, the share in step 2 replaces it.

Templates are where WATI's own guidance is most useful as a warning: its template import is WATI-to-WATI only, and templates held in WhatsApp Manager must be recreated under a new name. Plan for resubmission rather than for carry.

WATI can export chat history as a compressed archive of per-contact text files. It documents export and not import, which is the same boundary as everywhere else on this page. Its coexistence flow can import contacts, one-to-one history up to six months, and multimedia up to two weeks, while groups remain in the WhatsApp Business app. WATI also warns that adding a separate Meta payment method alongside its managed billing can produce duplicate charges, so settle the billing question with WATI before you add the payment method of step 3.

Coming from 360dialog

360dialog's public documentation was read on 2026-09-11, and its migration pages again on 2026-10-03.

360dialog's migration pages, read again on 2026-10-03, still describe a number migration, with two-step verification disabled and the destination coordinating the move. For a business that Meta has moved, the share in step 2 replaces those steps. The rest of its exit checklist is still a workstream of its own: outstanding invoices cleared, the old phone subscription cancelled so that billing stops, and any documented refund of unused funds requested.

A 360dialog API key is issued per phone number, may be partner-managed, is shown once, and generating a new one revokes the existing keys. Treat the old key as something to disable after the new path is validated, never before it.

One internal conflict to read carefully: 360dialog's migration overview opens by saying migration happens without losing messaging history, while the asset table on the same page marks message and chat history as not migrated. Use the asset table, and export.

Coming from another provider

Twilio, Infobip, Gupshup and anything else not named above have no block here, because their documentation has not been read for this guide. Rather than guess, use Meta's rules, which bound every move regardless of who you are leaving:

• The number does not move. You share it, and Meta gives each provider its own WhatsApp Business Account on it.
• A message template stays in the account where it was made.
• Meta bills each message to the account of the provider that sends it.
• While two providers are on the number, they share its throughput and its messaging limit, and Meta's Conversation Routing decides which one gets each incoming message.
• Any provider on the number can deregister it.
• Webhook subscriptions belong to each provider's account, and a new subscription does not backfill the events that went to the old endpoint.

Everything your current provider stores locally — its credential, its webhook wrapper, its inbox, its template records, its balance — is provider-local by the same reasoning that applies to the four providers above. Export it first, and assume none of it follows the number.

Does my history come with me

Two honest halves, and neither is the one most people hope for.

Not through a provider change. Neither Meta's share nor this connection hands your source provider's stored conversations to SambungAPI, and at least one provider's own asset table says history does not move, on a page whose introduction implies otherwise. Whatever your source provider stored stays with your source provider, which is why step 1 exports it.

Through coexistence, a bounded part. A number that is in the WhatsApp Business app, and not with an API provider, connects by coexistence: select Connect a WhatsApp Business Account, then Connect with Meta, and enter the number in Meta's window. A number that another provider serves by coexistence follows step 2. The number stays in the app and is also registered to Meta's WhatsApp Cloud API. When you agree in the app to share your history, SambungAPI imports what Meta sends, and its bounds are narrow by design: one-to-one messages within 180 days, individual chats only, groups excluded, and a sync that must be completed inside a deadline that starts when the account is connected.

Read "coexistence" as a bounded, opt-in synchronization of recent one-to-one messages. It is not an archive import, and nothing on this page is.

Where to go next

• Send a first WhatsApp message. Prove the whole journey on Meta's test account before you connect the real number. It is the rehearsal step 5 checks against.
• Read the API guide. Every route this runbook names, in full: where to mint a key, the request shapes, the envelopes and the error taxonomy.
• Open the console. Business accounts is where the connect wizard starts, and where step 2 happens.