How to migrate from Apifon to Sinch

Apifon is a Greek business-messaging platform offering SMS, Viber, WhatsApp, RCS, Messenger and email through a web app plus REST and SMPP APIs. Sinch is a larger, publicly traded cloud-communications platform covering messaging, voice and email. On the messaging.dev Score, Apifon rates 52/100 and Sinch 92/100; the sections below lay out what actually changes when you move, presented as data rather than endorsement.

What you gain, what you lose

Both platforms carry SMS, RCS, WhatsApp, Viber, Facebook Messenger and email, so those channels move over unchanged. Migrating to Sinch adds four channels Apifon lists as unsupported: MMS, Telegram, Apple Messages for Business and Voice. No channel is lost in the move.

On compliance, both are GDPR- and ISO 27001-aligned; Sinch additionally reports SOC 2 and HIPAA. For data residency, Apifon hosts within the EU only, with no US option and no region choice, while Sinch offers EU and US servers, a data-residency choice, and APAC, Australia and Brazil regions.

The two overlap on developer basics: identical SDK coverage (Java, Python, C#, Node.js, PHP), “high” documentation quality, and a free developer credit on sign-up. The differences: Apifon exposes REST and SMPP, while Sinch adds SMTP. Sinch also provides a sandbox for pre-production testing, which Apifon does not. Pricing models differ too — Apifon is prepaid pay-as-you-go against a euro balance with per-account (unpublished) rates, whereas Sinch is pay-as-you-go with volume and committed-use pricing and a published starting point of about $0.0075 per US SMS segment. One trade-off runs the other way: Sinch’s dataset lists roughly 150 countries covered versus Apifon’s 200.

How the request format differs

Source (Apifon):

curl -X POST "https://ars.apifon.com/services/api/v1/sms/send" \
  -H "Content-Type: application/json" \
  -H "X-ApifonWS-Date: $(date -u '+%a, %d %b %Y %H:%M:%S GMT')" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -d '{"message":{"text":"Hello There!","sender_id":"Apifon"},"subscribers":[{"number":"306999999999"}]}'

Target (Sinch):

curl -X POST 'https://us.sms.api.sinch.com/xms/v1/YOUR_SERVICE_PLAN_ID/batches' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -H 'Content-Type: application/json' \
  -d '{"from":"+15005550006","to":["+15551234567"],"body":"Hello from Sinch"}'

The endpoint changes from Apifon’s fixed .../sms/send path to Sinch’s .../xms/v1/{service_plan_id}/batches, which embeds a service-plan ID in the URL — you obtain that ID from the Sinch dashboard. Authentication simplifies: Apifon accepts either HMAC-signed requests (an Authorization: ApifonWS <key>:<signature> header plus X-ApifonWS-Date) or an OAuth2 Bearer token, while Sinch uses a single Bearer token in the Authorization header, so you can drop the X-ApifonWS-Date header entirely.

Payload fields remap as follows. Apifon nests content under a message object (message.text, message.sender_id) and lists recipients as objects in subscribers ([{"number":"306999999999"}]). Sinch flattens this: the body becomes body, the sender becomes from, and recipients become a plain string array in to (["+15551234567"]). Note the number format — Sinch expects E.164 with a leading +.

Migration checklist

1. Create a Sinch account, generate an API token, and note your service-plan ID from the dashboard.
2. Map request fields: message.text → body, message.sender_id → from, subscribers[].number → to[], and reformat numbers to E.164.
3. Swap authentication: replace Apifon’s HMAC/OAuth2 scheme with a single Authorization: Bearer token and remove X-ApifonWS-Date.
4. Re-point sending code to https://<region>.sms.api.sinch.com/xms/v1/{service_plan_id}/batches, choosing the region that matches your residency needs.
5. Re-test in the Sinch sandbox before sending live traffic.
6. Update delivery/status webhooks to consume Sinch’s callback format instead of Apifon’s.
7. Run both integrations in parallel, compare delivery results, then cut over once Sinch matches your baseline.

Watch out for

• Country coverage: Sinch’s dataset lists ~150 countries versus Apifon’s ~200 — confirm your destinations are supported before cutover.
• Default region: the quickstart endpoint uses a US host (us.sms.api.sinch.com); if you need EU residency (Apifon’s only option), explicitly select the EU region rather than the default URL.
• Auth change: HMAC-signed requests are Apifon-specific — if your code relied on request signing, it moves to a plain Bearer token.
• Service-plan ID: Sinch requires it in the URL path, so a hard-coded Apifon endpoint won’t port over directly.

For a fuller walkthrough, see how to start with Sinch, or the side-by-side Apifon vs Sinch comparison.