> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Europe channels onboarding: WhatsApp, RCS, SMS

> Step-by-step onboarding playbook for European destinations — pick WhatsApp vs RCS vs SMS per country, register EU-compliant senders (WABA, alphanumeric sender IDs, 2-way numbers), wire GDPR consent, and read the error codes you will actually see.

# Europe channels onboarding: WhatsApp, RCS, SMS

This guide is the ordered onboarding path for European destinations — from picking the right channel per country, through sender setup, to GDPR consent and troubleshooting. It is the series partner of the [APAC channels onboarding](/guides/asia-channels-onboarding) guide; the RCS, sender-identity, and GDPR pages it links carry the API detail.

## Pick the right channel per destination

Do not activate every channel for every European country. Pick per destination:

| Destination                 | First channel                        | Strong second | Notes                                                           |
| --------------------------- | ------------------------------------ | ------------- | --------------------------------------------------------------- |
| DE, UK, IE, NL, BE, Nordics | WhatsApp                             | SMS           | WhatsApp is the dominant consumer channel; SMS covers the rest. |
| FR, ES, IT, PT              | WhatsApp                             | RCS           | RCS reach is growing fastest here; keep SMS as fallback.        |
| PL, AT, CH, CZ              | RCS (bot launch willing) or WhatsApp | SMS           | RCS-outage hours matter — never RCS-only.                       |
| Any EU destination          | SMS                                  | —             | SMS is universal; it always delivers where apps do not.         |

If you are unsure, start with WhatsApp where your audience is smartphone-heavy, SMS everywhere else. Add RCS only where you pass the launch gates below.

## 1. Sender choice: WABA, registered sender ID, or a 2-way number

European SMS sender regulation is destination-level, not channel-level. Pick the sender before you send:

* **WhatsApp** — a verified **WhatsApp Business Account (WABA)**. The sender IS the WABA profile; there is no per-message `from`. Verification runs in [Channels → WhatsApp → Connect](/channels/whatsapp).
* **SMS alphanumeric sender ID** — a 3–11 character brand string (`MyBrand`). Most of Europe requires per-country **registration** before traffic flows. Register it under **Compliance → Sender-ID Registration**; the send-time gate refuses traffic to gated destinations until the registration is `approved` — failures come back as a visible `rejected`, never silently filtered.
* **SMS 2-way long code** — a real E.164 number. Required when you need inbound replies (STOP, support, opt-in). Buy it under **Numbers → Buy**; check stock first with the [country-capabilities summary](/numbers/country-capabilities).

To check what a destination requires before you pick:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/numbers/country-capabilities?country=DE" \
  -H "X-API-Key: dv_test_sk_..."
```

The response tells you which line types and sender forms are in stock for the destination. Route the sender decision through that result, not through habit — the wrong sender on a gated destination is a `rejected` you can avoid.

## 2. RCS-first pathway (DE/FR/ES, expanding)

RCS sends run under a **verified business agent**, and carriers only launch after brand + agent + per-carrier verification. Follow the full gates in order in the [RCS onboarding guide](/guides/rcs-onboarding); this checklist is the short version:

1. Register the brand and create the agent (one combined submission).
2. Pass per-carrier verification for the destinations you target.
3. Before the first campaign, check recipient capability rather than assuming reach:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/rcs/capability/bot_eu_retail/+491515556677" \
  -H "X-API-Key: dv_test_sk_..."
```

A `capable: true` handset takes RCS; a `capable: false` one falls through to SMS if you wire the chain. Size reach before committing a segment — the RCS onboarding guide's reach-scanning step returns a recommended channel mix (`rcs`, `mixed`, or `sms`).

## 3. SMS fallback with an alphanumeric sender

SMS is the universal European floor — it delivers where WhatsApp and RCS do not. Send with the registered sender ID as `from`:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/messages/sms \
  -H "X-API-Key: dv_test_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+491515556677",
    "from": "MyBrand",
    "body": "Your order #12345 has shipped."
  }'
```

| Field  | Required | Description                                                                                                                     |
| ------ | -------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `to`   | yes      | Recipient E.164 number.                                                                                                         |
| `from` | no       | Sender — alphanumeric ID (registration-gated per destination), E.164 number, or pool reference. Omit to use the tenant default. |
| `body` | yes      | Message body.                                                                                                                   |

The same send through the Node.js SDK:

```typescript theme={null}
import { Devotel } from '@devotel-orbit/node';

const orbit = new Devotel({ apiKey: process.env.ORBIT_API_KEY });

const message = await orbit.messages.send({
  channel: 'sms',
  to: '+491515556677',
  from: 'MyBrand',               // omit to use the tenant default
  body: 'Your order #12345 has shipped.',
});
```

`202 Accepted` means queued; terminal `delivered` / `failed` arrives on the delivery-status webhook. For RCS→SMS fallback wiring, see [Fallback chains](/guides/fallback-chains).

## 4. GDPR consent — the tenant-owned control

Sending into Europe without recorded consent is a deliverability and regulatory problem. Consent capture, lawful-basis tracking, residency, retention, and DSAR are **tenant-owned controls** — Orbit gives you the knobs; the posture you assemble is yours.

Wire it before the first campaign:

1. Record per-channel consent on the contact with the Consent Management API; the lawful basis (consent, legitimate interest) travels with the record. See [Consent Management & Receipts](/compliance/consent-management).
2. Map the rest of the GDPR posture — residency, retention, DSAR SLA, the Art. 30 register, the DPA — with the end-to-end walkthrough in [Assembling a GDPR Posture](/compliance/gdpr-posture-guide).
3. Honour revocation: a withdrawn consent suppresses further sends on that channel; the consent inspector shows the current state per contact.

<Note>
  None of these controls blocks outbound by default. They record and enforce the posture you choose — the regulatory decision stays with you.
</Note>

## Errors and troubleshooting

<AccordionGroup>
  <Accordion title="422 VALIDATION_ERROR on a sender-ID send">
    The `from` value fails format rules: 3–11 characters, letters/digits/space/hyphen/underscore. An 11-character ceiling is the GSM 7-bit hard limit; regulators such as OFCOM (UK) and AGCOM (Italy) also reject IDs shorter than 3 characters. Fix the format and retry.
  </Accordion>

  <Accordion title="Send to a gated destination comes back rejected">
    The destination requires a registered alphanumeric sender ID and your registration for that country is not yet `approved` (or was never submitted). Check status under **Compliance → Sender-ID Registration**. The send-time gate fails visibly as `rejected` — no silent filtering — so you catch it on the delivery-status webhook.
  </Accordion>

  <Accordion title="RCS campaign skips recipients after launch">
    The recipient's carrier is not in the bot's launched `carrier_statuses` set, or the handset is not RCS-capable. Check `GET /rcs/bots/:id/quality` and pre-scan capability per the RCS-first pathway above — never assume reach.
  </Accordion>

  <Accordion title="WhatsApp template send rejected with VALIDATION_ERROR">
    The template name is not approved on the WABA, or template params do not match the approved placeholders. Approve the template in Meta Business Suite first, then reference it by name.
  </Accordion>

  <Accordion title="country-capabilities returns zero stock">
    The destination has no inventory of the line type you need (common: SMS-capable mobiles in GB). Pick an alternative line type (local landline, toll-free) or a different sender form — the summary exists so you find this out before a number search, not after.
  </Accordion>
</AccordionGroup>

## See also

* [APAC channels onboarding](/guides/asia-channels-onboarding) — the partner guide for LINE, WeChat, KakaoTalk, and Zalo destinations.
* [RCS onboarding: brand to launch](/guides/rcs-onboarding) — the four RCS gates in full.
* [RCS channel page](/channels/rcs) · [SMS channel page](/channels/sms) · [WhatsApp channel page](/channels/whatsapp) — per-channel API references.
* [Sender-ID Registration](/compliance/sender-id-registration) — the per-country registration flow.
* [Assembling a GDPR Posture End to End](/compliance/gdpr-posture-guide) · [Consent Management & Receipts](/compliance/consent-management).
* [Country capabilities](/numbers/country-capabilities) — destination stock before number search.
* [Fallback chains](/guides/fallback-chains) — RCS→SMS and cross-channel fallback wiring.