Oppdater en merkevare for meldingstjenester

Korriger en eksisterende merkevare for meldingstjenester

Oppdater den eksisterende merkevaren når bedriftens kontaktopplysninger eller adresse endres. Behold merkevarens ID; å opprette en ny registrering er ikke riktig måte å korrigere opplysningene om en eksisterende bedrift på. Bruk en aktivert API-konto over HTTPS fra en tillatt kilde-IP-adresse. Merkevaren må tilhøre denne kontoen.

Begynn med å hente den gjeldende oppføringen. Hold den lokale kopien privat, siden den inneholder bedriftens identitets- og kontaktopplysninger.

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

Behold de gjeldende merkevarefeltene

Klargjør brand-update.json fra den gjeldende oppføringen, og velg bare merkevarefelt som kan skrives til. Behold bedriftens identitetsopplysninger og andre påkrevde verdier mens du utfører den planlagte korrigeringen. Ikke send hele GET-svaret: brandId, identitets- og statusresultater, tidsstempler og andre felt som bare hører til svaret, skal ikke tas med i oppdateringen.

Oppdateringsskjemaet krever entityType, displayName, country, email og brandRelationship. Reglene for den aktuelle virksomhetstypen gjelder fortsatt. For en organisasjon skal du beholde juridisk foretaksnavn, skatteidentifikator og utstederland, adresse og bransje der dette er relevant. For et enkeltpersonforetak skal du i stedet beholde de relevante feltene for personnavn og mobilkontakt. Bruk faktiske, gjeldende verdier, ikke plassholderne fra et registreringseksempel.

Feltgrupper for merkevareoppdatering
Felt	Slik brukes de
displayName, email, phone	Gjenkjennelig merkevarenavn og gyldige kontaktopplysninger. Maksimale lengder: 255, 100 og 20 tegn. Bruk internasjonalt telefonnummerformat med + og landskode.
street, city, state, postalCode, country	En faktisk bedriftsadresse med opplysninger som stemmer overens. Grenser: 255, 100, 20, 10 og 2 tegn. Bruk gjeldende amerikanske delstatskoder der det er relevant.
entityType, companyName, ein, einIssuingCountry	Juridisk identitet. Disse endringene er begrenset når kampanjer eller ekstern vurdering venter på behandling eller er aktive. Ikke slett fungerende kampanjer bare for å omgå en identitetsbegrensning.
firstName, lastName, mobilePhone, businessContactEmail	Identitetsopplysninger eller kontaktopplysninger for verifisering der dette passer for virksomhetstypen. Grenser: 100, 100, 20 og 255 tegn.
brandRelationship, vertical	Gjeldende koder for tilknytning til merkevaren og bransje. Tilknytningen kan endres høyst én gang hver tredje måned. Portalens vanlige redigeringsskjema tilbyr ikke endringer av tilknytning.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	Relevant nettsted, alternativ bedriftsidentifikasjon og opplysninger om børsnotert selskap. Behold verdiene som trengs for å validere virksomheten.
referenceId, ipAddress	Støttede metadata for bedriftsreferanse og opprinnelig IP-adresse. Ingen av dem angir hvilken konto merkevaren tilhører eller fungerer som forespørselens idempotensnøkkel.

Bruk de gjeldende meldingskatalogene for å finne koder. Oppdateringsskjemaet tilbyr ikke mock som en måte å endre merkevarens miljø på. Bruk den separate, gjennomgåtte arbeidsflyten for overgang fra sandkasse til produksjon fremfor å endre dette flagget under redigering.

Send inn den gjennomgåtte korrigeringen

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"

Bruk én nøkkel for denne planlagte oppdateringen, og behold de nøyaktige bytene i forespørselskroppen. Gjenbruk med endret metode, sti, spørring eller kropp fører til konflikt; omformatering av JSON endrer også fingeravtrykket. En duplikatforespørsel der den opprinnelige forespørselen fortsatt behandles, kan returnere 409 med Retry-After. En fullført forespørsel kan returnere det lagrede resultatet på nytt, også hvis resultatet er en feil. Behold forespørselsdetaljene når du avklarer utfallet etter et tidsavbrudd, fremfor å generere en ny nøkkel automatisk.

Kontroller den lagrede oppføringen og valideringsstatusen

En vellykket oppdatering returnerer HTTP 200 og et merkevareobjekt direkte i JSON, uten den eldre v3-innpakningen status/response. Kontroller objektets brandId, hent deretter samme merkevare på nytt med GET, og sammenlign de aktuelle feltene. Den offentlige oppdateringsruten godtar ikke portalens changes/version-innpakning og tilbyr heller ikke dens optimistiske kontroll av samtidige endringer. Koordiner brukere som redigerer samtidig; en idempotensnøkkel hindrer duplikatinnsending, men hindrer ikke endringer fra en annen bruker.

Den nåværende portalen henter merkevaren, beholder feltene som kan skrives til, kontrollerer skjemaversjonen før lagring og henter resultatet på nytt. Den låser de sentrale feltene for juridisk identitet når den finner aktive kampanjer. Registeret kan innføre ytterligere begrensninger, blant annet begrensninger knyttet til ekstern vurdering, selv om et felt var tilgjengelig i et skjema.

Lagring av korrigerte opplysninger ber ikke automatisk om en ny identitetsverifisering og garanterer ikke godkjenning. Ny verifisering er en separat handling som kan medføre et gebyr; bruk portalen til å gjennomgå gjeldende status og uttrykkelig bekrefte et eventuelt oppgitt gebyr. Vanlige merkevareoppdateringer med PUT utløser ikke en separat belastning for registrering i den nåværende API-tjenesten. Eksisterende kostnader for kampanjer, meldinger og andre tjenester forblir separate.

Løs feil uten å opprette en duplikatregistrering

Les HTTP-statusen og feildetaljene i JSON. Ved 400 skal du korrigere det aktuelle feltet eller respektere begrensningen for identitet eller tilknytning. Ved 401, 403 eller 404 skal du kontrollere påloggingsopplysninger, tillatt kilde-IP-adresse og at merkevaren tilhører kontoen. Ved 429 skal du følge Retry-After. En 500 eller 502 kan oppstå etter at registeret har godtatt oppdateringen; behold en eventuell requestId, og hent den eksisterende oppføringen før du sender inn på nytt.

Et oppdateringssvar som ikke er tomt, men er ufullstendig, kan etterlate en ufullstendig lokal øyeblikkskopi; en tom kropp i et vellykket svar kan føre til at eldre felt i øyeblikkskopien beholdes. Ikke anta at feltene er bevart ut fra en vellykket status alene. Hent hele merkevareoppføringen på nytt, og avklar eventuelle avvik med kundestøtte. Denne veiledningen lover ikke atomiske oppdateringer av registeret, den lokale hurtigbufferen og faktureringen.