Actualizar una marca de mensajería

Corregir una marca de mensajería existente

Actualice la marca existente cuando cambien los datos de contacto de la empresa o su dirección. Conserve el identificador de la marca; crear otro registro no es la forma de corregir los datos de una empresa existente. Utilice una cuenta de API habilitada a través de HTTPS desde una dirección IP de origen permitida. La marca debe pertenecer a esa cuenta.

Empiece por consultar el registro actual. Mantenga su copia local en privado, ya que contiene información de identidad y contacto de la empresa.

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

Conservar los campos actuales de la marca

Prepare brand-update.json a partir del registro actual, seleccionando únicamente los campos de la marca que se pueden modificar. Conserve la identidad de la empresa y los demás valores obligatorios al aplicar la corrección prevista. No envíe la respuesta GET completa: brandId, los resultados de identidad y estado, las marcas de tiempo y los demás campos exclusivos de la respuesta no deben incluirse en la actualización.

El esquema de actualización exige entityType, displayName, country, email y brandRelationship. Las reglas específicas de cada tipo de entidad siguen siendo aplicables. En el caso de una organización, conserve su razón social, identificador fiscal y país emisor, dirección y sector, según corresponda. En el caso de un empresario individual, conserve en su lugar los campos pertinentes de nombre personal y contacto móvil. Utilice los valores reales y actuales, no los valores de muestra de un ejemplo de registro.

Grupos de campos para actualizar la marca
Campos	Cómo utilizarlos
displayName, email, phone	Nombre de marca reconocible y datos de contacto válidos. Longitudes máximas: 255, 100 y 20 caracteres. Utilice el formato telefónico internacional con + y el código de país.
street, city, state, postalCode, country	Una dirección real de la empresa cuyos datos sean coherentes. Límites: 255, 100, 20, 10 y 2 caracteres. Utilice los códigos vigentes de los estados de Estados Unidos cuando corresponda.
entityType, companyName, ein, einIssuingCountry	Identidad legal. Estos cambios están restringidos cuando hay campañas o procesos de evaluación externa pendientes o activos. No elimine campañas en funcionamiento simplemente para eludir una restricción de identidad.
firstName, lastName, mobilePhone, businessContactEmail	Datos de identidad o de contacto para verificación cuando correspondan al tipo de entidad. Límites: 100, 100, 20 y 255 caracteres.
brandRelationship, vertical	Códigos actuales de relación y sector. Los cambios de relación se limitan a uno cada tres meses. El formulario de edición habitual del portal no permite cambiar la relación.
website, altBusinessIdType, altBusinessId, stockSymbol, stockExchange	Sitio web, identificación empresarial alternativa y datos de empresa cotizada, según corresponda. Conserve los valores necesarios para la validación de la entidad.
referenceId, ipAddress	Metadatos admitidos de referencia empresarial y de IP de origen. Ninguno establece a qué cuenta pertenece la marca ni actúa como clave de idempotencia de la solicitud.

Utilice los catálogos de mensajería vigentes para consultar los códigos. El esquema de actualización no ofrece mock como forma de cambiar el entorno de una marca. Utilice el flujo independiente y revisado de paso del entorno de pruebas a producción en lugar de cambiar ese indicador durante una edición.

Enviar la corrección revisada

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"

Utilice una sola clave para esta actualización prevista y conserve los bytes exactos del cuerpo de la solicitud. Reutilizarla con un método, una ruta, una consulta o un cuerpo distintos genera un conflicto; cambiar el formato de JSON también modifica la huella digital. Una solicitud duplicada mientras la original está en curso puede devolver 409 con Retry-After. Una solicitud completada puede volver a devolver su resultado guardado, incluido un error. Conserve los detalles de la solicitud al esclarecer el resultado tras agotarse el tiempo de espera, en lugar de generar automáticamente una clave nueva.

Verificar el registro guardado y el estado de validación

Una actualización correcta devuelve HTTP 200 y directamente un objeto JSON de la marca, sin la envoltura heredada de v3 con status/response. Compruebe su brandId, vuelva a consultar la misma marca mediante GET y compare los campos que pretendía modificar. La ruta pública de actualización no acepta la envoltura changes/version del portal ni proporciona su comprobación de concurrencia optimista. Coordine a quienes editen simultáneamente; una clave de idempotencia evita los envíos duplicados, pero no los cambios de otra persona que edite.

El portal actual consulta la marca, conserva sus campos modificables, comprueba la versión del formulario antes de guardar y vuelve a consultar el resultado. Bloquea los campos principales de identidad legal cuando encuentra campañas activas. El registro puede imponer restricciones adicionales, incluidas las relativas a la evaluación externa, incluso cuando un formulario haya permitido editar un campo.

Guardar la información corregida no solicita automáticamente una nueva verificación de identidad ni garantiza la aprobación. La nueva verificación es una acción independiente que puede conllevar una tarifa; utilice el portal para revisar el estado actual y confirmar explícitamente cualquier cargo indicado. Las actualizaciones ordinarias de marca mediante PUT no generan un débito de registro independiente en el servicio API actual. Los cargos existentes por campañas, mensajería y otros conceptos siguen siendo independientes.

Resolver errores sin crear un registro duplicado

Consulte el estado HTTP y los detalles del error en JSON. Para 400, corrija el campo específico o respete la restricción de identidad o relación. Para 401, 403 o 404, compruebe las credenciales, la IP de origen permitida y que la marca pertenezca a la cuenta. Para 429, respete Retry-After. Puede producirse un 500 o 502 después de que el registro haya aceptado la actualización; conserve cualquier requestId y consulte el registro existente antes de volver a enviarla.

Una respuesta de actualización no vacía pero incompleta puede dejar una instantánea local incompleta; un cuerpo de respuesta correcto pero vacío puede conservar campos anteriores de la instantánea. No deduzca que los campos se han conservado a partir de un simple estado de éxito. Vuelva a consultar la marca completa y resuelva cualquier discrepancia con el servicio de asistencia. Esta guía no garantiza actualizaciones atómicas del registro, la caché local y la facturación.