Актуализиране на марка за обмен на съобщения

Коригирайте съществуваща марка за обмен на съобщения

Актуализирайте съществуващата марка при промяна на фирмените данни за контакт или адреса. Запазете идентификатора на марката; създаването на друга регистрация не е начин за коригиране на данните за съществуваща фирма. Използвайте активиран API акаунт през HTTPS от разрешен изходен IP адрес. Марката трябва да принадлежи на този акаунт.

Започнете с прочитане на текущия запис. Пазете локалното си копие поверително, защото съдържа данни за идентичността на фирмата и информация за контакт.

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

Запазете текущите полета на марката

Подгответе brand-update.json от текущия запис, като изберете само полетата на марката, в които е разрешен запис. Запазете идентичността на фирмата и другите задължителни стойности, докато прилагате предвидената корекция. Не изпращайте целия отговор на GET: brandId, резултатите за идентичност и състояние, времевите отметки и другите полета, които се връщат само в отговора, не трябва да се включват в актуализацията.

Схемата за актуализиране изисква entityType, displayName, country, email и brandRelationship. Правилата, специфични за вида субект, продължават да важат. За организация запазете юридическото ѝ наименование, данъчния идентификатор и държавата на издаването му, адреса и отрасъла според приложимите изисквания. За едноличен търговец вместо това запазете съответните полета за лично име и мобилен контакт. Използвайте действителни актуални стойности, а не заместващите стойности от пример за регистрация.

Групи полета за актуализиране на марката
Полета	Как да ги използвате
displayName, email, phone	Разпознаваемо име на марката и валидни данни за контакт. Максимални дължини: 255, 100 и 20 знака. Използвайте международен формат за телефонните номера със знак + и телефонен код на държавата.
street, city, state, postalCode, country	Реален фирмен адрес със съгласувани данни. Ограничения: 255, 100, 20, 10 и 2 знака. Използвайте актуалните кодове на щатите в САЩ, когато е приложимо.
entityType, companyName, ein, einIssuingCountry	Юридическа идентичност. Тези промени са ограничени, когато кампании или външни проверки са в изчакване или са активни. Не изтривайте работещи кампании само за да заобиколите ограничение, свързано с идентичността.
firstName, lastName, mobilePhone, businessContactEmail	Данни за идентичността или контакти за потвърждение, когато са подходящи за вида субект. Ограничения: 100, 100, 20 и 255 знака.
brandRelationship, vertical	Актуални кодове за отношението към марката и отрасъла. Отношението може да се променя най-много веднъж на три месеца. Обичайният формуляр за редактиране в портала не предлага промени на отношението.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	Приложими данни за уебсайта, алтернативната идентичност на фирмата и дружеството, чиито акции се търгуват публично. Запазете стойностите, необходими за валидирането на субекта.
referenceId, ipAddress	Поддържани метаданни за фирмена референция и изходен IP адрес. Нито едно от тези полета не определя принадлежността към акаунт и не служи като ключ за идемпотентност на заявката.

Използвайте актуалните каталози за обмен на съобщения за кодовете. Схемата за актуализиране не предлага mock като начин за промяна на средата на марката. Използвайте отделния прегледан работен процес за преминаване от тестова към продукционна среда, вместо да променяте този флаг при редактиране.

Изпратете прегледаната корекция

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"

Използвайте един ключ за тази предвидена актуализация и запазете точните байтове на тялото на заявката. Повторното му използване с променен метод, път, параметри на заявката или тяло води до конфликт; преформатирането на JSON също променя отпечатъка. Дублирана заявка, чиято обработка още е в ход, може да върне 409 с Retry-After. Завършена заявка може да върне повторно запазения си резултат, включително грешка. Запазете подробностите за заявката, когато изяснявате резултата след изтичане на времето за изчакване, вместо автоматично да генерирате нов ключ.

Проверете запазения запис и състоянието на валидирането

Успешната актуализация връща HTTP 200 и директно JSON обект на марката, без старата v3 обвивка status/response. Проверете неговия brandId, след това прочетете отново същата марка чрез GET и сравнете полетата, които сте възнамерявали да промените. Публичният маршрут за актуализиране не приема обвивката changes/version на портала и не предоставя неговата оптимистична проверка за едновременни промени. Координирайте работата на редакторите, които правят промени едновременно; ключът за идемпотентност предотвратява дублирано изпращане, но не и промените на друг редактор.

Текущият портал прочита марката, запазва полетата ѝ, в които е разрешен запис, проверява версията на формуляра преди записване и прочита резултата отново. Той заключва основните полета за юридическа идентичност, когато открие активни кампании. Регистърът може да наложи допълнителни ограничения, включително ограничения за външна проверка, дори когато дадено поле е било достъпно във формуляра.

Запазването на коригираната информация не заявява автоматично нова проверка на идентичността и не гарантира одобрение. Повторната проверка е отделно действие, за което може да има такса; използвайте портала, за да прегледате текущото състояние и изрично да потвърдите всяка посочена сума за таксуване. Обичайните актуализации на марката чрез PUT не задействат отделно задължаване за регистрация в текущата API услуга. Съществуващите такси за кампании, обмен на съобщения и други услуги остават отделни.

Отстранявайте грешките, без да дублирате регистрацията

Прочетете HTTP статуса и подробностите за грешката във формат JSON. При 400 коригирайте конкретното поле или спазете ограничението за идентичността или отношението към марката. При 401, 403 или 404 проверете идентификационните данни, разрешения изходен IP адрес и принадлежността към акаунта. При 429 спазете Retry-After. Грешка 500 или 502 може да възникне, след като регистърът е приел актуализацията; запазете всеки получен requestId и прочетете съществуващия запис преди повторно изпращане.

Непразен, но непълен отговор на актуализацията може да остави непълен локален моментен запис; празното тяло на успешен отговор може да запази по-стари стойности на полетата в моментния запис. Не заключавайте, че полетата са запазени, само въз основа на статус за успех. Прочетете отново пълния запис на марката и изяснете всяко несъответствие чрез екипа за поддръжка. Това ръководство не обещава атомарни актуализации на регистъра, локалния кеш и таксуването.