Оновлення бренду для обміну повідомленнями

Виправлення наявного бренду для обміну повідомленнями

Оновлюйте наявний бренд у разі зміни контактних даних або адреси компанії. Зберігайте ідентифікатор бренду; створення іншої реєстрації не є способом виправити дані наявної компанії. Використовуйте активований обліковий запис 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 і прочитайте наявний запис перед повторним надсиланням.

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