Zgłaszanie wpisu numeru telefonu do spisu abonentów

Zgłaszanie wpisu do spisu abonentów operatora

Prześlij nazwę i adres do wpisu w spisie abonentów dla obsługiwanego numeru telefonu należącego do Ciebie w MultiTEL. Jest to płatna aktualizacja u operatora, a nie wyszukiwanie nazwy dzwoniącego, wpis w prywatnej książce adresowej ani ogólna aktualizacja pola LIDB w ewidencji portalu.

Przesyłaj wyłącznie dane, na których umieszczenie w spisie abonentów klient wyraził zgodę. Przed użyciem tej starszej ścieżki potwierdź, że operator obsługuje dany numer. Przeanalizowany moduł obsługi nie sprawdza, czy dany dostawca jest obsługiwany, ani nie weryfikuje międzynarodowego formatu numeru; żądanie wysyłane do operatora zakłada numer północnoamerykański i usuwa pierwszą zapisaną cyfrę.

Wymagania dotyczące konta i numeru

Korzystaj z aktywnego konta API przez HTTPS z dozwolonego źródłowego adresu IP. Dokładnie ten numer musi figurować jako nieunieważniony rekord zakupionego numeru przypisany do tego konta. Użyj pełnego międzynarodowego ciągu cyfr z ewidencji, na przykład formatu z kodem kraju 1 dla obsługiwanego numeru północnoamerykańskiego. Nie używaj identyfikatora planu taryfowego, identyfikatora UUID numeru ani numeru należącego do innego konta.

Żądanie POST z danymi formularza

Ustaw NUMBER na należący do Ciebie numer. Zastąp fikcyjny przykład autoryzowanymi danymi wpisu. Ta ścieżka odczytuje pola formularza z żądania POST; nie analizuje treści żądania w formacie 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"

Oznaczenia kierunku i adres w przykładzie są danymi zastępczymi, a nie zalecanym adresem pocztowym. Nie dodawaj fikcyjnego oznaczenia kierunku do rzeczywistych danych klienta. Kontrole pól wymaganych przez interfejs API są powierzchowne: nie potwierdzają poprawności adresu ani jego akceptacji przez operatora, a starsza witryna stosowała inne wymagania dotyczące formularza.

Implementacja może wyświetlić ostrzeżenie o brakującym kluczu tablicy, gdy opcjonalne oznaczenie kierunku nie występuje lub jest puste. Jeśli odpowiedź ma nieprawidłowy format albo operator odrzuci adres, zachowaj identyfikator żądania i poproś pomoc techniczną o potwierdzenie wpisu, zamiast wielokrotnie przesyłać kolejne zgadywane warianty adresu.

Opłaty i skutki ponawiania żądań

Przeanalizowany moduł obsługi sprawdza, czy saldo wynosi co najmniej 10.00 jednostek salda przed skontaktowaniem się z operatorem. Gdy operator zgłosi powodzenie i lokalna aktualizacja numeru również zakończy się powodzeniem, moduł odlicza 10.00 od salda konta i zapisuje transakcję utworzenia wpisu w spisie abonentów. Są to kwoty obecnie stosowane w implementacji, a nie nowa propozycja cenowa; przed wysłaniem żądania potwierdź właściwą walutę rozliczeniową i obsługiwaną usługę na podstawie warunków swojego konta.

Operacja nie ma klucza idempotencji, zabezpieczenia przed powieleniem zlecenia ani transakcji obejmującej wysłanie żądania do operatora, lokalną aktualizację i rozliczenie. Ponowione żądanie zakończone powodzeniem może spowodować kolejne zgłoszenie do operatora i naliczenie kolejnej opłaty. Przekroczenie limitu czasu lub błąd API nie dowodzi, że operator odrzucił wcześniejsze żądanie: dostawca mógł je zaakceptować, zanim lokalna aktualizacja zakończyła się niepowodzeniem.

Odpowiedź

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

Standardowa odpowiedź powodzenia zawiera pusty ciąg znaków w polu response i nie zwraca identyfikatora wpisu ani szczegółów zakończenia operacji. Oznacza to, że ścieżki obsługi operatora i lokalnej aktualizacji zgłosiły powodzenie; nie dowodzi to publikacji w każdym zewnętrznym spisie, natychmiastowego rozpowszechnienia danych ani ich przyszłego wyświetlania w identyfikacji dzwoniącego.

Błędy starszej implementacji

Sprawdź zarówno status HTTP, jak i następujące pola w odpowiedzi JSON: status.code/status.msg. Uwierzytelnianie i ograniczenia źródłowego adresu IP również mogą uniemożliwić uzyskanie użytecznej odpowiedzi. Nie żądaj aktualizacji metodą GET ani za pomocą parametrów zapytania tylko dlatego, że starszy moduł obsługi nie zawiera jawnej kontroli metody HTTP.

Sprawdź przed ponowieniem żądania

1. Przed wysłaniem żądania potwierdź, że numer należy do Ciebie, że operator go obsługuje oraz że dane wpisu są autoryzowane, a wysokość opłaty znana.
2. Wyślij żądanie raz i zachowaj wynik po stronie konta, nie ujawniając adresu klienta w publicznych dziennikach ani danych analitycznych.
3. Sprawdź zapisany wpis i historię transakcji za pomocą obsługiwanej procedury na koncie lub pomocy technicznej. Odczekaj czas przetwarzania potwierdzony przez operatora; ten interfejs API nie określa gwarantowanego terminu rozpowszechnienia danych.
4. Gdy wynik jest niepewny, przed kolejną próbą poproś pomoc techniczną o uzgodnienie zlecenia u operatora z lokalnym rozliczeniem. Ponowione żądanie nie jest idempotentnym sprawdzeniem statusu.