Een merk voor berichtenverkeer bijwerken

Een bestaand merk voor berichtenverkeer corrigeren

Werk het bestaande merk bij wanneer de contactgegevens of het adres van het bedrijf veranderen. Behoud de merk-ID; een nieuwe registratie aanmaken is geen geschikte manier om de gegevens van een bestaand bedrijf te corrigeren. Gebruik een ingeschakeld API-account via HTTPS vanaf een toegestaan bron-IP-adres. Het merk moet eigendom zijn van dat account.

Haal eerst de huidige gegevens op. Houd uw lokale kopie privé, want deze bevat identificatie- en contactgegevens van het bedrijf.

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

De huidige merkvelden behouden

Maak brand-update.json op basis van de huidige gegevens en selecteer alleen schrijfbare merkvelden. Behoud de bedrijfsidentiteit en andere verplichte waarden terwijl u de gewenste correctie aanbrengt. Verstuur niet het volledige GET-antwoord: brandId, identiteits- en statusresultaten, tijdstempels en andere velden die uitsluitend in antwoorden voorkomen, horen niet thuis in de update.

Het updateschema vereist entityType, displayName, country, email en brandRelationship. Regels voor het betreffende entiteitstype blijven van toepassing. Behoud voor een organisatie de wettelijke bedrijfsnaam, het fiscale identificatienummer en het land van uitgifte, het adres en de bedrijfstak, voor zover van toepassing. Behoud voor een eenmanszaak in plaats daarvan de relevante velden voor de persoonsnaam en mobiele contactgegevens. Gebruik de werkelijke actuele waarden, niet de tijdelijke aanduidingen uit een registratievoorbeeld.

Gebruik de actuele catalogi voor berichtenverkeer voor de codes. Het updateschema biedt mock niet aan als manier om de omgeving van een merk te wijzigen. Gebruik de afzonderlijke, beoordeelde procedure voor de overgang van de sandbox naar productie in plaats van die vlag tijdens een bewerking te wijzigen.

De gecontroleerde correctie indienen

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"

Gebruik één sleutel voor deze beoogde update en bewaar de exacte bytes van de verzoekinhoud. Hergebruik met een gewijzigde methode, een gewijzigd pad, gewijzigde queryparameters of gewijzigde inhoud veroorzaakt een conflict; ook het opnieuw opmaken van JSON verandert de vingerafdruk. Een duplicaat van een verzoek dat nog wordt verwerkt, kan 409 met Retry-After opleveren. Bij een voltooid verzoek kan het opgeslagen resultaat opnieuw worden teruggegeven, ook als dat een fout is. Bewaar de verzoekgegevens wanneer u de uitkomst na een time-out uitzoekt, in plaats van automatisch een nieuwe sleutel te genereren.

De opgeslagen gegevens en validatiestatus controleren

Een geslaagde update retourneert HTTP 200 en rechtstreeks een JSON-object met merkgegevens, zonder de verouderde v3-envelop met status/response. Controleer de brandId, haal vervolgens hetzelfde merk opnieuw op met GET en vergelijk de beoogde velden. De openbare updateroute accepteert de changes/version-omsluiting van het portaal niet en biedt ook niet de optimistische controle op gelijktijdige wijzigingen die het portaal uitvoert. Stem gelijktijdige bewerkingen op elkaar af; een idempotentiesleutel voorkomt dubbele indiening, maar geen wijzigingen door een andere bewerker.

Het huidige portaal haalt het merk op, behoudt de schrijfbare velden, controleert de formulierversie vóór het opslaan en haalt het resultaat opnieuw op. Het vergrendelt de belangrijkste velden voor de juridische identiteit wanneer het actieve campagnes aantreft. Het register kan aanvullende beperkingen opleggen, waaronder beperkingen voor externe screening, zelfs wanneer een veld op een formulier beschikbaar was.

Het opslaan van gecorrigeerde gegevens vraagt niet automatisch een nieuwe identiteitsverificatie aan en garandeert geen goedkeuring. Herverificatie is een afzonderlijke handeling waaraan kosten verbonden kunnen zijn; bekijk de huidige status in het portaal en bevestig eventuele opgegeven kosten expliciet. Gewone merkupdates via PUT leiden in de huidige API-service niet tot een afzonderlijke afschrijving voor registratie. Bestaande kosten voor campagnes, berichtenverkeer en andere diensten blijven afzonderlijk van toepassing.

Fouten oplossen zonder een dubbele registratie aan te maken

Lees de HTTP-status en de foutdetails in JSON. Corrigeer bij 400 het betreffende veld of houd rekening met de beperking voor identiteit of relatie. Controleer bij 401, 403 of 404 de inloggegevens, het toegestane bron-IP-adres en of het merk eigendom is van het account. Houd bij 429 rekening met Retry-After. Een 500 of 502 kan optreden nadat het register de update heeft geaccepteerd; bewaar een eventuele requestId en haal de bestaande gegevens op voordat u opnieuw een verzoek indient.

Een niet-leeg maar onvolledig updateantwoord kan een onvolledige lokale momentopname achterlaten; een leeg antwoord bij een geslaagd verzoek kan oudere veldwaarden in de momentopname laten staan. Leid niet alleen uit een successtatus af dat velden behouden zijn gebleven. Haal de volledige merkgegevens opnieuw op en laat eventuele verschillen via de ondersteuning oplossen. Deze handleiding garandeert geen atomaire updates van het register, de lokale cache en de facturering.