Dostęp do konta i projektu
Korzystaj z aktywnego konta API przez HTTPS z dozwolonego adresu IP. Projekt musi należeć do tego konta i nie może być usunięty. Użyj unikatowego identyfikatora projektu z procesu składania zlecenia przeniesienia, a nie jego numerycznego identyfikatora w bazie danych ani numeru telefonu. Podczas tworzenia żądania zakoduj identyfikator projektu zgodnie z zasadami kodowania adresów URL.
Żądanie
curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
"https://api.multitel.net/v3/lnp/project/$PROJECT_ID/events"Odpowiedź
Przykład fikcyjnej odpowiedzi.
{
"status": {
"code": 200,
"msg": "Project Events",
"results": 1
},
"response": [
{
"id": 31,
"subject": "Example project update",
"event": "{\"type\":\"comment\",\"value\":\"Example update\",\"source\":\"Example source\"}",
"type": "comment",
"value": "Example update",
"source": "Example source",
"date_created": "2026-10-23 12:00:00"
}
]
}Dla istniejącego projektu bez zdarzeń zwracane są kod API 200, pusta lista oraz status.results o wartości 0. Wyniki są pobierane w kolejności malejącej według czasu utworzenia, bez dodatkowego porządkowania przy jednakowych czasach, stronicowania, kursora ani filtra daty.
Uważnie interpretuj dane zdarzenia
id to numeryczny identyfikator rekordu zdarzenia, subject to jego zapisany temat, a date_created to zapisana dla niego wartość daty i czasu. Punkt końcowy zachowuje surowy ciąg znaków w polu event i próbuje również zdekodować zawarte w nim właściwości type, value i source. Jeśli dane nie są obiektem JSON lub brakuje właściwości, odpowiednie pole uzyskane po parsowaniu zawiera pusty ciąg znaków.
Dane zdarzenia nie mają postaci ustalonego typu wyliczeniowego ani gwarantowanego schematu zwykłego tekstu. Nie traktuj tekstu wskazującego źródło jako zweryfikowanej tożsamości ani nie renderuj treści zdarzeń jako HTML. Przechowuj surowe zdarzenia w autoryzowanych procesach po stronie serwera, a uprawnionym użytkownikom wyświetlaj tylko odpowiedni tekst. Ten punkt końcowy nie zapewnia osobnego filtra widoczności zdarzeń dla pracowników i klientów ani maskowania treści.
Historia nie gwarantuje dostarczenia
Jest to zapisana historia projektu, a nie strumień zdarzeń webhook, niezmienny kursor synchronizacji ani pełny rejestr wszystkich zmian w bazie danych. Na przykład dodanie numerów za pomocą sprawdzonej procedury obsługującej dodawanie numerów samo w sobie nie tworzy zdarzenia. Oprócz odczytywania zdarzeń uzgadniaj również listę numerów i liczby numerów w poszczególnych stanach.
Błędy i ograniczenia
Sprawdzaj zarówno odpowiedź HTTP, jak i status.code/status.msg. W przypadku projektu, który nie istnieje, został usunięty lub nie należy do konta, zwracany jest kod API 404 z komunikatem o nieznalezieniu projektu. Obowiązują również wymagania dotyczące uwierzytelniania i ograniczenia źródłowych adresów IP. Przykłady nie wykonują rzeczywistego żądania, a pomyślna odpowiedź nie stanowi dowodu, że operator zaakceptował lub zakończył przeniesienie numerów.
Skutki
Sprawdzona procedura obsługi odczytuje zapisane zdarzenia i nie zmienia projektu, nie rozpoczyna przeniesienia numerów ani nie obciąża konta. Widoczność mechanizmów zapisujących zdarzenia oraz testy z uwierzytelnionym dostępem do konta pozostają częścią oczekującego przeglądu kontraktu interfejsu.