Përditësoni një markë për mesazhe

Korrigjoni një markë ekzistuese për mesazhe

Përditësoni markën ekzistuese kur ndryshojnë të dhënat e kontaktit të biznesit ose një adresë. Ruani identifikuesin e markës; krijimi i një regjistrimi tjetër nuk është mënyra për të korrigjuar të dhënat e një biznesi ekzistues. Përdorni një llogari API të aktivizuar përmes HTTPS, nga një adresë IP burimore e lejuar. Marka duhet t'i përkasë asaj llogarie.

Filloni duke lexuar regjistrimin aktual. Mbajeni konfidenciale kopjen tuaj lokale, sepse ajo përmban të dhëna identifikimi dhe kontakti të biznesit.

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

Ruani fushat aktuale të markës

Përgatitni brand-update.json nga regjistrimi aktual, duke përzgjedhur vetëm fushat e markës që lejojnë shkrimin. Ruani identitetin e biznesit dhe vlerat e tjera të detyrueshme ndërsa zbatoni korrigjimin e synuar. Mos dërgoni të gjithë përgjigjen GET: brandId, rezultatet e identitetit/gjendjes, vulat kohore dhe fushat e tjera që shfaqen vetëm në përgjigje nuk duhen përfshirë në përditësim.

Skema e përditësimit kërkon entityType, displayName, country, email dhe brandRelationship. Rregullat specifike për llojin e subjektit vazhdojnë të zbatohen. Për një organizatë, ruani emrin ligjor të shoqërisë, identifikuesin tatimor dhe vendin lëshues, adresën dhe sektorin e veprimtarisë, sipas rastit. Për një sipërmarrës individual, ruani në vend të tyre fushat përkatëse të emrit personal dhe të kontaktit në celular. Përdorni vlerat reale aktuale, jo vlerat zëvendësuese nga një shembull regjistrimi.

Grupet e fushave për përditësimin e markës
Fushat	Si t'i përdorni
displayName, email, phone	Emër marke i dallueshëm dhe të dhëna kontakti të vlefshme. Gjatësitë maksimale: 255, 100 dhe 20 karaktere. Përdorni formatin ndërkombëtar të numrit të telefonit me +kodin e vendit.
street, city, state, postalCode, country	Një adresë reale biznesi me të dhëna të përputhshme. Kufijtë: 255, 100, 20, 10 dhe 2 karaktere. Përdorni kodet aktuale të shteteve të SHBA-së, kur është e zbatueshme.
entityType, companyName, ein, einIssuingCountry	Identiteti ligjor. Këto ndryshime kufizohen kur fushatat ose vlerësimet e jashtme janë në pritje apo aktive. Mos fshini fushata funksionale thjesht për të anashkaluar një kufizim të identitetit.
firstName, lastName, mobilePhone, businessContactEmail	Të dhënat e kontaktit për identifikim ose verifikim, kur janë të përshtatshme për llojin e subjektit. Kufijtë: 100, 100, 20 dhe 255 karaktere.
brandRelationship, vertical	Kodet aktuale të marrëdhënies dhe të sektorit të veprimtarisë. Ndryshimet e marrëdhënies lejohen më së shumti një herë në tre muaj. Formulari i zakonshëm i redaktimit në portal nuk ofron mundësinë për të ndryshuar marrëdhënien.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	Faqja e internetit, të dhënat alternative të identifikimit të biznesit dhe hollësitë e shoqërisë së listuar në bursë, sipas rastit. Ruani vlerat e nevojshme për validimin e subjektit.
referenceId, ipAddress	Metadatat e mbështetura për referencën e biznesit dhe adresën IP të origjinës. Asnjëra nuk përcakton se cilës llogari i përket marka dhe as nuk shërben si çelësi i idempotencës së kërkesës.

Përdorni versionet aktuale të katalogëve të mesazheve për kodet. Skema e përditësimit nuk e ofron mock si mënyrë për të ndryshuar mjedisin e një marke. Përdorni rrjedhën e veçantë dhe të shqyrtuar të punës për kalimin nga mjedisi i testimit në prodhim, në vend që ta ndryshoni atë tregues gjatë redaktimit.

Dërgoni korrigjimin e shqyrtuar

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"

Përdorni një çelës të vetëm për këtë përditësim të synuar dhe ruani saktësisht bajtet e trupit të kërkesës. Ripërdorimi i tij me metodë, shteg, parametra kërkimi ose trup të ndryshuar shkakton konflikt; riformatimi i JSON ndryshon gjithashtu gjurmën identifikuese. Një kërkesë e dyfishuar që është ende në proces mund të kthejë 409 me Retry-After. Një kërkesë e përfunduar mund të kthejë sërish rezultatin e saj të ruajtur, përfshirë një gabim. Ruani hollësitë e kërkesës kur sqaroni rezultatin pas skadimit të kohës së pritjes, në vend që të gjeneroni automatikisht një çelës të ri.

Verifikoni regjistrimin e ruajtur dhe gjendjen e validimit

Një përditësim i suksesshëm kthen HTTP 200 dhe drejtpërdrejt një objekt JSON të markës, pa strukturën mbështjellëse status/response të versionit të vjetër v3. Kontrolloni brandId të saj, më pas lexoni sërish të njëjtën markë me GET dhe krahasoni fushat e synuara. Rruga publike e përditësimit nuk pranon strukturën mbështjellëse changes/version të portalit dhe nuk ofron kontrollin e tij optimist të njëkohshmërisë. Bashkërendoni personat që redaktojnë njëkohësisht; një çelës idempotence parandalon dërgimin e dyfishtë, por jo ndryshimet nga një redaktues tjetër.

Portali aktual lexon markën, ruan fushat e saj që lejojnë shkrimin, kontrollon versionin e formularit përpara ruajtjes dhe lexon sërish rezultatin. Ai bllokon fushat bazë të identitetit ligjor kur gjen fushata aktive. Regjistri mund të vendosë kufizime shtesë, përfshirë kufizime të vlerësimit të jashtëm, edhe kur një fushë ishte e disponueshme në formular.

Ruajtja e informacionit të korrigjuar nuk kërkon automatikisht një verifikim të ri të identitetit dhe nuk garanton miratimin. Riverifikimi është një veprim i veçantë që mund të ketë tarifë; përdorni portalin për të shqyrtuar gjendjen aktuale dhe për të konfirmuar shprehimisht çdo tarifë të paraqitur. Përditësimet e zakonshme të markës me PUT nuk shkaktojnë një debitim të veçantë regjistrimi në shërbimin aktual API. Tarifat ekzistuese të fushatave, mesazheve dhe tarifat e tjera mbeten të ndara.

Zgjidhni gabimet pa krijuar një regjistrim të dyfishtë

Lexoni kodin e gjendjes HTTP dhe hollësitë e gabimit në JSON. Për 400, korrigjoni fushën përkatëse ose respektoni kufizimin e identitetit/marrëdhënies. Për 401, 403 ose 404, kontrolloni kredencialet, adresën IP burimore të lejuar dhe nëse marka i përket llogarisë. Për 429, respektoni Retry-After. Një gabim 500 ose 502 mund të ndodhë pasi regjistri ta ketë pranuar përditësimin; ruani çdo requestId dhe lexoni regjistrimin ekzistues përpara një dërgimi tjetër.

Një përgjigje përditësimi që nuk është bosh, por është e paplotë, mund të lërë një kopje lokale të paplotë; një trup bosh në përgjigjen e suksesit mund të mbajë fusha më të vjetra në kopjen lokale. Mos nxirrni përfundimin se fushat janë ruajtur vetëm nga një kod gjendjeje suksesi. Lexoni sërish të dhënat e plota të markës dhe zgjidhni çdo mospërputhje përmes shërbimit të mbështetjes. Ky udhëzues nuk premton përditësime atomike të regjistrit, memories së përkohshme lokale dhe faturimit.