Skicka in en katalogpost för ett telefonnummer

Skicka in en katalogpost till operatören

Skicka in det namn och den adress som ska användas för en katalogpost för ett behörigt telefonnummer som du äger i MultiTEL. Detta är en avgiftsbelagd uppdatering hos operatören, inte en sökning efter uppringarens namn, en post i en privat adressbok eller en allmän uppdatering av portalens LIDB-fält i nummerregistret.

Skicka endast in uppgifter som kunden har godkänt för en katalogpost. Bekräfta att operatören stöder numret innan du använder denna äldre anropsväg. Den granskade hanteraren kontrollerar varken om leverantören är behörig eller om numret har internationellt format; begäran till operatören förutsätter ett nordamerikanskt nummer och tar bort den första lagrade siffran.

Krav på konto och nummer

Använd ett aktiverat API-konto via HTTPS från en tillåten käll-IP-adress. Det exakta numret måste finnas som en ej makulerad post för ett köpt nummer som tillhör kontot. Använd samtliga siffror i det internationella numret i ditt nummerregister, exempelvis formatet med landskod 1 för ett nordamerikanskt nummer som stöds. Använd inte ett prisplans-ID, ett nummers UUID eller ett nummer som tillhör ett annat konto.

POST-begäran med formulärdata

Ange NUMBER som det nummer du äger. Ersätt det fiktiva exemplet med de godkända kataloguppgifterna. Denna anropsväg läser formulärfält från POST; den tolkar inte en begärandekropp 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"

Exemplets väderstrecksangivelser och adress är platshållare, inte en rekommenderad postadress. Lägg inte till en påhittad väderstrecksangivelse i riktiga kunduppgifter. Kontrollerna av obligatoriska fält i API är ytliga: de fastställer inte att en adress är giltig eller accepteras av operatören, och den äldre webbplatsen hade andra formulärkrav.

Implementationen kan ge en varning om en saknad arraynyckel när en valfri väderstrecksangivelse saknas eller är tom. Om svaret är felaktigt formaterat eller operatören avvisar adressen ska du spara begärans referens och be supporten bekräfta katalogposten i stället för att upprepade gånger skicka in ändrade adressgissningar.

Debitering och upprepade försök

Den granskade hanteraren kontrollerar att saldot är minst 10.00 saldoenheter innan den kontaktar operatören. När både operatören och den lokala nummeruppdateringen har rapporterat att åtgärden lyckades drar den av 10.00 från kontosaldot och registrerar en transaktion för upprättande av katalogposten. Detta är de belopp som för närvarande är implementerade, inte ett nytt prisförslag; kontrollera den tillämpliga faktureringsvalutan och vilken tjänst som stöds mot dina kontovillkor innan du skickar in begäran.

Åtgärden saknar idempotensnyckel, skydd mot dubbla beställningar och en transaktion som omsluter inskickandet till operatören, den lokala uppdateringen och debiteringen. En upprepad begäran som lyckas kan leda till ett nytt inskickande till operatören och en ny avgift. En timeout eller ett API-fel bevisar inte att operatören avvisade den tidigare begäran: leverantören kan ha accepterat den innan en lokal uppdatering misslyckades.

Svar

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

Det normala svaret vid en lyckad åtgärd innehåller en tom sträng i response och returnerar varken ett ID för katalogposten eller uppgifter om slutförandet. Det betyder att operatörsflödet och den lokala uppdateringen rapporterade att åtgärden lyckades; det bevisar inte publicering i alla externa kataloger, omedelbar spridning eller framtida visning av uppringaridentitet.

Fel i den äldre implementationen

Läs både HTTP-statusen och följande fält i JSON: status.code/status.msg. Autentisering och begränsningar för käll-IP-adresser kan också förhindra ett användbart svar. Använd inte GET eller frågeparametrar för att begära en uppdatering bara för att den äldre hanteraren saknar en uttrycklig kontroll av HTTP-metoden.

Kontrollera innan du försöker igen

1. Bekräfta numret du äger, att operatörens behörighetskrav är uppfyllda, de godkända kataloguppgifterna och avgiften innan du skickar begäran.
2. Skicka in begäran en gång och spara resultatet på kontosidan utan att exponera kundens adress i offentliga loggar eller analysdata.
3. Kontrollera den sparade katalogposten och transaktionshistoriken via det kontoflöde som stöds eller via supporten. Avvakta operatörens bekräftade handläggningstid; detta API anger ingen garanterad tidsgräns för spridning.
4. Om resultatet är osäkert ska du låta supporten stämma av operatörsbeställningen och den lokala debiteringen innan du försöker igen. En upprepad begäran är inte en idempotent statuskontroll.