Uppdatera ett varumärke för meddelanden

Korrigera ett befintligt varumärke för meddelanden

Uppdatera det befintliga varumärket när företagets kontaktuppgifter eller adress ändras. Behåll varumärkets ID; en ny registrering är inte rätt sätt att korrigera uppgifterna för ett befintligt företag. Använd ett aktiverat API-konto via HTTPS från en tillåten käll-IP-adress. Varumärket måste tillhöra det kontot.

Börja med att läsa den aktuella posten. Skydda din lokala kopia från obehörig åtkomst eftersom den innehåller företagets identitets- och kontaktuppgifter.

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

Behåll de aktuella varumärkesfälten

Skapa brand-update.json utifrån den aktuella posten och välj endast skrivbara varumärkesfält. Behåll företagets identitetsuppgifter och övriga obligatoriska värden när du gör den avsedda korrigeringen. Skicka inte hela GET-svaret: brandId, resultat för identitet och status, tidsstämplar och andra fält som endast förekommer i svar ska inte ingå i uppdateringen.

Uppdateringsschemat kräver entityType, displayName, country, email och brandRelationship. Reglerna för respektive verksamhetsform gäller fortfarande. För en organisation ska du behålla dess juridiska företagsnamn, skatteidentifierare och utfärdandeland samt adress och bransch i tillämpliga fall. För en enskild näringsidkare ska du i stället behålla de relevanta fälten för personnamn och mobilkontakt. Använd verkliga, aktuella värden, inte platshållarna från ett registreringsexempel.

Fältgrupper för varumärkesuppdatering
Fält	Så använder du dem
displayName, email, phone	Ett igenkännbart varumärkesnamn och giltiga kontaktuppgifter. Maximala längder: 255, 100 och 20 tecken. Ange telefonnummer i internationellt format med + och landskod.
street, city, state, postalCode, country	En verklig företagsadress med uppgifter som stämmer överens. Gränser: 255, 100, 20, 10 och 2 tecken. Använd aktuella koder för amerikanska delstater där det är tillämpligt.
entityType, companyName, ein, einIssuingCountry	Juridisk identitet. Ändringar av dessa uppgifter är begränsade när kampanjer eller extern granskning väntar på behandling eller är aktiva. Radera inte fungerande kampanjer enbart för att kringgå en identitetsbegränsning.
firstName, lastName, mobilePhone, businessContactEmail	Identitetsuppgifter eller kontaktuppgifter för verifiering när de är tillämpliga för verksamhetsformen. Gränser: 100, 100, 20 och 255 tecken.
brandRelationship, vertical	Aktuella relations- och branschkoder. Relationen får ändras högst en gång var tredje månad. Portalens vanliga redigeringsformulär erbjuder inte ändringar av relationen.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	Tillämpliga uppgifter om webbplats, alternativ företagsidentitet och börsnotering. Behåll de värden som behövs för att validera verksamheten.
referenceId, ipAddress	Metadata som stöds för företagsreferens och ursprunglig IP-adress. Inget av dessa fält anger kontotillhörighet eller fungerar som begärans idempotensnyckel.

Använd de aktuella meddelandekatalogerna för att hitta koder. Uppdateringsschemat erbjuder inte mock som ett sätt att ändra ett varumärkes miljö. Använd det separata, granskade arbetsflödet för övergång från sandlåda till produktion i stället för att ändra den flaggan vid redigering.

Skicka den granskade 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"

Använd en och samma nyckel för den här avsedda uppdateringen och spara begärans brödtext med exakt samma byte. Att återanvända nyckeln med en ändrad metod, sökväg, frågesträng eller brödtext orsakar en konflikt; även omformatering av JSON ändrar fingeravtrycket. En dubblett av en pågående begäran kan ge 409 med Retry-After. En slutförd begäran kan återge sitt sparade resultat, även ett fel. Spara begärans uppgifter när du utreder en tidsgränsöverskridning i stället för att automatiskt generera en ny nyckel.

Kontrollera den sparade posten och valideringsstatusen

En lyckad uppdatering returnerar HTTP 200 och varumärket direkt som ett JSON-objekt, utan det äldre omslaget status/response från v3. Kontrollera dess brandId, hämta sedan samma varumärke igen med GET och jämför de avsedda fälten. Den publika uppdateringsrutten tar inte emot portalens changes/version-omslag och erbjuder inte dess optimistiska samtidighetskontroll. Samordna dem som redigerar samtidigt; en idempotensnyckel förhindrar dubbla inskickningar, men inte en annan redigerares ändringar.

Den nuvarande portalen läser varumärket, behåller dess skrivbara fält, kontrollerar formulärets version före sparandet och läser sedan resultatet igen. Den låser de centrala fälten för juridisk identitet när den hittar aktiva kampanjer. Registret kan införa ytterligare begränsningar, inklusive begränsningar som rör extern granskning, även när ett fält har varit tillgängligt i ett formulär.

Att spara korrigerade uppgifter begär inte automatiskt en ny identitetsverifiering och garanterar inte ett godkännande. Omverifiering är en separat åtgärd som kan medföra en avgift; använd portalen för att granska aktuell status och uttryckligen bekräfta eventuell angiven avgift. Vanliga PUT-uppdateringar av varumärken utlöser ingen separat registreringsdebitering i den nuvarande API-tjänsten. Befintliga avgifter för kampanjer, meddelanden och annat förblir separata.

Åtgärda fel utan att registrera en dubblett

Läs HTTP-statusen och felinformationen i JSON. Vid 400 ska du korrigera det aktuella fältet eller följa begränsningen för identitet eller relation. Vid 401, 403 eller 404 ska du kontrollera inloggningsuppgifter, tillåten käll-IP-adress och kontotillhörighet. Vid 429 ska du följa Retry-After. Ett fel med status 500 eller 502 kan uppstå efter att registret har accepterat uppdateringen; spara eventuellt requestId och läs den befintliga posten innan du skickar på nytt.

Ett uppdateringssvar som inte är tomt men är ofullständigt kan lämna en ofullständig lokal ögonblicksbild; en tom brödtext i ett lyckat svar kan göra att äldre fält i ögonblicksbilden finns kvar. Dra inte slutsatsen att fälten har bevarats enbart utifrån en lyckad status. Läs tillbaka hela varumärket och red ut eventuella avvikelser med supporten. Den här guiden garanterar inte atomära uppdateringar av registret, den lokala cachen och faktureringen.