Aktualizacja marki do wysyłania wiadomości

Popraw dane istniejącej marki do wysyłania wiadomości

Zaktualizuj istniejącą markę, gdy zmienią się dane kontaktowe firmy lub adres. Zachowaj jej identyfikator; tworzenie kolejnej rejestracji nie jest sposobem na poprawienie danych istniejącej firmy. Korzystaj z aktywnego konta API przez HTTPS z dozwolonego źródłowego adresu IP. Marka musi należeć do tego konta.

Zacznij od odczytania bieżącego rekordu. Zachowaj poufność lokalnej kopii, ponieważ zawiera ona dane identyfikacyjne i kontaktowe firmy.

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID" \
  --output current-brand.json

Zachowaj bieżące pola marki

Przygotuj brand-update.json na podstawie bieżącego rekordu, wybierając wyłącznie pola marki, które można zapisywać. Wprowadzając zamierzoną poprawkę, zachowaj tożsamość firmy i pozostałe wymagane wartości. Nie wysyłaj całej odpowiedzi GET: brandId, wyniki dotyczące tożsamości i stanu, znaczniki czasu oraz inne pola występujące wyłącznie w odpowiedziach nie powinny znaleźć się w aktualizacji.

Schemat aktualizacji wymaga pól entityType, displayName, country, email i brandRelationship. Nadal obowiązują reguły właściwe dla danego typu podmiotu. W przypadku organizacji zachowaj jej prawną nazwę, identyfikator podatkowy i kraj jego wydania, a także adres i branżę, stosownie do sytuacji. W przypadku osoby prowadzącej jednoosobową działalność gospodarczą zachowaj zamiast tego odpowiednie pola imienia i nazwiska oraz kontaktowego numeru telefonu komórkowego. Używaj rzeczywistych, aktualnych wartości, a nie wartości zastępczych z przykładu rejestracji.

Grupy pól aktualizacji marki
Pola	Jak ich używać
displayName, email, phone	Rozpoznawalna nazwa marki i prawidłowe dane kontaktowe. Maksymalne długości: 255, 100 i 20 znaków. Stosuj międzynarodowy format numeru telefonu ze znakiem + i kodem kraju.
street, city, state, postalCode, country	Spójny, rzeczywisty adres firmy. Limity: 255, 100, 20, 10 i 2 znaki. W stosownych przypadkach używaj aktualnych kodów stanów USA.
entityType, companyName, ein, einIssuingCountry	Tożsamość prawna. Zmiany te podlegają ograniczeniom, gdy kampanie lub zewnętrzne procedury weryfikacyjne oczekują na realizację albo są aktywne. Nie usuwaj działających kampanii tylko po to, by obejść ograniczenie dotyczące tożsamości.
firstName, lastName, mobilePhone, businessContactEmail	Dane identyfikacyjne lub dane kontaktowe do weryfikacji, jeśli są właściwe dla danego typu podmiotu. Limity: 100, 100, 20 i 255 znaków.
brandRelationship, vertical	Aktualne kody relacji i branży. Relację można zmienić najwyżej raz na trzy miesiące. Standardowy formularz edycji w portalu nie umożliwia zmiany relacji.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	Mające zastosowanie informacje o witrynie internetowej, alternatywnej identyfikacji firmy i spółce giełdowej. Zachowaj wartości potrzebne do walidacji podmiotu.
referenceId, ipAddress	Obsługiwane metadane referencji biznesowej i źródłowego adresu IP. Żadne z tych pól nie określa przynależności do konta ani nie pełni funkcji klucza idempotencji żądania.

Korzystaj z aktualnych katalogów dotyczących wysyłania wiadomości jako źródła kodów. Schemat aktualizacji nie udostępnia mock jako sposobu zmiany środowiska marki. Skorzystaj z oddzielnej, sprawdzonej procedury przejścia ze środowiska testowego do produkcyjnego, zamiast zmieniać tę flagę podczas edycji.

Prześlij sprawdzoną poprawkę

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @brand-update.json \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID"

Użyj jednego klucza dla tej zamierzonej aktualizacji i zachowaj dokładną treść żądania, bajt po bajcie. Ponowne użycie klucza ze zmienioną metodą, ścieżką, zapytaniem lub treścią powoduje konflikt; zmiana formatowania JSON również zmienia odcisk żądania. Duplikat żądania, którego przetwarzanie nadal trwa, może zwrócić 409 z Retry-After. W przypadku zakończonego żądania zapisany wynik może zostać zwrócony ponownie, również wtedy, gdy jest błędem. Podczas wyjaśniania skutków przekroczenia czasu oczekiwania zachowaj szczegóły żądania, zamiast automatycznie generować nowy klucz.

Sprawdź zapisany rekord i stan walidacji

Pomyślna aktualizacja zwraca HTTP 200 oraz bezpośrednio obiekt marki w formacie JSON, bez starszej otoczki v3 status/response. Sprawdź jego brandId, następnie ponownie pobierz tę samą markę za pomocą GET i porównaj pola objęte zamierzoną zmianą. Publiczna trasa aktualizacji nie przyjmuje otoczki changes/version używanej przez portal ani nie zapewnia jego optymistycznej kontroli współbieżności. Uzgadniaj równoczesne edycje z innymi osobami; klucz idempotencji zapobiega ponownemu przesłaniu tego samego żądania, ale nie zmianom wprowadzanym przez inną osobę.

Obecny portal odczytuje markę, zachowuje jej pola dostępne do zapisu, sprawdza wersję formularza przed zapisaniem i ponownie odczytuje wynik. Blokuje podstawowe pola tożsamości prawnej, gdy wykryje aktywne kampanie. Rejestr może nakładać dodatkowe ograniczenia, w tym wynikające z zewnętrznych procedur weryfikacyjnych, nawet jeśli formularz udostępniał dane pole do edycji.

Zapisanie poprawionych informacji nie powoduje automatycznego zlecenia nowej weryfikacji tożsamości ani nie gwarantuje zatwierdzenia. Ponowna weryfikacja jest oddzielną czynnością, która może wiązać się z opłatą; sprawdź bieżący stan w portalu i wyraźnie potwierdź każdą podaną opłatę. Zwykłe aktualizacje marki metodą PUT nie powodują oddzielnego obciążenia za rejestrację w obecnej usłudze API. Dotychczasowe opłaty za kampanie, wysyłanie wiadomości i inne usługi pozostają odrębne.

Rozwiąż błędy bez tworzenia zduplikowanej rejestracji

Odczytaj status HTTP i szczegóły błędu w formacie JSON. Przy 400 popraw wskazane pole lub zastosuj się do ograniczenia dotyczącego tożsamości bądź relacji. Przy 401, 403 lub 404 sprawdź dane uwierzytelniające, dozwolony źródłowy adres IP i przynależność do konta. Przy 429 zastosuj się do Retry-After. Błąd 500 lub 502 może wystąpić po przyjęciu aktualizacji przez rejestr; zachowaj requestId, jeśli go otrzymano, i odczytaj istniejący rekord przed kolejnym przesłaniem.

Niepusta, ale niekompletna odpowiedź na aktualizację może pozostawić niekompletny lokalny obraz danych; pusta treść odpowiedzi oznaczającej sukces może pozostawić starsze pola w tym obrazie. Nie wnioskuj o zachowaniu pól na podstawie samego statusu powodzenia. Ponownie odczytaj kompletne dane marki i wyjaśnij wszelkie rozbieżności z pomocą techniczną. Ten przewodnik nie gwarantuje atomowych aktualizacji rejestru, lokalnej pamięci podręcznej i rozliczeń.