curl -X POST https://api.orbit.devotel.io/api/v1/messages/sms \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+14155552671",
    "from": "+18005551234",
    "body": "Hallo von Orbit 🚀 — normalisierter Text: 160 Zeichen hier wären zwei UCS-2-Segmente"
  }'

{
  "data": {
    "id": "msg_e4d5c6b7a8b9c0d1e2f3a4b5c6d7e8f9",
    "status": "queued",
    "channel": "sms",
    "segments": 2,
    "encoding": "UCS-2"
  },
  "meta": {
    "request_id": "req_xK9f3m2h",
    "timestamp": "2026-09-06T12:00:00Z"
  }
}

curl -X POST https://api.orbit.devotel.io/api/v1/messages/sms \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+14155552671",
    "from": "+18005551234",
    "body": "Hallo von Orbit 🚀 — normalisierter Text: 160 Zeichen hier wären zwei UCS-2-Segmente"
  }'

{
  "data": {
    "id": "msg_e4d5c6b7a8b9c0d1e2f3a4b5c6d7e8f9",
    "status": "queued",
    "channel": "sms",
    "segments": 2,
    "encoding": "UCS-2"
  },
  "meta": {
    "request_id": "req_xK9f3m2h",
    "timestamp": "2026-09-06T12:00:00Z"
  }
}

SMS

SMS weltweit über Orbits SMPP-Gateway senden. Orbit verbindet sich mit Tier-1-Carriern und Aggregatoren in über 190 Ländern und übernimmt Konkatenation, Kodierung und Zustellverfolgung automatisch. Diese Seite führt Sie durch den Kanal von Anfang bis Ende: welchen Absender Sie anbinden, wo Registrierung vor dem Verkehr erforderlich ist, wie die Kodierung die Kosten pro Sendung bestimmt, was der Status-Lifecycle Ihnen sagt und wie Sie Fehler lesen, wenn sie zurückkommen.

Ein SMS senden

curl -X POST https://api.orbit.devotel.io/api/v1/messages/sms \
  -H "X-API-Key: dv_test_sk_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+14155552671",
    "from": "+18005551234",
    "body": "Hallo von Orbit!"
  }'

import { Devotel } from '@devotel-orbit/node';

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

// Body-only-Kanäle gehen über den generischen typed Helper.
const message = await orbit.messages.send({
  channel: 'sms',
  to: '+14155552671',
  from: '+18005551234',          // expliziter Absender — weglassen für Tenant-Default
  body: 'Hallo von Orbit!',
});

console.log(message.data.id);      // msg_a1b2…
console.log(message.data.status);  // 'queued'

// Kein SDK? Plain fetch reicht — die Anfrageform bleibt unverändert.
const res = await fetch('https://api.orbit.devotel.io/api/v1/messages/sms', {
  method: 'POST',
  headers: {
    'X-API-Key': process.env.ORBIT_API_KEY!,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    to: '+14155552671',
    from: '+18005551234',
    body: 'Hallo von Orbit!',
  }),
});
const { data } = await res.json();
console.log(data.id, data.status); // gleicher Umschlag wie die curl-Antwort unten

from orbit_sdk import OrbitClient

client = OrbitClient.from_env()  # liest ORBIT_API_KEY

message = client.messages.send_sms(
    to="+14155552671",
    body="Hallo von Orbit!",
    from_="+18005551234",  # expliziter Absender — weglassen für Tenant-Default
)

print(message["data"]["id"])       # msg_a1b2…
print(message["data"]["status"])   # 'queued'

msg, err := client.Messages().SendSMS(context.Background(), orbit.SendSMSInput{
    To:   "+14155552671",
    Body: "Hallo von Orbit!",
    From: "+18005551234",  // expliziter Absender — weglassen für Tenant-Default
})
if err != nil {
    panic(err)
}

fmt.Println(msg.Data.ID)      // msg_a1b2…
fmt.Println(msg.Data.Status)  // "queued"

# Eine rohe HTTP-Escape-Hatch für Sprachen ohne typed SDK — jeder Client
# oder jede Bibliothek funktioniert, solange Header und JSON-Body gesetzt werden können.
send = client.request(
    "POST",
    "/messages/sms",
    json_body: {
        to: "+14155552671",
        from: "+18005551234",
        body: "Hallo von Orbit!",
    },
)

puts send.dig("data", "id")       # msg_a1b2…
puts send.dig("data", "status")   # 'queued'

Sowohl to als auch from werden als E.164 validiert — vollständiges internationales Format mit Länder-Präfix, wie +14155552671. Wie Orbit Nummern validiert und normalisiert, steht im Nummern-Lifecycle. Verwenden Sie während des Prototypings einen Sandbox-Schlüssel (dv_test_sk_… über curl, ORBIT_API_KEY im Code) — Sandbox-Sendungen sind simuliert, kostenlos und erreichen nie einen Carrier. Beim Wechsel zur Produktion tauschen Sie den Live-Schlüssel ein; kein Code oben ändert sich. Der Node-Tab oben verwendet den generischen orbit.messages.send({ channel: 'sms', ... })-Helper; die typed Per-Channel-Methode orbit.messages.sendSms({ to, body, from }) macht denselben POST — wählen Sie eine Form und bleiben Sie konsistent.

Antwort

Endpunkt antwortet mit HTTP 202 Accepted — die Nachricht ist persisted und zur Zustellung in Warteschlange (noch nicht an Carrier übergeben). Die id ist eine Plattform-Nachricht-ID der Form msg_ gefolgt von 32 kleingeschriebenen Hex-Zeichen (kein Kanal-Infix); ihren Lifecycle über Zustell-Webhooks verfolgen.

{
  "data": {
    "id": "msg_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
    "status": "queued",
    "channel": "sms",
    "segments": 1,
    "encoding": "GSM-7"
  },
  "meta": {
    "request_id": "req_sms_send",
    "timestamp": "2026-03-08T00:00:00Z"
  }
}

Mit welcher Sprache die Sendung geschah, der Umschlag ist der obige — data.id lesen, um später zu pollen oder abzugleichen, und auf data.status verzweigen (beginnt bei queued):

Node.js / fetch (TypeScript) — SDK- oder res.json()-Rückgabewert trägt den Umschlag: message.data.id, message.data.status.
Python — send_sms gibt den rohen JSON-Body als dict zurück: message["data"]["id"], message["data"]["status"].
Go — SendSMS unmarshal den Umschlag in ein typed struct: msg.Data.ID, msg.Data.Status.
Ruby / PHP (Escape-Hatch) — client.request gibt den rohen JSON-Body zurück: send.dig("data", "id") / $send['data']['id'].

segments und encoding bei jedem Senden lesen — das ist, was die Abrechnung belastet, und Abschnitt Kodierung & Konkatenation unten zeigt, wie Sie beides vor dem Senden vorhersagen.

Häufige Muster

Zwei Muster decken nahezu jede SMS-Produktionsintegration ab: sichere Retries beim Senden und Nachrichten-Historie paginieren.

Idempotent senden mit Idempotency-Key

POST-Endpunkte, die Ressourcen erstellen, akzeptieren einen Idempotency-Key-Header. Ein Retry mit demselben Schlüssel gibt den ursprünglichen Umschlag zurück — kein Doppel-Senden, keine zweite Belastung. Die SDKs mintieren einen UUID pro Aufruf automatisch; über rohen HTTP setzen Sie ihn explizit. In beiden Fällen übergeben sie einen stabilen Schlüssel über die Versuche eines logischen Sendens statt jedem Retry seinen eigenen zu mintieren.

Node

const message = await orbit.messages.send(
  { channel: 'sms', to: '+14155552671', body: 'Hallo von Orbit!' },
  { idempotencyKey: 'job-7a3b9d-checkout-reminder' },  // stabiler Schlüssel über Retries
);

Python

message = client.messages.send_sms(
    to="+14155552671",
    body="Hallo von Orbit!",
    idempotency_key="job-7a3b9d-checkout-reminder",  # stabiler Schlüssel über Retries
)

Der vollständige Vertrag steht in Idempotenz und sichere Retries.

GET /messages über SDK-Listenaufrufe paginieren

Nachrichten-Historie ist cursor-paginiert: jede Seite trägt meta.pagination.cursor und meta.pagination.has_more; den Cursor zurückgeben, bis has_more false ist. Das Node-SDK liefert eine Cursor-Schleife und einen auto-paginierenden Iterator; die anderen SDKs paginieren über ihre Listen-Methoden oder die Escape-Hatch:

Node

// Cursor-Schleife — explizite Kontrolle.
let cursor: string | undefined;
do {
  const page = await orbit.messages.list({ channel: 'sms', limit: 100, cursor });
  for (const message of page.data) {
    // eine Nachricht pro Iteration konsumieren
  }
  cursor = page.meta.pagination.has_more
    ? page.meta.pagination.cursor
    : undefined;
} while (cursor);

// …oder Iterator paginieren lassen:
for await (const message of orbit.messages.iter({ channel: 'sms' })) {
  console.log(message.id, message.status);
}

Python

# Das Python-SDK umhüllt nur Kern-Ressourcen — mit der Escape-Hatch paginieren,
# die neben `json_body` ein `query`-dict akzeptiert.
cursor = None
while True:
    query = {"channel": "sms", "limit": 100}
    if cursor:
        query["cursor"] = cursor
    page = client.request("GET", "/messages", query=query)
    for message in page["data"]:
        # eine Nachricht pro Iteration konsumieren
        pass
    pagination = page["meta"]["pagination"]
    if not pagination.get("has_more"):
        break
    cursor = pagination["cursor"]

Das vollständige Paginations-Modell — Cursor- vs. Offset-Familien, Seiten-Size-Kappen und warum Cursor nicht bookmarkbar sind — steht in der Paginations-Anleitung.

Abgearbeitetes Beispiel: senden, pollen und Fehler handhaben

Die Sequenz unten ist die gleiche Ende-zu-Ende: POST die Sendung, poll GET /messages/{id} (oder nehme den webhook — Polling ist der Fallback) und verzweige deterministisch, wenn etwas fehlschlägt. Der Body ist absichtlich ein UCS-2-Senden, damit Sie das Kodierungsverdikt zurückkommen sehen statt GSM-7-Preis zu vermuten.

1. Nachricht senden

curl -X POST https://api.orbit.devotel.io/api/v1/messages/sms \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+14155552671",
    "from": "+18005551234",
    "body": "Hallo von Orbit 🚀 — normalisierter Text: 160 Zeichen hier wären zwei UCS-2-Segmente"
  }'

Direkte API-Sendungen müssen einen Absender deklarieren — from, sender_pool_id, messaging_service_id oder from_extension — sonst gibt der Endpunkt HTTP 422 mit SENDER_REQUIRED (z.B. wenn ein Past wie "from": null in Ihre Anfrage rutscht). Was jeder Selektor bedeutet, siehe Absendertyp wählen.

2. Send-Antwort lesen

{
  "data": {
    "id": "msg_e4d5c6b7a8b9c0d1e2f3a4b5c6d7e8f9",
    "status": "queued",
    "channel": "sms",
    "segments": 2,
    "encoding": "UCS-2"
  },
  "meta": {
    "request_id": "req_xK9f3m2h",
    "timestamp": "2026-09-06T12:00:00Z"
  }
}

status: queued ist der Startzustand — noch nichts zugestellt, und kein external_id (Carrier-Referenz) ist zurückgegeben. segments- und encoding-Felder sind genau das, wogegen Segment-Preisung multipliziert; behandeln Sie sie als die Rechnung, nicht als Hinweis.

3. Zeile pollen

Wenn Sie Webhooks nicht (oder nicht wollen) abonnieren, pollen Sie GET /messages/{id} auf der id, die das Senden zurückgab. Die Zeile rückt durch sending → sent → delivered / einen Terminal-Fehler vor. Jede Antwort trägt auch metadata.classified_error_code für Terminal-Fehler und metadata.no_dlr_channel für Meta-DM-Zeilen, also verzweigen Sie auf den maschinenlesbaren status, nie auf Beschriftungsstrings.

curl https://api.orbit.devotel.io/api/v1/messages/msg_e4d5c6b7a8b9c0d1e2f3a4b5c6d7e8f9 \
  -H "X-API-Key: dv_live_sk_your_key_here"

{
  "data": {
    "id": "msg_e4d5c6b7a8b9c0d1e2f3a4b5c6d7e8f9",
    "channel": "sms",
    "direction": "outbound",
    "to": "+14155552671",
    "from": "+18005551234",
    "status": "delivered",
    "segments": 2,
    "encoding": "UCS-2",
    "external_id": "dev-smpp-e9a8b7c6",
    "sent_at": "2026-09-06T12:00:01Z",
    "error_code": null,
    "error_message": null,
    "metadata": {}
  },
  "meta": {
    "request_id": "req_poll_002",
    "timestamp": "2026-09-06T12:00:02Z"
  }
}

Polling ohne Webhooks fängt Zwischenzustände meist auch — sending (Provider hat sie gepackt) oder sent (Provider akzeptierte sie) vor delivered. ?include=webhook_deliveries hinzufügen, wenn Sie die Fan-Out-Historie in einer Rundreise wollen.

4. Auf Fehler verzweigen

Verzweigen Sie auf die Poll-status, die Webhook-data.status oder metadata.classified_error_code — alle erzählen dieselbe Geschichte. Die Fehlerfamilien unten sind die, die Sie realistisch handhaben müssen:

status / code	Was passierte	Was zu tun
`rejected` — `SENDER_REQUIRED`, `SENDER_ID_NOT_REGISTERED`, `SENDER_ID_NOT_APPROVED`	Pre-Carrier-Gate verweigerte die Sendung: kein deklarierter Absender, oder Absender-ID nicht registriert/genehmigt für die Destination	Deterministisch — nicht retry. Gate zuerst leeren: expliziten Absender deklarieren (`from` / `sender_pool_id`), Absender-ID für die Destination registrieren, und für US 10DLC durch die 10DLC-Registrierungsanleitung routen. Bis dahin wird die Sendung jedes Mal verweigert.
Senden-blockiert — Warteschlangen-supprimiert — `SENDING_BLOCKED`, `RECIPIENT_OPTED_OUT`, `FREQUENCY_CAP_EXCEEDED`	Ihre eigenen Tenant-Kontrollen supprimierten die Sendung: Ausgang auf Org-Ebene pausiert, Empfänger ist auf Ihrer Opt-out-Liste, oder Frequenz-Kappe feuerte	Auf Ihrer Seite korrigieren: Nummer von der Blockliste entfernen oder auf die Kappe-Lift warten. Die Sendung erreicht den Carrier nie, also keine `external_id` erzeugt.
DLR-Fehler — `undelivered`, `failed`, `submitted_no_receipt`	Carrier-Ergebnis zurückkam: Handset unerreichbar / Nummer tot (`undelivered`), Provider-/Upstream-Fehler (`failed`), oder keine DLR innerhalb des 30-minütigen SMPP-Grace-Fensters (`submitted_no_receipt` — kann noch zu `delivered` wechseln, siehe Nachrichten-Status-Lifecycle)	Troubleshooting-Pfad einschleifen: `classified_error_code` auf der Zeile vor Übergabe an Support prüfen; Nummern-Lookup vor einem `undelivered`-Retry ablaufen.

Auf jedem message.failed-Webhook ist data.status das Verzweigungsfeld — submitted_no_receipt und expired reiten auf diesem Event, und ein späterer message.delivered-Webhook kann noch nach einem davon ankommen.

SMS-Deliverability-Grundlagen

SMS-Deliverability beruht auf drei Dingen, in dieser Reihenfolge: von wem Sie senden, wo, und wie schnell. Das richtig einstellen, und Kodierung wird die einzige Kostenvariable, die bleibt.

Absendertyp wählen

Absendertyp	Am besten für	Einschränkung
Alphanumerischer Absender-ID (`MyBrand`)	Marken-Erkennung; Märkte, wo numerische Absender-IDs supprimiert sind	Registrierung in vielen Ländern erforderlich; kann keine Antworten (eine Richtung)
Numerischer Long-Code (`+14155550123`)	Zwei-Wege-SMS, Antworten, Konversational-Support	Durchsatz variiert nach Land (US: registrieren Sie in 10DLC für vollen Durchsatz)
Short-Code (`12345`)	Hochdurchsatz-Kampagnen, einprägsame OTP-Sendungen	Lange Carrier-Lead-Zeit, höhere Kosten
Absender-Pool (Mischung der obigen)	Hohes Volumen, lokale Präsenz, Degradierter-Absender-Rotation	Siehe Absender-Pools
Messaging-Service (`messaging_service_id`)	Pool + Opt-out-Liste + Inbound-Webhook + Durchsatz-Kappe unter einer ID; Multi-Absender-, Marken-Compliance- oder Twilio-Migrationsverkehr	Nummern anbinden und Per-Absender-Verkehr in der Messaging-Services-Konsole konfigurieren

Absender existieren aus einem Grund jeweils: Deliverability. Sie brauchen eine Absender-ID, die für die Regeln des Ziellandes genehmigt ist, oder der Carrier filtert den Verkehr, bevor er Ihnen ein Segment kostet — siehe Ländervors-Compliance.

Onboarding über das Dashboard

Der Dashboard-Walkaround dauert weniger als fünf Minuten und fängt die beiden Fehlermodi unten, bevor Sie eine Code-Zeile schreiben.

Öffnen Sie Channels → SMS im Dashboard.
Klicken Sie Attach Sender und wählen Sie einen Absendertyp oben. Orbit validiert das Format (E.164-Nummer, 3–11-stellige alphanumerische ID oder Pool-Referenz) und prüft, ob die als Default gewählte Destination Registrierung erfordert.
Senden Sie eine Testnachricht an eine Nummer, die Sie besitzen. Der Komposer zeigt segments und encoding inline, also sehen Sie die geschätzten Pro-Segment-Kosten vor dem Senden.
Wenn Ihr Ziel-Gate die Anbindung ablehnt (US ohne 10DLC-Kampagne, gated Land ohne Absender-ID-Genehmigung), routet der Assistent Sie zum Registrierungsfluss — siehe die nächsten zwei Abschnitte.

Sobald ein Absender hier angebunden ist, ist derselbe Absender aus dem SenderIdSelect im Komposer wählbar und läuft durch den registrierten Sendweg. So auditieren Sie auch, was GET /api/v1/messaging/senders über API zurückgibt.

10DLC-Registrierung & Kampangentyppen (US)

Wenn Sie zu US-Zielen über numerische Long-Codes senden, erfordern die Carrier Registrierung; unregistrierter Verkehr wird gefiltert, surcharged oder beides. Orbit übermittelt Registrierung durch The Campaign Registry in Ihrem Namen — der vollständige Walkaround (Marke → Kampagne → Genehmigung → Durchsatz-Tiers) ist in der 10DLC-Registrierungsanleitung. Der US-spezifische Punkt, den Sie im Kopf halten: Durchsatz nach Registrierung wird als pro-Tag-, pro-Nummer-Segment-Kappe auf Basis Ihrer Marken-Vetting-Score gewährt — nicht eine pro-Sekunde-Rate. Mehr tägliche Kapazität nötig? Erhöhen Sie Ihre Vetting-Score (vollständige Markendaten, EIN, Website) oder weisen Sie mehr Nummern der Kampagne zu. Für nicht-US-Ziele, die alphanumerische Absender-IDs gaten (meiste Europa, Brasilien, Bangladesh, Teile APAC), ist der parallele Registrierungsfluss Absender-ID-Registrierung, der Ihre Genehmigung pro Land aufzeichnet und die unterstützenden KYC-Dokumente anbindet. Das Sende-Zeit-Gate verweigert Verkehr zu gated Ländern, bis der passende Landeintrag approved ist — keine Stillfilterung, der Fehler kommt als sichtbarer rejected zurück. Indien ist die Ausnahme: Seine Absender-IDs (“Headers”) registrieren über DLT/TRAI statt dem generischen Fluss — siehe DLT-Indien-Onboarding.

Kodierung & Konkatenation

Kodierung ist die einzige Kostenvariable, die einen ordentlich registrierten Absender überlebt. SMS rechnet pro Segment ab, und die Segmentzahl hängt völlig davon ab, in welche Alphabet der Body passt.

GSM-7 vs. UCS-2

GSM-7 — das 7-Bit-GSM-Alphabet (ASCII plus ein paar Extras: @, £, €, etwas Griechisch). Ein Body, der hineinpasst, bekommt bis 160 Zeichen pro Segment, oder 153 Zeichen auf Multi-Part (7 pro Segment gehen an den UDH-Konkatenations-Header).
UCS-2 — jedes Zeichen außerhalb GSM-7 (Emoji, CJK, Smart-Anführungszeichen, meiste nicht-Latin-Skripte) flipt die ganze Nachricht auf 16-Bit-Kodierung. Ein Body bekommt bis 70 Zeichen pro Segment oder 67 auf Multi-Part.

Ein einziges Nicht-GSM-7-Zeichen klassifiziert die ganze Nachricht neu. Orbit normalisiert die versehentlichen Eindringlinge — eingefühlte Smart-Anführungszeichen, lange Striche, gekrümmte Apostrophe, unsichtbare Null-Breite-Zeichen — zu GSM-7-sicheren Äquivalenten, bevor es zählt, damit Paste-durch-Dokumente-Fehler Ihre Segmentrechnung nicht verdoppeln. Das vollständige Kodierungs- und Segmentations-Modell — Kapazitätstabellen, die 10-Segment-Kappe und warum der Komposer der Abrechnung entspricht — steht im Konzept SMS-Segmente und Kodierung. Eine einzelne Workspace-Formel, die Sie von Hand anwenden können:

segments = ceil(chars / per_segment_limit)
per_segment_limit = single_limit         falls es in einem Segment passt
                  = single_limit - header  sonst (GSM-7: 153, UCS-2: 67)

Abgearbeitetes Beispiel

Ihre Bestellung versandt — Antwort JA — 30 Zeichen, alle GSM-7 → 1 Segment, GSM-7. Ein einziges Emoji flipt das Alphabet: 54 Zeichen in UCS-2 → immer noch 1 Segment, aber ein 160-Zeichen-ASCII-Newsletter wird 2 UCS-2-Segmente, sobald ein Emoji hereinkommt. Auf Skala ist das die Zahl, die Kosten treibt. Die Plattform zählt Segmente vor dem Dispatchen; die Send-Antwort trägt das Verdikt:

{
  "segments": 2,
  "encoding": "UCS-2"
}

Hart-Ceiling: 10 Segmente (1.530 GSM-7-Zeichen oder 670 UCS-2-Zeichen). Bodies darüber werden abgeschnitten und die Sendung geht weiter; der Segment-Zähler markiert wasTruncated: true, damit Sie sehen, statt zu vielen, wo der Schwanz blieb. Das ist es, was die Features-Liste nennt “konkatenierte Nachrichten bis zu 10 Segmente”. Lesen Sie segments auf jeder Sendung und verzweigen Sie Ihre Abrechnungsschätzungen darauf — es ist genau das, wogegen Segment-Preisung multipliziert.

Rate-Limits, Durchsatz & Absender-Pools

Zwei unabhängige Limits auf SMS-Durchsatz, und Sie müssen beide leeren:

API-seitiges Request-Limit. 100 Requests/Minute pro Tenant standardmäßig auf POST /messages/sms, pro Organisation keyed. Darüber bekommen Sie 429 RATE_LIMITED; siehe Rate-Limits-Anleitung für Header und Retry-Handling. Die volle Per-Channel-Tabelle unten.
Absender-seitiger Durchsatz. US 10DLC: pro-Tag, pro-Nummer Segment-Kappe von Ihrer Vetting-Tier. Woanders: was die Zielroute pro Absender unterstützt.

Wenn eine Decke bindet, ist ein Absender-Pool der Hebel: mehr registrierte Absender zum Pool hinzufügen, Volumen über sticky, round_robin, random oder geomatch-Strategie verteilen, und Per-Absender-Durchsatz multipliziert mit Pool-Size. Pools lassen einen degradierten Absender ohne Änderung Ihres Sendcodes rotieren — der Pool-Health-Endpunkt sagt, welches Mitglied degradiert, bevor es ein Deliverability-Problem wird.

Nachrichten-Status-Lifecycle

Jede ausgehende SMS trägt einen status, der vorrückt, wenn die Nachricht von Ihrem API-Aufruf zum Handset — oder zum Terminal-Fehler — bewegt: queued → sending → sent → delivered (oder failed / undelivered / rejected / expired) Abonnieren Sie Status-Übergänge über Webhooks mit den Events message.sent, message.delivered und message.failed — ein Webhook pro Übergang, jeder trägt die Nachricht-id und den neuen status. Die Nuance, die Operatoren fängt:

submitted_no_receipt — der Provider akzeptierte die Sendung, keine DLR kam innerhalb des 30-minütigen SMPP-Grace-Fensters zurück. Als Zwischen markiert (is_terminal: false), weil eine späte delivered oder Fehler-DLR noch ankommen und überschreiben kann. Behandeln Sie es als Ergebnis unbekannt, nicht eine Zustellung und nicht ein Fehler.
expired — eine DLR kam an, nachdem das Spät-Zulassungsfenster schloss. Geschlossene Zeile, unkenntliches Ergebnis; fans auf message.failed aus.
cancelled — nur von Ihnen erreichbar; kein Webhook feuert je dafür.

Der Konzept-Level-Walkaround dieser Zustandsmaschine, die Per-Channel-Grace-Fenster und was is_terminal bedeutet, lebt in Liefer-Lifecycle; die Per-Status-Semantiken und die volle Übergangstabelle stehen in der Nachrichten-Status-Lifecycle-Referenz.

Troubleshooting

Wenn message.failed ankommt, verzweigen Sie auf den Payload-status, nicht den Event-Typ — submitted_no_receipt und expired fanen auch auf diesem Event aus. Lesen Sie metadata.classified_error_code für Maschinen-Handling, und error_code / error_message für des Carriers eigene Worting, wenn Sie ein Ticket öffnen.

Status	Wahrscheinliche Ursache	Wo damit arbeiten
`undelivered`	Handset unerreichbar, ungültige/deaktivierte Nummer, Carrier-Spamfilter	Troubleshooting: Nachricht unzugestellt oder fehlgeschlagen — Nummer-Lookup gegen die Destination vor Wiederholung vom Senden laufen lassen
`failed`	Provider-seitiger Fehler, transitorischer Upstream-Fehler	Gleiche Seite; meist transitorisch — Analytik-Fehler-Grund-Breakdown prüfen, bevor Sie auf Skala erneut senden
`rejected`	Unregistrierte Absender-ID, fehlende 10DLC-Kampagne, Inhaltpolitik	Gleiche Seite; deterministisch bis das Gate leert — Absender-Registrierung zuerst verifizieren
`submitted_no_receipt`	Langsame oder fehlende Carrier-DLR (30-minütiges SMS-Grace-Fenster)	Troubleshooting: Nachricht gesendet, aber keine Zustell-Quittung — nicht retry; die Zeile kann noch zu `delivered` wechseln
Steckt in `queued`	Nie den Provider erreicht	Warteschlangen-Troubleshooting

Das Eskalations-Paket, das ein Support-Ticket beim ersten Pass beantwortet: Ihre Tenant-ID, eine Nachricht-ID und die Zeilen-classified_error_code — plus Provider-Referenz aus dem Liefer-Log für DLR-Symptom-Zeilen. Der Liefer-Log-Anleitung zeigt, wie man den Status filtert; Nummern-Lookup sagt eine tote Nummer von einer lebendigen, bevor Sie wiederholen.

Preisung

SMS-Preisung ist pro Segment und variiert nach Zielland. Prüfen Sie die Preisseite oder fragen Sie den Endpunkt GET /api/v1/pricing/messaging?country=<ISO> für Echtzeit-Rates ab (das zurückgegebene channels-Array enthält sms). Die Planungszahl kommt aus den vorherigen Abschnitten: multiplizieren Sie die Pro-Segment-Rate, die der Preis-Endpunkt zurückgibt, mit dem segments-Wert, den die Send-Antwort trägt. Zwei sonst identische Sendungen rechnen verschieden ab, sobald deren Kodierung auf UCS-2 flipt — siehe Kodierung & Konkatenation, wann das passiert und wie man es zurücknormalisiert.

Features

A2P- und P2P-Nachrichten — App-an-Person- und Person-an-Person-Support
Globaler Reach — 190+ Länder über Devotels Aggregator-Netz
Zustell-Berichte — Echtzeit-Status-Webhooks für jede Nachricht
Konkatenierte Nachrichten — Multi-Part-SMS transparent gehandhabt (bis 10 Segmente)
E.164-Validierung — automatische Telefonnummer-Format-Validierung
Unicode-Support — vollständige GSM-7- und UCS-2-Kodierung mit automatischer Erkennung und Smart-Punctuation-Normalisierung
Absender-ID — alphanumerische Absender-IDs, wo lokalen Vorschriften unterstützt, registrierungs-gated wo erforderlich

Rate-Limits

SMS-Sendungen sind auf 100 Requests/Minute pro Tenant standardmäßig auf dem /messages/sms-Endpunkt limitiert. Das Limit ist pro Tenant (pro Organisation) keyed, nicht pro IP oder pro Plan, also konkurrierende Aufrufer im selben Tenant teilen einen Pool, während separate Tenants sich nie beeinflussen. Eine höhere Decke nötig? Die Pro-Tenant-Kappe ist über Ihre Organisation-Nachrichten-Einstellungen (channel_rate_overrides.sms) überbrückbar — Support kontaktieren oder vom Dashboard setzen. Limit-Überschreitung gibt 429 Too Many Requests mit dem RATE_LIMITED-Fehlercode zurück; siehe Rate-Limits-Anleitung für Header und Retry-Handling. Der gleiche Per-Channel-, Per-Minute-, Pro-Tenant-Modell gilt über Nachrichten-Kanäle (jede unabhängig überbrückbar):

Kanal	Default-Limit (Requests/Minute)
SMS	100
WhatsApp	80
Messenger	80
LINE	80
Telegram	80
Email	200
MMS	60
Gruppen-MMS (`POST /messages/group`)	60 (teilt die MMS-Kappe)
RCS	50
Viber	50
Fax	20

WhatsApp

Developer console

Contact center

Guides

Messaging Controls

Audience & Support Tools

SMS — weltweit senden und empfangen

SMS

Ein SMS senden

Antwort

Häufige Muster

Idempotent senden mit Idempotency-Key

GET /messages über SDK-Listenaufrufe paginieren

Abgearbeitetes Beispiel: senden, pollen und Fehler handhaben

1. Nachricht senden

2. Send-Antwort lesen

3. Zeile pollen

4. Auf Fehler verzweigen

SMS-Deliverability-Grundlagen

Absendertyp wählen

Onboarding über das Dashboard

10DLC-Registrierung & Kampangentyppen (US)

Kodierung & Konkatenation

GSM-7 vs. UCS-2

Abgearbeitetes Beispiel

Rate-Limits, Durchsatz & Absender-Pools

Nachrichten-Status-Lifecycle

Troubleshooting

Preisung

Features

Rate-Limits

​SMS

​Ein SMS senden

​Antwort

​Häufige Muster

​Idempotent senden mit Idempotency-Key

​GET /messages über SDK-Listenaufrufe paginieren

​Abgearbeitetes Beispiel: senden, pollen und Fehler handhaben

​1. Nachricht senden

​2. Send-Antwort lesen

​3. Zeile pollen

​4. Auf Fehler verzweigen

​SMS-Deliverability-Grundlagen

​Absendertyp wählen

​Onboarding über das Dashboard

​10DLC-Registrierung & Kampangentyppen (US)

​Kodierung & Konkatenation

​GSM-7 vs. UCS-2

​Abgearbeitetes Beispiel

​Rate-Limits, Durchsatz & Absender-Pools

​Nachrichten-Status-Lifecycle

​Troubleshooting

​Preisung

​Features

​Rate-Limits

SMS

Ein SMS senden

Antwort

Häufige Muster

Idempotent senden mit Idempotency-Key

GET /messages über SDK-Listenaufrufe paginieren

Abgearbeitetes Beispiel: senden, pollen und Fehler handhaben

1. Nachricht senden

2. Send-Antwort lesen

3. Zeile pollen

4. Auf Fehler verzweigen

SMS-Deliverability-Grundlagen

Absendertyp wählen

Onboarding über das Dashboard

10DLC-Registrierung & Kampangentyppen (US)

Kodierung & Konkatenation

GSM-7 vs. UCS-2

Abgearbeitetes Beispiel

Rate-Limits, Durchsatz & Absender-Pools

Nachrichten-Status-Lifecycle

Troubleshooting

Preisung

Features

Rate-Limits