POST
Ingest a normalized business signal
A conexão viaja no path, não no corpo, e é validada contra a loja do token. Um connection_id de outra loja dá forbidden_connection.

O signal_id é derivado pelo cliente

signal_id é obrigatório no corpo. O servidor o recalcula e verifica, mas não o inventa por você. A derivação é determinística:
provider_event_id é opcional: se o provedor não dá um id de entrega, a chave cai no digest canônico do payload. A sua implementação tem que dar o mesmo resultado, byte a byte, que a do servidor; senão, duplicate deixa de funcionar. A canonicalização preserva o literal de cada número: 10 e 10.0 não são o mesmo payload.

Reenviar o mesmo evento é seguro

Na primeira vez a resposta é status: "accepted"; na segunda, status: "duplicate", com o mesmo signal_id. Um duplicate não volta a mexer no catálogo, então tentar de novo é seguro.
source_version não pode retroceder. Um sinal com uma source_version anterior à aplicada responde conflict e o catálogo fica como estava.

Autorizações

Authorization
string
header
obrigatório

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

Parâmetros de caminho

connection_id
string
obrigatório

CrossUp connection identifier.

Minimum string length: 1

Corpo

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

Resposta

Signal accepted or already processed

signal_id
string
obrigatório
Minimum string length: 1
status
enum<string>
obrigatório
Opções disponíveis:
accepted,
duplicate