Hvorfor kommer ikke SMS-en frem? Leveringsstatus, feilkoder og vanlige årsaker

At et system har godtatt en SMS, betyr ikke nødvendigvis at den er levert til mottakerens telefon. Meldingen går gjennom flere trinn: fra applikasjonen eller portalen, via meldingstjenesten og mobilnettet, og til slutt til enheten. En feil kan oppstå i hvert trinn, og statusen må tolkes i riktig sammenheng.

Denne guiden forklarer de viktigste statusforskjellene og en trygg måte å feilsøke på. Nøyaktige statusverdier og felter kan endres, så gjeldende API-dokumentasjon er alltid den tekniske fasiten.

Opprettet er ikke det samme som levert

En godkjent API-forespørsel bekrefter først og fremst at meldingen er registrert for videre behandling. Den sier ikke at mottakerens telefon har mottatt meldingen. Ta vare på meldings-ID-en fra opprettelsessvaret. Når arbeidsflyten trenger leveringsinformasjon, kan denne brukes mot det dokumenterte statusendepunktet.

Det er nyttig å tenke på statusene som tre grupper:

• Registrert eller godtatt: tjenesten har mottatt oppgaven og kan begynne videre behandling.
• Sendt videre eller under behandling: meldingen er på vei gjennom leverandør- og mobilnett, men utfallet er ikke endelig.
• Endelig utfall: nettverket har rapportert levering eller en feil som ikke lenger behandles.

Navnene kan variere mellom grensesnitt og ruter. Bygg derfor logikken på den dokumenterte kontrakten, ikke på antakelser om hva et ord som «sendt» må bety.

Hva en leveringsrapport faktisk forteller

En leveringsrapport, ofte kalt DLR, er en teknisk kvittering fra meldingskjeden. En levert-status er et sterkt signal om at meldingen er nådd frem slik mobilnettet rapporterer det. Den er ikke en lesebekreftelse og beviser ikke at riktig person så, forstod eller handlet på innholdet.

En manglende endelig status betyr heller ikke automatisk at meldingen er tapt. Telefonen kan være slått av, uten dekning eller utilgjengelig i en periode. Nettverket kan fortsette å forsøke før det rapporterer et endelig utfall. Hvor lenge og hvordan dette skjer, avhenger av rute, land og operatør.

Vanlige årsaker til at en SMS ikke kommer frem

Ugyldig eller dårlig formatert nummer

Feil landskode, manglende sifre, gamle numre og tegn som følger med fra et regneark er vanlige årsaker. Normaliser nummeret før sending og behold landet som en eksplisitt del av datagrunnlaget. Bruk gjerne nummerverktøyet før import eller API-kall.

Telefonen er midlertidig utilgjengelig

Enheten kan være avslått, uten dekning, full eller frakoblet nettet. Dette kan gi en midlertidig status som senere endres. Unngå å sende samme melding på nytt manuelt før du har kontrollert om den første fortsatt behandles.

Avsenderen passer ikke mottakerlandet

Land og operatører kan ha ulike regler for alfanumeriske avsendernavn, nummer, registrering og innhold. Et oppsett som fungerer i Norge, trenger ikke fungere likt internasjonalt. Kontroller landet og avsendertypen i den internasjonale leveringsguiden og avklar særskilte behov før større utsendinger.

Innhold eller trafikk blir begrenset

Nettverk og leverandører kan reagere på forbudt innhold, villedende avsender, mistenkelige lenker, uvanlig trafikk eller manglende etterlevelse av landregler. Det betyr ikke at enhver filtrering kan forklares fra én statuskode. Samle tekniske referanser og be support undersøke den konkrete meldingen eller gruppen.

Konto, credits eller forespørsel er ikke gyldig

Autentisering, manglende obligatoriske felt, kontoens tilstand eller utilstrekkelige credits kan stoppe meldingen før den sendes videre. Slike feil bør håndteres direkte i applikasjonen og skilles fra en senere leveringsfeil i mobilnettet.

En praktisk feilsøkingsrekkefølge

1. Finn meldings-ID og tidspunkt. Ikke start med hele kontaktlisten eller en ny masseutsending.
2. Kontroller opprettelsessvaret. Var forespørselen godkjent, eller stoppet den før registrering?
3. Hent siste dokumenterte status. Skill mellom pågående og endelig utfall.
4. Kontroller mottakeren. Se på landskode, lengde og om nummeret fortsatt er aktivt.
5. Kontroller avsender og land. Bekreft at kombinasjonen støttes for den aktuelle arbeidsflyten.
6. Sammenlign et lite utvalg. Se om feilen gjelder ett nummer, én operatør, ett land eller alle meldinger.
7. Samle minimale referanser. Oppgi ID, tidspunkt, status og relevante kontodetaljer til support, uten å spre meldingstekst og persondata unødvendig.

Slik bør en API-integrasjon håndtere status

Et produksjonssystem bør lagre den tekniske meldings-ID-en sammen med sin egen referanse og skille mellom «forespørsel mottatt» og «endelig leveringsutfall». Bruk statusendepunktet slik den aktuelle dokumentasjonen beskriver. Ikke bygg avhengighet til en webhook eller annen mekanisme som ikke er bekreftet for kontoen og API-versjonen deres.

Håndter 400-, 401- og 5xx-svar eksplisitt. Ta vare på X-Request-ID ved feilsøking. Kontroller kontoens dokumenterte capabilities før du bruker valgfri idempotens, og send en stabil Idempotency-Key for samme logiske opprettelseskall. Sett også en tydelig grense for hvor lenge systemet venter på endelig status før saken flagges for manuell vurdering.

Utviklerguiden viser skillet mellom opprettet og levert, mens SMS API-siden gir en samlet inngang til integrasjon og dokumentasjon. Trenger dere hjelp med en konkret ID eller meldingsflyt, kan dere kontakte Intellipush med de tekniske referansene.