SMS API Dokumentation

Wie request_id funktioniert

1. Zeigen Sie die Zählungen mit action=preview an. Es wird kein request_id benötigt und es werden keine Datensätze gelöscht.
2. Generieren Sie eine eindeutige request_id für eine neue Löschung, zum Beispiel eine UUID. Speichern Sie es vor dem Senden von action=delete.
3. Für Wiederholungen, Timeouts oder HTTP 202 verwenden Sie den gleichen API-Schlüssel, den Historienendpunkt, den request_id- und den include_linked-Wert erneut. Generieren Sie niemals automatisch eine neue ID nach einem Fehler.
4. Wenn completed=true, ist die Operation beendet. Die Wiederverwendung seiner ID gibt das gleiche Ergebnis zurück, anstatt neu angekommene Datensätze zu löschen. Verwenden Sie eine neue ID nur für eine bewusst neue Bereinigung.

request_id identifiziert Ihren Löschvorgang, nicht einen individuellen SMS. Erlaubtes Format: 16–128 ASCII Buchstaben, Ziffern, Bindestriche oder Unterstriche. Geeignet ist ein mit crypto.randomUUID() erzeugtes UUID.

Die Löschung erfolgt stapelweise. Bei HTTP 202 mit continue_required=true wiederholen Sie action=delete nach 3 Sekunden. Es gibt keinen Hintergrund-Cron. action=status liest nur den Fortschritt und setzt die Löschung nicht fort, auch bei HTTP 200.

Lösch- und Statusbeispiele

Ersetzen Sie das Beispiel request_id durch Ihren eigenen eindeutigen Wert, bevor Sie beginnen. Die folgenden Löschanforderungen ändern den realen Kontoverlauf; sie sind keine Vorschau.

curl -X POST "https://api.smsmobileapi.com/delete-history-sms-api/" \
  --data-urlencode "apikey=YOUR_API_KEY" \
  -d "action=delete" -d "include_linked=0" \
  -d "request_id=6d54ac58-41f1-4fbc-9a39-6e6c86089451"

curl -X POST "https://api.smsmobileapi.com/delete-history-sms-api/" \
  -H "Authorization: Bearer YOUR_OAUTH_ACCESS_TOKEN" \
  -d "action=delete" -d "include_linked=0" \
  -d "request_id=6d54ac58-41f1-4fbc-9a39-6e6c86089451"

curl -G "https://api.smsmobileapi.com/delete-history-sms-api/" \
  --data-urlencode "apikey=YOUR_API_KEY" \
  -d "action=status" \
  -d "request_id=6d54ac58-41f1-4fbc-9a39-6e6c86089451"

GET akzeptiert auch action=preview oder action=delete. POST wird empfohlen: URL-Parameter können in den Browserverlauf und die Serverprotokolle gelangen. Legen Sie niemals eine Lösch-URL in einen öffentlichen Link, ein Bild oder einen Prefetch ein.

Senden Sie für POST alle Parameter im Formularkörper oder einem JSON-Objekt, niemals in der Abfragezeichenfolge. Unbekannte Parameter werden abgelehnt; Datums- oder mobile Filter werden nicht unterstützt.

Authentifizierung für History-Endpunkte

Verwenden Sie apikey oder ein Authorization: Bearer-Zugriffstoken, das von SMSMobileAPI OAuth2 ausgegeben wurde. Senden Sie kein Refresh-Token oder einen API-Schlüssel als Bearer-Token. Expired Tokens werden abgelehnt.

Wenn die Bereiche festgelegt sind, erlaubt history:read Vorschau/Status und history:delete erlaubt auch das Löschen. Es gelten Einschränkungen sowohl für den Token als auch für den OAuth-Client. Legacy-Token ohne Scopes behalten ihren bestehenden Kontozugriff.

OAuth2 wählt den eindeutigen primären API-Schlüssel aus. Wenn mehrere Primärschlüssel vorhanden sind, geben Sie auch apikey an, um einen zum Konto gehörenden auszuwählen. Sekundärschlüssel gewähren niemals Zugriff auf die Primärschlüsselhistorie.

Lesen Sie die Antwort, bevor Sie fortfahren

count_delete ist die kumulative Zahl, die durch diese Operation entfernt wird. selected_at_start ist die erste Auswahl; protected_at_start zählt ausgeschlossene Datensätze. Verwenden Sie preview.linked_or_processing, um verknüpfte Datensätze zu zählen, auch wenn include_linked=1.

{
    "result": {
        "error": 0,
        "history": "sms-api",
        "action": "delete",
        "request_id": "6d54ac58-41f1-4fbc-9a39-6e6c86089451",
        "status": "processing",
        "completed": false,
        "count_delete": 100,
        "total_before": 250,
        "selected_at_start": 200,
        "protected_at_start": 50,
        "include_linked": 0,
        "continue_required": true,
        "message": "Repeat GET or POST with the same request_id and include_linked to continue. Status requests do not run deletion."
    }
}

• 200 mit completed=true: fertig. Eine 200-Vorschau oder Statusantwort allein beweist keine Vollendung.
• 400 INVALID_REQUEST_ID: Überprüfen Sie das Format. 404 REQUEST_NOT_FOUND: Es gibt keine Operation für diese ID, API-Schlüssel und Historie.
• 401: ungültige oder abgelaufene Anmeldeinformationen. 403: unzureichender OAuth-Bereich oder nicht autorisiertes Konto.
• 409 HISTORY_BUSY: eine weitere Bereinigung läuft; setzen Sie sie vom ursprünglichen Client fort. 409 INCLUDE_LINKED_CONFLICT: Wiederherstellung des ursprünglichen include_linked-Werts.
• 409 OAUTH_ACCOUNT_AMBIGUOUS: Geben Sie einen API-Schlüssel an, der zu diesem Konto gehört.
• 503 oder Netzwerkunterbrechung: Einige Batches können bereits abgeschlossen sein. Überprüfen Sie die Konfiguration und versuchen Sie es dann erneut mit dem ursprünglichen request_id. Erstellen Sie keinen Ersatzvorgang automatisch.