Opdater et brand til beskeder

Ret et eksisterende brand til beskeder

Opdater det eksisterende brand, når virksomhedens kontaktoplysninger eller adresse ændres. Bevar brandets ID; en ny registrering er ikke den rette måde at rette oplysninger om en eksisterende virksomhed på. Brug en aktiveret API-konto via HTTPS fra en tilladt kilde-IP-adresse. Brandet skal tilhøre den pågældende konto.

Start med at hente den aktuelle post. Hold din lokale kopi privat, da den indeholder virksomhedens identitets- og kontaktoplysninger.

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

Bevar brandets aktuelle felter

Opret brand-update.json ud fra den aktuelle post, og medtag kun de brandfelter, der kan skrives til. Bevar virksomhedens identitet og andre påkrævede værdier, mens du foretager den ønskede rettelse. Send ikke hele GET-svaret: brandId, identitets- og statusresultater, tidsstempler og andre felter, der kun indgår i svar, hører ikke til i opdateringen.

Opdateringsskemaet kræver entityType, displayName, country, email og brandRelationship. Reglerne for den enkelte enhedstype gælder stadig. For en organisation skal du bevare dens juridiske virksomhedsnavn, skatteidentifikationsnummer og udstedelsesland samt adresse og branche, hvor det er relevant. For en enkeltmandsvirksomhed skal du i stedet bevare de relevante felter for personnavn og mobilkontakt. Brug de faktiske, aktuelle værdier, ikke pladsholderne fra et registreringseksempel.

Feltgrupper til brandopdatering
Felter	Sådan bruges de
displayName, email, phone	Genkendeligt brandnavn og gyldige kontaktoplysninger. Maksimale længder: 255, 100 og 20 tegn. Brug internationalt telefonnummerformat med +landekode.
street, city, state, postalCode, country	En faktisk virksomhedsadresse med indbyrdes overensstemmende oplysninger. Grænser: 255, 100, 20, 10 og 2 tegn. Brug gældende koder for amerikanske delstater, hvor det er relevant.
entityType, companyName, ein, einIssuingCountry	Juridisk identitet. Disse ændringer er begrænsede, når kampagner eller ekstern kontrol afventer behandling eller er aktive. Slet ikke fungerende kampagner blot for at omgå en identitetsbegrænsning.
firstName, lastName, mobilePhone, businessContactEmail	Identitetsoplysninger eller kontaktoplysninger til verifikation, når det er relevant for enhedstypen. Grænser: 100, 100, 20 og 255 tegn.
brandRelationship, vertical	Aktuelle relations- og branchekoder. Relationen kan højst ændres én gang hver tredje måned. Portalens normale redigeringsformular giver ikke mulighed for at ændre relationen.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	Relevant websted, alternativ virksomhedsidentitet og oplysninger om børsnoterede selskaber. Bevar de værdier, der er nødvendige for at validere enheden.
referenceId, ipAddress	Understøttede metadata for virksomhedsreference og oprindelig IP-adresse. Ingen af dem fastlægger kontoejerskab eller fungerer som anmodningens idempotensnøgle.

Brug de aktuelle beskedkataloger til at finde koder. Opdateringsskemaet giver ikke mulighed for at bruge mock til at ændre et brands miljø. Brug den separate, gennemgåede arbejdsgang til overførsel fra sandkasse til produktion i stedet for at ændre dette flag under redigering.

Indsend den gennemgåede rettelse

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"

Brug én nøgle til denne planlagte opdatering, og bevar de nøjagtige bytes i anmodningens brødtekst. Genbrug af nøglen med en ændret metode, sti, forespørgsel eller brødtekst medfører en konflikt; omformatering af JSON ændrer også fingeraftrykket. En dublet af en igangværende anmodning kan returnere 409 med Retry-After. En afsluttet anmodning kan returnere sit gemte resultat igen, herunder en fejl. Bevar anmodningens oplysninger, når du afklarer resultatet efter en timeout, i stedet for automatisk at generere en ny nøgle.

Kontroller den gemte post og valideringsstatus

En vellykket opdatering returnerer HTTP 200 og et direkte JSON-objekt for brandet uden den ældre v3-indpakning med status/response. Kontroller dets brandId, hent derefter det samme brand igen med GET, og sammenlign de ønskede felter. Den offentlige opdateringsrute accepterer ikke portalens changes/version-indpakning og tilbyder heller ikke dens optimistiske samtidighedskontrol. Koordiner arbejdet mellem samtidige redaktører; en idempotensnøgle forhindrer gentagen indsendelse, men ikke en anden redaktørs ændringer.

Den nuværende portal henter brandet, bevarer de felter, der kan skrives til, kontrollerer formularens version før lagring og henter resultatet igen. Den låser de centrale felter for juridisk identitet, når den finder aktive kampagner. Registret kan pålægge yderligere begrænsninger, herunder begrænsninger ved ekstern kontrol, selvom et felt var tilgængeligt i en formular.

Lagring af rettede oplysninger anmoder ikke automatisk om en ny identitetsverifikation og garanterer heller ikke godkendelse. Fornyet verifikation er en separat handling, som kan medføre et gebyr; brug portalen til at gennemgå den aktuelle status og udtrykkeligt bekræfte et eventuelt oplyst gebyr. Almindelige brandopdateringer med PUT udløser ikke en særskilt debitering for registrering i den nuværende API-tjeneste. Eksisterende gebyrer for kampagner, beskeder og andet forbliver separate.

Løs fejl uden at registrere en dublet

Læs HTTP-status og fejloplysningerne i JSON. Ved 400 skal du rette det pågældende felt eller overholde identitets- eller relationsbegrænsningen. Ved 401, 403 eller 404 skal du kontrollere legitimationsoplysninger, tilladt kilde-IP-adresse og kontoejerskab. Ved 429 skal du følge Retry-After. En 500 eller 502 kan forekomme, efter at registret har accepteret opdateringen; bevar en eventuel requestId, og hent den eksisterende post, før du indsender igen.

Et opdateringssvar, som ikke er tomt, men er ufuldstændigt, kan efterlade et ufuldstændigt lokalt øjebliksbillede; en tom brødtekst i et vellykket svar kan bevare ældre felter i øjebliksbilledet. Udled ikke, at felterne er bevaret, alene ud fra en successtatus. Hent hele brandet igen, og få afklaret eventuelle uoverensstemmelser via support. Denne vejledning lover ikke atomiske opdateringer af register, lokal cache og fakturering.