Üzenetküldési márka frissítése

Meglévő üzenetküldési márka adatainak javítása

Frissítse a meglévő márkát, ha megváltoznak a vállalkozás kapcsolattartási adatai vagy címe. Tartsa meg a márkaazonosítót; egy meglévő vállalkozás adatainak javításához nem új regisztrációt kell létrehozni. Használjon engedélyezett API-fiókot HTTPS-kapcsolaton keresztül, egy engedélyezett forrás-IP-címről. A márkának ehhez a fiókhoz kell tartoznia.

Először kérje le az aktuális rekordot. A helyi másolatot tartsa bizalmasan, mert a vállalkozás azonosító és kapcsolattartási adatait tartalmazza.

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

A márka jelenlegi mezőinek megőrzése

Készítse el a brand-update.json fájlt az aktuális rekordból, kizárólag a márka írható mezőit kiválasztva. A kívánt javítás elvégzése közben őrizze meg a vállalkozás azonosító adatait és a többi kötelező értéket. Ne küldje el a teljes GET-választ: a brandId, az azonossági és állapoteredmények, az időbélyegek és a többi, kizárólag válaszban szereplő mező nem része a frissítésnek.

A frissítési séma megköveteli az entityType, displayName, country, email és brandRelationship mezőket. A szervezet vagy vállalkozó típusára vonatkozó szabályok továbbra is érvényesek. Szervezet esetén őrizze meg annak hivatalos cégnevét, adóazonosítóját és az azt kiállító országot, továbbá szükség szerint a címét és az iparágát. Egyéni vállalkozó esetén ehelyett a megfelelő személynév- és mobilos kapcsolattartási mezőket őrizze meg. A tényleges aktuális értékeket használja, ne egy regisztrációs példa helyőrzőit.

A márkafrissítés mezőcsoportjai
Mezők	Használatuk
displayName, email, phone	Felismerhető márkanév és érvényes kapcsolattartási adatok. Maximális hossz: 255, 100 és 20 karakter. A telefonszámot nemzetközi formátumban, + jellel és országhívószámmal adja meg.
street, city, state, postalCode, country	A vállalkozás valós, egymással összhangban álló címadatai. Hosszkorlátok: 255, 100, 20, 10 és 2 karakter. Ahol szükséges, az Egyesült Államok államainak aktuális kódjait használja.
entityType, companyName, ein, einIssuingCountry	Hivatalos azonosító adatok. Ezek módosítása korlátozott, ha kampányok vagy külső átvilágítások függőben vannak vagy aktívak. Ne töröljön működő kampányokat pusztán azért, hogy megkerüljön egy, az azonosító adatokra vonatkozó korlátozást.
firstName, lastName, mobilePhone, businessContactEmail	Azonosító adatok vagy ellenőrzési kapcsolattartási adatok, ha az adott szervezeti vagy vállalkozói típusnál alkalmazhatók. Hosszkorlátok: 100, 100, 20 és 255 karakter.
brandRelationship, vertical	Aktuális kapcsolati és iparági kódok. A kapcsolat háromhavonta legfeljebb egyszer módosítható. A portál szokásos szerkesztési űrlapján nem lehet módosítani a kapcsolatot.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	A vonatkozó webhely, alternatív vállalkozásazonosító és tőzsdei társasági adatok. Őrizze meg a szervezet vagy vállalkozó érvényesítéséhez szükséges értékeket.
referenceId, ipAddress	A támogatott üzleti referencia és a kiinduló IP-cím metaadatai. Egyik sem határozza meg, hogy melyik fiókhoz tartozik a márka, és egyik sem szolgál a kérés idempotenciakulcsaként.

A kódokhoz használja az aktuális üzenetküldési katalógusok adatait. A frissítési séma nem kínálja a mock mezőt a márka környezetének megváltoztatására. A jelző szerkesztés közbeni módosítása helyett használja a tesztkörnyezetből az éles környezetbe történő áthelyezés külön felülvizsgált munkafolyamatát.

Az ellenőrzött javítás beküldése

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"

Ehhez a tervezett frissítéshez egyetlen kulcsot használjon, és őrizze meg a kéréstörzs pontos bájtjait. Ugyanennek a kulcsnak a használata megváltoztatott metódussal, útvonallal, lekérdezéssel vagy törzzsel ütközést okoz; a JSON újraformázása is megváltoztatja az ujjlenyomatot. Egy még folyamatban lévő kérés ismételt beküldése 409 választ adhat Retry-After fejléccel. Egy befejezett kérés visszaadhatja a mentett eredményét, beleértve a hibát is. Időtúllépés tisztázásakor őrizze meg a kérés részleteit ahelyett, hogy automatikusan új kulcsot hozna létre.

A mentett rekord és az érvényesítési állapot ellenőrzése

A sikeres frissítés HTTP 200 állapotot és közvetlenül egy, a márkát leíró JSON-objektumot ad vissza, a régi v3 status/response burkoló nélkül. Ellenőrizze a brandId értékét, majd kérje le újra ugyanazt a márkát GET kéréssel, és hasonlítsa össze a kívánt mezőket. A nyilvános frissítési útvonal nem fogadja el a portál changes/version burkolóját, és nem biztosítja annak optimista konkurenciakezelési ellenőrzését. Hangolják össze az egyidejű szerkesztést; az idempotenciakulcs az ismételt beküldést akadályozza meg, nem egy másik szerkesztő módosításait.

A jelenlegi portál lekéri a márkát, megőrzi az írható mezőit, mentés előtt ellenőrzi az űrlap verzióját, majd újra lekéri az eredményt. Ha aktív kampányokat talál, zárolja az alapvető hivatalos azonosító mezőket. A nyilvántartás további korlátozásokat is előírhat, köztük külső átvilágításhoz kapcsolódó korlátozásokat, még akkor is, ha egy mező elérhető volt az űrlapon.

A javított adatok mentése nem kér automatikusan új azonosságellenőrzést, és nem garantálja a jóváhagyást. Az újbóli ellenőrzés külön művelet, amely díjköteles lehet; a portálon tekintse át az aktuális állapotot, és kifejezetten erősítse meg az esetlegesen feltüntetett díjat. A márka szokásos PUT frissítései a jelenlegi API-szolgáltatásban nem váltanak ki külön regisztrációs díjterhelést. A meglévő kampány-, üzenetküldési és egyéb díjak továbbra is külön kezelendők.

Hibák elhárítása ismételt regisztráció nélkül

Olvassa el a HTTP-állapotot és a JSON formátumú hibarészleteket. 400 esetén javítsa az érintett mezőt, vagy tartsa be az azonosító adatokra, illetve a kapcsolatra vonatkozó korlátozást. 401, 403 vagy 404 esetén ellenőrizze a hitelesítő adatokat, az engedélyezett forrás-IP-címet és azt, hogy a márka a fiókhoz tartozik-e. 429 esetén tartsa be a Retry-After fejlécben megadott várakozási időt. 500 vagy 502 akkor is előfordulhat, ha a nyilvántartás már elfogadta a frissítést; őrizze meg az esetleges requestId értéket, és újabb beküldés előtt kérje le a meglévő rekordot.

A nem üres, de hiányos frissítési válasz hiányos helyi pillanatképet hagyhat maga után; az üres törzsű sikeres válasz esetén a pillanatkép régebbi mezőértékei megmaradhatnak. Pusztán a sikeres állapotból ne következtessen a mezők megőrzésére. Kérje le újra a márka teljes adatait, és az eltéréseket az ügyfélszolgálattal egyeztesse. Ez az útmutató nem ígéri a nyilvántartás, a helyi gyorsítótár és a számlázás atomi frissítését.