Send inn en katalogoppføring for et telefonnummer

Send inn en katalogoppføring til operatøren

Send inn navnet og adressen som skal brukes i en katalogoppføring for et støttet telefonnummer du eier i MultiTEL. Dette er en betalt oppdatering hos operatøren, ikke et oppslag av innringerens navn, en privat adressebokoppføring eller en generell oppdatering av LIDB-feltet i portalens nummeroversikt.

Send bare inn opplysninger kunden har godkjent for en katalogoppføring. Bekreft at operatøren støtter nummeret før du bruker denne eldre ruten. Den gjennomgåtte behandlingsrutinen kontrollerer ikke om leverandøren støttes eller om nummeret har internasjonalt format; forespørselen til operatøren forutsetter et nordamerikansk nummer og fjerner det første lagrede sifferet.

Krav til konto og nummer

Bruk en aktivert API-konto over HTTPS fra en tillatt kilde-IP-adresse. Det nøyaktige nummeret må finnes i en ikke-annullert rad for kjøpte numre som tilhører kontoen. Bruk alle sifrene i det internasjonale nummeret i nummeroversikten, for eksempel formatet med landskode 1 for et støttet nordamerikansk nummer. Ikke bruk en prisplan-ID, nummerets UUID eller et nummer som tilhører en annen konto.

POST-forespørsel med skjemadata

Sett NUMBER til nummeret du eier. Erstatt de oppdiktede eksempelopplysningene med de godkjente opplysningene for katalogoppføringen. Denne ruten leser skjemafelt fra POST; den tolker ikke en forespørselskropp av typen application/json.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --data-urlencode "lastname=EXAMPLE" \
  --data-urlencode "firstname=EXAMPLE" \
  --data-urlencode "streetnum=1" \
  --data-urlencode "streetname=Example" \
  --data-urlencode "streetpredir=N" \
  --data-urlencode "streetpostdir=W" \
  --data-urlencode "city=Example City" \
  --data-urlencode "state=NY" \
  --data-urlencode "postalcode=10001" \
  "https://api.multitel.net/v3/directory/$NUMBER"

Himmelretningsangivelsene og adressen i eksemplet er plassholdere, ikke en anbefalt postadresse. Ikke legg til en oppdiktet himmelretning i faktiske kundeopplysninger. Kontrollene av obligatoriske felt i API-et er overfladiske: de fastslår ikke at en adresse er gyldig eller godtas av operatøren, og det eldre nettstedet brukte andre skjemakrav.

Implementasjonen kan gi en advarsel om en manglende arraynøkkel når en valgfri himmelretningsangivelse mangler eller er tom. Hvis svaret har feil format eller operatøren avviser adressen, tar du vare på forespørselsreferansen og ber kundestøtte bekrefte oppføringen i stedet for å sende inn gjentatte, gjetningsbaserte adresseendringer.

Belastning og gjentatte forsøk

Den gjennomgåtte behandlingsrutinen kontrollerer at saldoen er på minst 10.00 saldoenheter før den kontakter operatøren. Etter at både operatøren og den lokale nummeroppdateringen har meldt om vellykket behandling, trekker den 10.00 fra kontosaldoen og registrerer en transaksjon for opprettelse av katalogoppføringen. Dette er beløpene som er implementert nå, ikke et nytt prisforslag; bekreft gjeldende faktureringsvaluta og støttet tjeneste mot kontovilkårene før innsending.

Operasjonen har ingen idempotensnøkkel, beskyttelse mot dupliserte bestillinger eller transaksjon som omfatter innsending til operatøren, lokal oppdatering og fakturering. En gjentatt forespørsel som lykkes, kan føre til en ny innsending til operatøren og en ny belastning. Et tidsavbrudd eller en API-feil beviser ikke at operatøren avviste den tidligere forespørselen: leverandøren kan ha godtatt den før en lokal oppdatering mislyktes.

Svar

{
  "status": {
    "code": 200,
    "msg": "Success"
  },
  "response": ""
}

Et vanlig svar ved vellykket behandling har en tom streng i feltet response og returnerer verken oppførings-ID eller detaljer om fullføring. Det betyr at behandlingen hos operatøren og den lokale oppdateringen meldte om vellykket resultat; det beviser ikke publisering i alle eksterne kataloger, umiddelbar spredning av endringen eller fremtidig visning av anrops-ID.

Feil i den eldre implementasjonen

Les både HTTP-statusen og følgende felt i JSON-svaret: status.code/status.msg. Autentisering og begrensninger på kilde-IP-adresser kan også hindre et brukbart svar. Ikke bruk GET eller spørringsparametere for å be om en oppdatering bare fordi den eldre behandlingsrutinen ikke har en uttrykkelig kontroll av HTTP-metoden.

Kontroller før du prøver på nytt

1. Bekreft nummeret du eier, at operatøren støtter det, de godkjente oppføringsopplysningene og gebyret før du sender forespørselen.
2. Send inn én gang og ta vare på resultatet på kontosiden uten å eksponere kundens adresse i offentlige logger eller analysesystemer.
3. Kontroller den lagrede oppføringen og transaksjonshistorikken gjennom den støttede arbeidsflyten for kontoen eller via kundestøtte. Vent ut behandlingstiden operatøren har bekreftet; dette API-et angir ingen garantert frist for spredning av endringen.
4. Når resultatet er usikkert, ber du kundestøtte avstemme bestillingen hos operatøren mot den lokale faktureringen før du prøver på nytt. En gjentatt forespørsel er ikke en idempotent statuskontroll.