Actualizarea unei mărci pentru mesagerie

Corectați o marcă existentă pentru mesagerie

Actualizați marca existentă atunci când se schimbă datele de contact ale firmei sau o adresă. Păstrați identificatorul mărcii; crearea unei alte înregistrări nu este o modalitate de a corecta datele unei firme existente. Folosiți un cont API activat, prin HTTPS, de la o adresă IP sursă permisă. Marca trebuie să aparțină acelui cont.

Începeți prin a citi înregistrarea curentă. Păstrați confidențială copia locală, deoarece conține date de identificare și de contact ale firmei.

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

Păstrați câmpurile curente ale mărcii

Pregătiți brand-update.json pornind de la înregistrarea curentă, selectând numai câmpurile mărcii care pot fi scrise. Păstrați datele de identificare ale firmei și celelalte valori obligatorii în timp ce aplicați corecția dorită. Nu trimiteți întregul răspuns GET: brandId, rezultatele privind identitatea/starea, marcajele temporale și celelalte câmpuri disponibile numai în răspuns nu trebuie incluse în actualizare.

Schema de actualizare impune câmpurile entityType, displayName, country, email și brandRelationship. Regulile specifice tipului de entitate se aplică în continuare. Pentru o organizație, păstrați denumirea legală a firmei, identificatorul fiscal și țara emitentă, adresa și domeniul de activitate, după caz. Pentru un întreprinzător individual, păstrați în schimb câmpurile relevante pentru numele persoanei și contactul pe telefonul mobil. Folosiți valorile reale și actuale, nu valorile substitutive dintr-un exemplu de înregistrare.

Grupuri de câmpuri pentru actualizarea mărcii
Câmpuri	Cum se folosesc
displayName, email, phone	Un nume de marcă ușor de recunoscut și date de contact valide. Lungimi maxime: 255, 100 și 20 de caractere. Folosiți formatul telefonic internațional cu +indicativul țării.
street, city, state, postalCode, country	O adresă reală a firmei, cu date coerente. Limite: 255, 100, 20, 10 și 2 caractere. Folosiți codurile actuale ale statelor din SUA, acolo unde este cazul.
entityType, companyName, ein, einIssuingCountry	Identitatea juridică. Aceste modificări sunt restricționate atunci când campaniile sau evaluările externe sunt în așteptare ori active. Nu ștergeți campanii funcționale doar pentru a ocoli o restricție privind identitatea.
firstName, lastName, mobilePhone, businessContactEmail	Date de contact pentru identificare sau verificare, atunci când sunt adecvate tipului de entitate. Limite: 100, 100, 20 și 255 de caractere.
brandRelationship, vertical	Codurile actuale ale relației și ale domeniului de activitate. Relația poate fi modificată cel mult o dată la trei luni. Formularul obișnuit de editare din portal nu permite modificarea relației.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	Site-ul web, datele alternative de identificare a firmei și detaliile privind societatea listată la bursă, după caz. Păstrați valorile necesare pentru validarea entității.
referenceId, ipAddress	Metadatele acceptate privind referința firmei și adresa IP de origine. Niciuna nu stabilește cărui cont îi aparține marca și nici nu servește drept cheie de idempotență a cererii.

Folosiți versiunile actuale ale cataloagelor de mesagerie pentru coduri. Schema de actualizare nu oferă mock ca modalitate de a schimba mediul unei mărci. Folosiți fluxul separat și revizuit de trecere din mediul de testare în producție, în loc să modificați acel indicator printr-o editare.

Trimiteți corecția revizuită

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"

Folosiți o singură cheie pentru această actualizare și păstrați exact octeții corpului cererii. Reutilizarea ei cu o metodă, o cale, parametri de interogare sau un corp modificat provoacă un conflict; reformatarea JSON schimbă și ea amprenta. O cerere duplicată aflată în curs de procesare poate returna 409 cu Retry-After. O cerere finalizată poate returna din nou rezultatul salvat, inclusiv o eroare. Păstrați detaliile cererii atunci când clarificați situația unei expirări a timpului de așteptare, în loc să generați automat o cheie nouă.

Verificați înregistrarea salvată și starea validării

O actualizare reușită returnează HTTP 200 și direct un obiect JSON al mărcii, fără structura de încadrare status/response din vechea versiune v3. Verificați valoarea brandId, apoi citiți din nou aceeași marcă prin GET și comparați câmpurile vizate. Ruta publică de actualizare nu acceptă structura changes/version a portalului și nu oferă verificarea optimistă a concurenței disponibilă în portal. Coordonați persoanele care editează simultan; o cheie de idempotență împiedică trimiterea duplicată, nu modificările făcute de altă persoană.

Portalul actual citește marca, păstrează câmpurile care pot fi scrise, verifică versiunea formularului înainte de salvare și citește din nou rezultatul. Blochează câmpurile de bază ale identității juridice atunci când găsește campanii active. Registrul poate impune restricții suplimentare, inclusiv restricții privind evaluarea externă, chiar dacă un câmp era disponibil în formular.

Salvarea informațiilor corectate nu solicită automat o nouă verificare a identității și nu garantează aprobarea. Reverificarea este o acțiune separată, care poate presupune o taxă; folosiți portalul pentru a consulta starea curentă și pentru a confirma explicit orice taxă indicată. Actualizările obișnuite ale mărcii prin PUT nu declanșează o debitare separată pentru înregistrare în serviciul API actual. Taxele existente pentru campanii, mesagerie și alte servicii rămân separate.

Rezolvați erorile fără a crea o înregistrare duplicată

Citiți codul de stare HTTP și detaliile erorii în JSON. Pentru 400, corectați câmpul indicat sau respectați restricția privind identitatea/relația. Pentru 401, 403 sau 404, verificați datele de autentificare, adresa IP sursă permisă și faptul că marca aparține contului. Pentru 429, respectați Retry-After. O eroare 500 sau 502 poate apărea după ce registrul a acceptat actualizarea; păstrați orice requestId și citiți înregistrarea existentă înainte de o nouă trimitere.

Un răspuns de actualizare care nu este gol, dar este incomplet, poate lăsa o copie locală incompletă; un corp gol al unui răspuns de succes poate păstra câmpuri mai vechi în copia locală. Nu deduceți că s-au păstrat câmpurile doar dintr-un cod de stare de succes. Citiți din nou datele complete ale mărcii și rezolvați orice neconcordanță prin serviciul de asistență. Acest ghid nu promite actualizări atomice ale registrului, memoriei cache locale și facturării.