Sincronizar los contactos de un sitio
POST/contacts/sync
Los clientes de un sitio conectado, hasta 500 por llamada. Es lo que llama el plugin de
WordPress para traer los usuarios, clientes y leads del sitio — y cualquier plataforma
propia con la API key de un sitio conectado también puede llamarla. La respuesta es 200
aunque fallen filas: el resultado de cada una viene en results, en el orden de envío.
POST /contacts/batch es una planilla enviada una vez. Esta ruta es lo contrario: un
sistema que reporta a las mismas personas una y otra vez, por eso sus reglas solo suman,
nunca destruyen:
- el contacto se busca primero por quién es en el sitio (
ref: el usuario 42 de WordPress), después por teléfono. Quien cambió de número sigue siendo el mismo contacto; si el número nuevo ya es de otro contacto, no se une nada y la fila vuelve conphone_conflict; - sin teléfono y sin vínculo con el sitio, no se crea a nadie (
no_phone,invalid_phone); - las etiquetas solo entran, por nombre, y las que no existen se crean. Para quitar una,
usa
removeTags; - nombre, e-mail y campos personalizados solo rellenan lo que está vacío: lo que alguien
escribió en el panel gana sobre lo que reporta el sitio. Los campos que calcula el propio
sitio (los
wc_…de WooCommerce) sobrescriben — salvo queoccurredAtsea más antiguo que el último aplicado para ese vínculo (stale_snapshot); - una baja dada en el sitio siempre vale. El consentimiento solo pasa de
unknownaopted_in, con evidencia, y nunca por encima de una baja (kept_opt_out) o de una supresión (kept_suppression); - un valor para un campo que la cuenta no tiene, o del tipo equivocado, se descarta y
aparece en
warnings— el resto de la fila se aplica; - los contactos nuevos cuentan en el tope del plan (
contact_limit_reached).
Con options.triggers en false — el valor por defecto, el de una carga inicial — no se
dispara nada: ningún flujo empieza y no sale ningún webhook contact.created. Una carga
de diez mil clientes no puede saludar a diez mil personas. Envía true para lo que acaba
de pasar en el sitio.
Idempotencia. Con la cabecera Idempotency-Key, un lote repetido tras una conexión
caída devuelve el primer resultado, con Idempotent-Replayed: true, en lugar de
aplicarse dos veces. La misma clave con otro cuerpo se rechaza con
422 idempotency_key_reused; mientras la primera solicitud sigue en curso, la repetición
recibe 409 idempotency_in_progress.
Solo la API key de un sitio conectado sincroniza — viene con el permiso contacts:sync.
Una API key común recibe 404 site_not_found, y una API key restringida a algunos
números, 403.
Request
Responses
- 200
- 401
- 402
- 403
- 404
- 409
- 413
- 422
- 429
Resultado por fila.
Token ausente, mal formado, desconocido o revocado (authentication), o cuenta
suspendida (tenant_inactive).
Sin derecho de uso (payment_required). El cuerpo trae el motivo en reason y la
salida en action: qué hacer (kind) y la página del panel donde se hace (url).
Una sesión del panel en lugar de una API key (site_key_required), una API key sin el permiso contacts:sync (key_permission_denied) o restringida a algunos números (forbidden).
La API key no está vinculada a un sitio conectado (site_not_found). Conecta el sitio de nuevo desde el plugin.
El sitio está en pausa en el panel (site_paused), o una solicitud con la misma Idempotency-Key sigue en curso (idempotency_in_progress).
El cuerpo supera 1 MB (payload_too_large). Divide el lote.
Cuerpo inválido — contacts ausente, vacío o con más de 500 filas (invalid_request, con issues) —, o la misma Idempotency-Key con otro cuerpo (idempotency_key_reused). Una fila inválida no rechaza el lote: vuelve en results como failed.
Límite de peticiones superado (rate_limit).
Response Headers
Segundos a esperar antes de reintentar.
Categoría de límite aplicada — send, media o default.
Qué cubo describen las otras cabeceras — key (la API key), session (el panel) o account (el techo de la cuenta).
Techo de peticiones de la categoría en la ventana actual.
Peticiones restantes en la ventana actual.