Meldings-ID (tidligere SMS-ID)
Hver melding som sendes gjennom BulkGate, får sin egen Melding-ID. Det er den eneste verdien som lar oss spore én bestemt melding – i portalen, i API-svaret og hos leverandøren som leverer den. Tidligere het den SMS-ID; det er samme verdi, bare med nytt navn underveis, fordi vi for lengst har sluttet å sende bare SMS.
Hva meldings-ID-en er
Melding-ID er en tekstidentifikator for én melding til én mottaker.
- BulkGate tildeler den automatisk i det øyeblikket meldingen blir akseptert. Du kan ikke velge den selv eller endre den i ettertid.
- Den gjelder én melding til ett nummer. Sender du en kampanje til tusen numre, opprettes tusen forskjellige
Melding-ID-verdier, ikke én felles. - Formen varierer etter hvilket grensesnitt du sender gjennom. Behandle den som en ugjennomsiktig tekststreng – ikke utled dato, kanal eller noe annet fra den, og prøv aldri å lage en selv.
Hvis du vil merke meldinger med en egen verdi – et ordrenummer, en kunde-ID – er det Tag (TAG) som er beregnet på det, ikke Melding-ID. Forskjellen er beskrevet i Hvordan den skiller seg fra de andre identifikatorene.
Hvorfor den tidligere het SMS-ID
Navnet SMS-ID stammer fra tiden da BulkGate bare sendte SMS. I dag går Viber, WhatsApp og RCS samme vei, og identifikatoren heter derfor Melding-ID – i portalen og i de nyere grensesnittene.
De eldre API-ene har imidlertid ikke endret navnet på feltet, for ikke å ødelegge eksisterende integrasjoner:
| Hvor | Hva feltet heter |
|---|---|
| Portal | Melding-ID |
Simple API, Advanced API versjon 1.0 |
sms_id |
Advanced API versjon 2.0, Integration API, engangspassord |
message_id |
| Leveringsbekreftelse (webhook) | smsID |
I alle tilfeller er det samme verdi. Tar du sms_id fra et svar fra Simple API og søker etter den i historikken under Melding-ID, finner du nettopp den meldingen.
Hvor du finner ID-en i portalen
- Klikk på
Rapporteri menyen - Klikk på
Historie - Klikk på raden med meldingen – detaljene folder seg ut
Melding-IDstår på høyre side av detaljene; et klikk markerer hele verdien, slik at du kan kopiere den
Det fungerer også motsatt vei: Når du allerede har Melding-ID og vil finne meldingen, åpner du Filter over tabellen og limer inn verdien i feltet Melding-ID. Den samme verdien er også med når du eksporterer historikken til CSV.
Hva historikken viser og hvordan du filtrerer den, er beskrevet i Historikk.
Meldingsteksten lagres ikke i historikken for alltid – eldre oppføringer viser Denne meldingen er utløpt i stedet. Melding-ID og de andre detaljene blir værende.
Hvor du finner ID-en i API-svaret
Grensesnittene returnerer Melding-ID direkte i svaret på sendeforespørselen – det er det eneste øyeblikket du får den programmatisk, så lagre den i dette steget.
| Grensesnitt | Hva feltet heter |
|---|---|
| Simple API | sms_id |
| Advanced API `1.0` | sms_id |
| Advanced API `2.0` | message_id |
| Integration API | message_id |
| Engangspassord | message_id |
I tillegg returnerer hvert av dem også en part_id-matrise – den er beskrevet i Hva part_id er.
Ved masseutsendelse inneholder svaret en response-matrise med en egen oppføring for hver mottaker. Melding-ID slutter da med meldingens løpenummer i satsen:
Hva part_id er
En lang SMS overleveres ikke til operatørens nett i ett stykke – den deles opp i flere separate meldinger som mottakerens telefon setter sammen igjen. Hver av disse delene har sin egen ID, og part_id er listen over dem. Når og hvorfor en melding blir delt opp, er beskrevet i Sammenkjedede meldinger.
Matrisen følger tre regler:
- Det siste elementet tilsvarer alltid
Melding-ID– det har ikke noe suffiks. - De foregående delene har suffiksene
_1,_2og så videre, i den rekkefølgen meldingen settes sammen. - En melding som ikke ble delt opp, har ett enkelt element i
part_id, identisk medMelding-ID. Det gjelder alle SMS-er i én del og alle Viber-, WhatsApp- og RCS-meldinger – de deles aldri opp.
Svaret for en SMS som er delt i tre deler, ser derfor slik ut:
Hver del belastes som en egen SMS. Antallet elementer i part_id er derfor også antallet meldinger du betaler for – tre i eksempelet over, selv om du sendte én.
For å koble sammen svar og leveringsbekreftelser trenger du bare Melding-ID. part_id er nyttig når du allerede ved sending vil vite hvor mange deler meldingen ble delt i, uten å vente på at den dukker opp i historikken.
Hvor du finner ID-en i en webhook
Leveringsbekreftelsen kommer til adressen du har angitt, og Melding-ID ligger i parameteren smsID. Bruk den til å koble bekreftelsen til meldingen du sendte.
- Enkeltvis kommer forespørselen som
GETmed verdiene i spørrestrengen – se Leveringsbekreftelse. - Samlet kommer én
POST-forespørsel med en matrise av oppføringer iJSON– se Samlet leveringsbekreftelse.
Hvor adressen for leveringsbekreftelser angis, er beskrevet i Webhooks.
Én melding kan utløse flere bekreftelser med samme smsID – status 2 betyr at meldingen står i kø hos operatøren og at resultatet kommer senere. Regn med å se den samme verdien mer enn én gang.
Innkommende meldinger og svar, som du kjenner igjen på status med verdien 10, har ingen smsID-parameter. De er ikke en bekreftelse på en melding du har sendt, men en ny melding fra mottakeren.
Hva meldings-ID-en brukes til
- Melde fra om et leveringsproblem. Uten
Melding-IDkan vi ikke spore en bestemt melding hos leverandøren. Hele fremgangsmåten er beskrevet i Meldingen ble ikke levert – du kan legge ved opptil tre forskjelligeMelding-ID-verdier i én henvendelse. - Kobling i ditt eget system. Lagre
Melding-IDfra API-svaret sammen med ordren eller kunden, og koble innkommende leveringsbekreftelser til dem via parameterensmsID. - Finne en melding i historikken.
Melding-IDer det eneste filteret som fører til nøyaktig én melding; søker du på nummer eller kampanje, finner du flere.
Hvordan den skiller seg fra de andre identifikatorene
Meldingsdetaljene i historikken viser flere identifikatorer ved siden av Melding-ID. De er lette å forveksle, men hver av dem svarer på et annet spørsmål:
| Identifikator | Hva den identifiserer | Hvem som angir den |
|---|---|---|
Melding-ID |
Én melding til én mottaker | BulkGate |
Kampanje-ID |
En hel kampanje, altså alle meldinger som ble sendt sammen | BulkGate |
Tag (TAG) |
Alt du merker selv – en ordre, en kunde, en kjøring av et skript | Du |
Application ID |
Applikasjonen meldingen ble sendt fra | BulkGate |
Tag (TAG) er den eneste av dem du angir selv. Fyller du den ut ved sending, kan du senere filtrere historikken etter den uten å kjenne noen Melding-ID – praktisk når du trenger å finne alle meldinger som hører til én ordre.
Takk for tilbakemeldingen.