POST
Ingest a normalized business signal
The connection travels in the path, not in the body, and is checked against the token’s store. A connection_id from another store returns forbidden_connection.

The client derives the signal_id

signal_id is required in the body. The server recomputes and checks it, but doesn’t make it up for you. The derivation is deterministic:
provider_event_id is optional: if the provider gives no delivery id, the key falls back to the payload’s canonical digest. Your implementation must match the server’s byte for byte; otherwise duplicate stops working. Canonicalization keeps each number’s literal: 10 and 10.0 are not the same payload.

Resending the same event is safe

The first time the response is status: "accepted"; the second, status: "duplicate", with the same signal_id. A duplicate doesn’t touch the catalog again, so retrying is safe.
source_version can’t go backwards. A signal with a source_version older than the applied one returns conflict and the catalog stays as it was.

Authorizations

Authorization
string
header
required

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

Path Parameters

connection_id
string
required

CrossUp connection identifier.

Minimum string length: 1

Body

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

Response

Signal accepted or already processed

signal_id
string
required
Minimum string length: 1
status
enum<string>
required
Available options:
accepted,
duplicate