SMS-Verifizierung automatisieren: der komplette API-Guide

Für eine gelegentliche Registrierung reicht die Website völlig aus: ein paar Klicks, kurz auf eine SMS warten. Das reicht nicht mehr, wenn du automatisierte Tests schreibst, ein Skript für Massenregistrierungen, eine CI-Pipeline oder einen Bot, der den Verifizierungscode unbeaufsichtigt abholen muss. Das kann die Website nicht. Die API kann es. Hier steht alles, was du brauchst, um von null zu einem funktionierenden Ablauf zu kommen.

Schritt 1: API-Schlüssel besorgen

Melde dich an und gehe zu /account/api-keys, um einen zu erstellen. Schlüssel sehen so aus: jm_ gefolgt von einer zufälligen Zeichenfolge. Der Klartext wird genau einmal angezeigt — wir speichern nur einen Hash, nicht den Schlüssel selbst, es gibt also keine Möglichkeit, ihn „wiederherzustellen“, wenn du ihn verlierst. Dann bleibt nur: löschen und einen neuen erstellen.

Jede Anfrage nutzt Standard-Bearer-Authentifizierung:

Authorization: Bearer jm_your_key

Behandle den Schlüssel wie ein Passwort — committe ihn nicht in ein öffentliches Repository, poste ihn nicht in einen Chat, damit dir jemand beim Debuggen hilft. Falls du vermutest, dass er geleakt ist, geh zurück zu /account/api-keys, lösche ihn und erstelle einen neuen; der alte funktioniert sofort nicht mehr.

Schritt 2: Dienst und Land auswählen

Für eine Bestellung brauchst du zwei Dinge: service (ein Dienst-Code) und country (eine Länder-ID). Sieh dir zuerst den Katalog an:

curl https://jiema.my/api/v1/services \
  -H "Authorization: Bearer jm_your_key"

Jeder Eintrag hat ein code-Feld (Telegram ist tg) — gib das direkt an den Bestell-Endpunkt weiter, das ist zuverlässiger, als selbst einen Slug zusammenzubauen. Um aktuelle Preise und Bestand für einen bestimmten Dienst über alle Länder zu sehen, füge den Parameter service hinzu:

curl "https://jiema.my/api/v1/prices?service=tg" \
  -H "Authorization: Bearer jm_your_key"

Jeder Eintrag in items hat countryId / priceCents / count (aktuell verfügbare Nummern). Prüfe count, bevor du bestellst — steht dort eine Null, schlägt die Bestellung garantiert fehl, verschwende also keinen Aufruf darauf, das erst auf die harte Tour herauszufinden.

Schritt 3: Bestellung aufgeben

curl -X POST https://jiema.my/api/v1/orders \
  -H "Authorization: Bearer jm_your_key" \
  -H "Content-Type: application/json" \
  -d '{"service":"tg","country":"6"}'

Eine erfolgreiche Bestellung liefert eine Telefonnummer und ein Ablaufdatum zurück:

{
  "ok": true,
  "data": {
    "id": "cm...",
    "status": "WAITING",
    "phone": "62812xxxxxxx",
    "expiresAt": "2026-08-01T12:15:00.000Z",
    "chargedCents": "40"
  }
}

Die Abbuchung passiert in diesem Schritt — chargedCents ist der tatsächlich abgezogene Betrag (in Cent). Gib diese Nummer an die Ziel-App weiter, um den Verifizierungscode zu empfangen, und geh dann zum nächsten Schritt.

Schritt 4: Auf den Code pollen

Es gibt weder WebSocket noch Webhook-Push — den SMS-Inhalt bekommst du, indem du GET /api/v1/orders/:id pollst, bis smsBody nicht mehr null ist:

while true; do
  RESP=$(curl -s https://jiema.my/api/v1/orders/$ORDER_ID \
    -H "Authorization: Bearer jm_your_key")
  BODY=$(echo "$RESP" | jq -r '.data.smsBody')
  if [ "$BODY" != "null" ]; then
    echo "Code received: $BODY"
    break
  fi
  sleep 5
done

Fünf Sekunden sind ein vernünftiger Ausgangspunkt — die Nummer bleibt 15 Minuten gültig, und das Limit von 60 Anfragen pro Minute für Lesezugriffe lässt reichlich Spielraum. Drei Sekunden funktionieren auch, wenn du ungeduldig bist; einmal pro Sekunde zu pollen bringt den Code nicht schneller, es verbraucht nur schneller dein Ratenlimit.

Stolperfallen

• Ratenlimits gelten pro Nutzer, nicht pro Schlüssel. Schreib-Endpunkte (order / cancel / next-sms) sind auf 10 pro Minute und Nutzer begrenzt, Lesezugriffe auf 60 pro Minute. Zusätzliche Schlüssel zu erstellen bringt keine höhere Grenze — sie teilen sich alle dieselbe.
• Nummern laufen nach 15 Minuten ab. Eine ungenutzte Nummer, die ohne empfangenen Code abläuft, wird automatisch erstattet — du musst nichts beantragen. Wenn deine eigene Pipeline aber zu lange braucht, bis sie die Nummer tatsächlich nutzt (etwa weil sie in einer Warteschlange hängt), ist sie schon tot, wenn sie an der Reihe ist.
• Eine Nummer kann mehr als einen Code empfangen. Wenn die Ziel-App die SMS in zwei Schritten schickt (erst eine Registrierungsbestätigung, dann ein separater Login-Code), rufe nach dem Eintreffen der ersten POST /api/v1/orders/:id/next-sms auf, um uns zu sagen „damit bin ich fertig, warte weiter“ — ohne eine neue Bestellung für eine weitere Nummer aufgeben zu müssen.
• Sobald ein Code angekommen ist, funktioniert das Stornieren nicht mehr. POST /api/v1/orders/:id/cancel erstattet sofort, solange die Nummer noch auf einen Code wartet. Sobald smsBody einmal nicht null war, liefert derselbe Aufruf stattdessen einen CODE_RECEIVED-Fehler — du hast bereits bekommen, wofür du bezahlt hast, das lässt sich nicht zurückdrehen.
• Nicht nur einmal den Status prüfen und aufgeben. status wechselt von WAITING zu RECEIVED. Bleibt er bis zum Ablauf bei WAITING stehen, liegt das meist an der Zustellrate genau dieser Land/Dienst-Kombination — eine neue Bestellung in einem anderen Land aufzugeben führt in der Regel schneller zum Ziel als abzuwarten.

Wie geht's weiter

Damit ist der Hauptablauf von der Bestellung bis zum Code abgedeckt. Die vollständige Feldliste, Fehlercodes und Grenzfälle zu jedem Endpunkt findest du unter /api-docs. Wenn du das in großem Maßstab betreibst — etwa die Verifizierung für Dutzende Accounts gleichzeitig am Laufen hältst — dann takte das Polling jeder Bestellung unabhängig. Reihe sie nicht in einer einzigen seriellen Schleife auf, sonst laufen die älteren Nummern ab, während du noch auf die erste wartest.