# Drift av SMS API: status, feil og gjentakelser

Canonical URL: https://www.intellipush.com/sms-api-drift/

En praktisk driftsplan for integrasjoner: OAuth-token, idempotens, usikre svar og forskjellen mellom opprettet og levert SMS.

## Hold forretningshendelsen og sendingen sammen

Lagre en intern hendelsesreferanse, planlagt mottaker og innholdsversjon før sending. Knytt meldings-ID fra Intellipush til denne referansen når opprettelsen lykkes. Dette er en anbefalt applikasjonsmodell, ikke en ekstra garanti fra API-et.

Hent token med POST /restv2/token, HTTP Basic og grant_type=client_credentials som formdata. Token er ugjennomsiktig, varer 3 600 sekunder og har ikke refresh token. Mellomlagre det på serveren til kort før utløp; ikke hent nytt token for hver SMS.

## Gjør gjentakelser til samme logiske sending

Den offentlige kontrakten dokumenterer Idempotency-Key for SMS-opprettelse. Lag en unik, uforutsigbar nøkkel for hver logiske forespørsel og lagre den før første forsøk. Bruk samme nøkkel og identiske aksepterte felt i samme rekkefølge ved gjentakelse innen 24 timer. Nøkler avgrenses til konto, OAuth-klient og operasjon.

Uten headeren er opprettelsen ikke idempotent. Et tidsavbrudd kan bety at svaret ble borte etter at meldingen ble opprettet. Ikke erstatt dette med en ny nøkkel og blind ny sending. Kontroller dokumenterte funksjoner for kontoen og send usikre tilfeller til avklaring.

- 409 idempotency_in_progress: vent som angitt i Retry-After, og behold nøkkel og data.
- 409 idempotency_conflict: undersøk feil i nøkkel- eller datahåndtering; ikke bytt nøkkel automatisk for å tvinge gjennom en sending.
- 503 idempotency_temporarily_unavailable: kontrakten sier at ingen SMS er opprettet; prøv senere med samme nøkkel.

## Skill tekniske feil fra leveringsutfall

HTTP-status er fasit for forespørselen. Håndter 400 (ugyldig input/forretningsregel), 401 (manglende eller ugyldig autentisering), 403 (ikke tillatt), 405 (feil metode), 409 og 5xx eksplisitt. Bruk dokumenterte errorcode-verdier når de finnes; status_message er tekst for mennesker.

Et HTTP 200 fra opprettelse bekrefter ikke levering. Bruk returnert ID med POST /restv2/sms/status og id_array. Feltene sent_to_operator og confirmed_delivered skiller videresending fra bekreftet levering. En levert-status er heller ikke en lesebekreftelse.

## Velg statusoppfølging bevisst

Den gjeldende API-kilden beskriver statusoppslag, /events og signerte /webhooks. Kontroller /capabilities og dokumentasjonen før dere velger mekanisme. Ved webhooks må signaturen verifiseres mot nøyaktig request-body, og event_id må dedupliseres før vellykket svar. Ikke anta lik tilgjengelighet for alle kontoer.

Logg interne referanser, meldings-ID, tidspunkt, HTTP-status og X-Request-ID for feilsøking. X-Request-ID er en støttereferanse, ikke en idempotensnøkkel. Unngå å logge tokens, hemmeligheter og meldingsinnhold uten et dokumentert behov.

## En liten testmatrise før lansering

Test ett kontrollert nummer og lavt volum etter egen godkjenning. Kontroller tokenutløp, ugyldige data, gjentakelse med samme nøkkel, nøkkelkonflikt og tapt svar. Dokumenter hvordan sending kan stanses, hvem som følger opp feil og når en uavklart melding eskaleres. Nettstedets eksempler er ikke en sandkasse.

[Gjeldende API-referanse](https://api.intellipush.com/restv2/developer/)

[Rå OpenAPI-kontrakt](https://api.intellipush.com/restv2/developer/intellipush.yaml)

[Start med integrasjonsevalueringen](https://www.intellipush.com/integrasjoner/)

Reviewed: 2026-10-30