POST
Ingest a normalized business signal
La conexión viaja en el path, no en el cuerpo, y se valida contra la tienda del token. Un connection_id de otra tienda da forbidden_connection.

El signal_id lo deriva el cliente

signal_id es requerido en el cuerpo. El servidor lo recalcula y lo verifica, pero no lo inventa por vos. La derivación es determinista:
provider_event_id es opcional: si el proveedor no da un id de entrega, la clave cae al digest canónico del payload. Tu implementación tiene que dar el mismo resultado byte a byte que la del servidor; si no, duplicate deja de funcionar. La canonicalización preserva el literal de cada número: 10 y 10.0 no son el mismo payload.

Reenviar el mismo evento es seguro

La primera vez la respuesta es status: "accepted"; la segunda, status: "duplicate", con el mismo signal_id. Un duplicate no vuelve a tocar el catálogo, así que reintentar es seguro.
source_version no puede retroceder. Una señal con una source_version anterior a la aplicada responde conflict y el catálogo queda como estaba.

Autorizaciones

Authorization
string
header
requerido

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Parámetros de ruta

connection_id
string
requerido

CrossUp connection identifier.

Minimum string length: 1

Cuerpo

application/json
signal_id
string
requerido
Minimum string length: 1
signal_type
string
requerido
Minimum string length: 1
occurred_at
string<date-time>
requerido
provider
string
requerido
Minimum string length: 1
external_resource_id
string
requerido
Minimum string length: 1
payload
any
requerido
source_version
string
requerido
Minimum string length: 1
provider_event_id
string
Minimum string length: 1

Respuesta

Signal accepted or already processed

signal_id
string
requerido
Minimum string length: 1
status
enum<string>
requerido
Opciones disponibles:
accepted,
duplicate