Eine bestehende Marke für den Nachrichtenversand korrigieren
Aktualisieren Sie die bestehende Marke, wenn sich die geschäftlichen Kontaktdaten oder eine Adresse ändern. Behalten Sie ihre Marken-ID bei; eine weitere Registrierung anzulegen ist nicht der richtige Weg, um die Daten eines bestehenden Unternehmens zu korrigieren. Verwenden Sie ein freigeschaltetes API-Konto über HTTPS von einer zugelassenen Quell-IP-Adresse aus. Die Marke muss diesem Konto gehören.
Lesen Sie zunächst den aktuellen Datensatz aus. Bewahren Sie Ihre lokale Kopie vertraulich auf, da sie Identitäts- und Kontaktdaten des Unternehmens enthält.
curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
"https://api.multitel.net/tcr/v2/brand/$BRAND_ID" \
--output current-brand.jsonDie aktuellen Markenfelder beibehalten
Erstellen Sie brand-update.json aus dem aktuellen Datensatz und wählen Sie dabei nur beschreibbare Markenfelder aus. Behalten Sie bei der vorgesehenen Korrektur die Unternehmensidentität und andere erforderliche Werte bei. Senden Sie nicht die gesamte GET-Antwort: brandId, Identitäts- und Statusergebnisse, Zeitstempel und andere Felder, die nur in Antworten vorkommen, gehören nicht in die Aktualisierung.
Das Aktualisierungsschema erfordert entityType, displayName, country, email und brandRelationship. Die für den jeweiligen Unternehmenstyp geltenden Regeln bleiben bestehen. Behalten Sie bei einer Organisation deren rechtlichen Firmennamen, Steuerkennung und Ausstellungsland sowie gegebenenfalls Adresse und Branche bei. Behalten Sie bei einem Einzelunternehmer stattdessen die entsprechenden Felder für den Personennamen und die Mobilfunk-Kontaktdaten bei. Verwenden Sie tatsächliche aktuelle Werte und keine Platzhalter aus einem Registrierungsbeispiel.
| Felder | Verwendung |
|---|---|
| displayName, email, phone | Wiedererkennbarer Markenname und gültige Kontaktdaten. Maximale Längen: 255, 100 und 20 Zeichen. Verwenden Sie für Telefonnummern das internationale Format mit + und Landesvorwahl. |
| street, city, state, postalCode, country | Eine in sich stimmige, tatsächlich bestehende Geschäftsadresse. Begrenzungen: 255, 100, 20, 10 und 2 Zeichen. Verwenden Sie gegebenenfalls die aktuellen Kürzel der US-Bundesstaaten. |
| entityType, companyName, ein, einIssuingCountry | Rechtliche Identität. Diese Änderungen sind eingeschränkt, wenn Kampagnen oder externe Überprüfungen ausstehen oder aktiv sind. Löschen Sie keine funktionierenden Kampagnen, nur um eine Beschränkung für Identitätsänderungen zu umgehen. |
| firstName, lastName, mobilePhone, businessContactEmail | Identitätsdaten oder Kontaktdaten für die Verifizierung, soweit sie für den Unternehmenstyp zutreffen. Begrenzungen: 100, 100, 20 und 255 Zeichen. |
| brandRelationship, vertical | Aktuelle Codes für Beziehung und Branche. Die Beziehung darf höchstens einmal innerhalb von drei Monaten geändert werden. Das normale Bearbeitungsformular im Portal bietet keine Änderung der Beziehung an. |
| website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange | Zutreffende Angaben zur Website, zur alternativen Unternehmensidentifikation und zu börsennotierten Unternehmen. Behalten Sie die Werte bei, die für die Validierung des Unternehmens erforderlich sind. |
| referenceId, ipAddress | Unterstützte Metadaten zur Geschäftsreferenz und zur Ursprungs-IP-Adresse. Keines dieser Felder legt die Kontozugehörigkeit fest oder dient als Idempotenzschlüssel der Anfrage. |
Verwenden Sie die aktuellen Kataloge für den Nachrichtenversand für die Codes. Das Aktualisierungsschema bietet mock nicht als Möglichkeit an, die Umgebung einer Marke zu ändern. Verwenden Sie den gesonderten, geprüften Ablauf für den Wechsel von der Testumgebung in die Produktionsumgebung, anstatt dieses Kennzeichen bei einer Bearbeitung zu ändern.
Die geprüfte Korrektur übermitteln
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"Verwenden Sie für diese beabsichtigte Aktualisierung einen einzigen Schlüssel und bewahren Sie den Anfrageinhalt bytegenau auf. Die Wiederverwendung mit geänderter Methode, geändertem Pfad, geänderter Abfrage oder geändertem Inhalt führt zu einem Konflikt; auch eine Neuformatierung von JSON ändert den Fingerabdruck. Eine doppelte Anfrage, deren ursprüngliche Verarbeitung noch läuft, kann 409 mit Retry-After zurückgeben. Bei einer abgeschlossenen Anfrage kann das gespeicherte Ergebnis erneut ausgegeben werden, auch wenn es sich um einen Fehler handelt. Bewahren Sie beim Klären einer Zeitüberschreitung die Anfragedetails auf, anstatt automatisch einen neuen Schlüssel zu erzeugen.
Den gespeicherten Datensatz und den Validierungsstatus prüfen
Eine erfolgreiche Aktualisierung gibt HTTP 200 und direkt ein JSON-Objekt der Marke zurück, ohne die bisherige v3-Hülle status/response. Prüfen Sie dessen brandId, rufen Sie anschließend dieselbe Marke erneut mit GET ab und vergleichen Sie die vorgesehenen Felder. Die öffentliche Aktualisierungsroute akzeptiert weder die changes/version-Hülle des Portals noch bietet sie dessen optimistische Nebenläufigkeitsprüfung. Stimmen Sie gleichzeitige Bearbeitungen ab; ein Idempotenzschlüssel verhindert doppelte Übermittlungen, nicht die Änderungen eines anderen Bearbeiters.
Das aktuelle Portal liest die Marke aus, behält ihre beschreibbaren Felder bei, prüft vor dem Speichern die Formularversion und liest das Ergebnis erneut aus. Es sperrt die wesentlichen Felder der rechtlichen Identität, wenn es aktive Kampagnen findet. Die Registrierungsstelle kann zusätzliche Einschränkungen vorgeben, darunter Einschränkungen aufgrund externer Überprüfungen, selbst wenn ein Feld in einem Formular zur Bearbeitung angeboten wurde.
Das Speichern korrigierter Informationen fordert nicht automatisch eine neue Identitätsprüfung an und garantiert keine Genehmigung. Eine erneute Verifizierung ist eine gesonderte Aktion, die gebührenpflichtig sein kann; prüfen Sie den aktuellen Status im Portal und bestätigen Sie jede angegebene Gebühr ausdrücklich. Gewöhnliche Markenaktualisierungen per PUT lösen im aktuellen API-Dienst keine gesonderte Abbuchung für die Registrierung aus. Bestehende Gebühren für Kampagnen, Nachrichtenversand und andere Leistungen bleiben davon getrennt.
Fehler beheben, ohne eine doppelte Registrierung anzulegen
Lesen Sie den HTTP-Status und die Fehlerdetails in JSON. Korrigieren Sie bei 400 das betreffende Feld oder beachten Sie die Einschränkung für Identität oder Beziehung. Prüfen Sie bei 401, 403 oder 404 die Zugangsdaten, die zugelassene Quell-IP-Adresse und die Kontozugehörigkeit. Beachten Sie bei 429 die Vorgabe von Retry-After. Ein Fehler 500 oder 502 kann auftreten, nachdem die Registrierungsstelle die Aktualisierung angenommen hat; bewahren Sie eine gegebenenfalls vorhandene requestId auf und lesen Sie den bestehenden Datensatz vor einer erneuten Übermittlung aus.
Eine nicht leere, aber unvollständige Aktualisierungsantwort kann einen unvollständigen lokalen Datenstand hinterlassen; bei einem leeren Antwortinhalt trotz Erfolg können ältere Felder im lokalen Datenstand erhalten bleiben. Schließen Sie aus einem bloßen Erfolgsstatus nicht, dass die Felder beibehalten wurden. Lesen Sie den vollständigen Markendatensatz erneut aus und klären Sie etwaige Abweichungen mit dem Support. Dieser Leitfaden garantiert keine atomare Aktualisierung von Registrierungsstelle, lokalem Zwischenspeicher und Abrechnung.