Webhooks
Tesser's receiver for Nexa's events (§7). Matches Tesser's existing partner-webhook convention: /v1/webhooks/circle/{organizationId}, /v1/webhooks/openfx/{workspaceId}, and so on, all POST plus HEAD.
Receive Nexa webhook (op 4)
Tesser's receiver for every Nexa-to-Tesser event (§7): the credit decision, additional-funds requests, rejections, and payout failures.
There is no payout success event. POST /v1/payments is synchronous and carries the outcome — COMPLETED, or FAILED on a synchronous decline — in its own response, so a payment.status.changed event is sent only when a failure (FAILED or RETURNED) surfaces on the rail after a COMPLETED response.
The body is the Nexa-minted envelope {event_id, event_type, occurred_at, data}; data varies by event_type; every shape is in the examples below. Tesser dedupes on event_id, so a redelivery is safe. Non-state-advancing events (quote.additional_funds_requested, metadata-only payment.status.changed) are still processed, on the first delivery of each event_id: the reachability rule governs only the quote_status field, never whether the event's content is handled.
path Parameters
organizationIdNexa's Tesser organization ID, shared during onboarding. Tesser's existing partner receivers use the organization's UUID; the POC stub accepts any opaque identifier (the portal examples use org_nexa_001). The mTLS-resolved identity must match this value.
Receive Nexa webhook (op 4) › Request Body
event_idevent_typeoccurred_atdataReceive Nexa webhook (op 4) › Responses
Delivery accepted. Nexa treats any 2xx as success; a production receiver may return a truly empty body, and the empty object below is the explicit contract this document specifies so every operation has a schema and an example. A 200 means 'received and deduped', not 'the event was reachable'. An unreachable event is also acked (and alerted on internally).
Verify webhook connectivity (op 4)
Connectivity and credential check for the receiver above, per Tesser's existing partner-webhook convention (every partner receiver is POST plus HEAD). Nexa can call it at onboarding and after certificate rotation to confirm the endpoint is reachable and its client certificate resolves to {organizationId}.
A HEAD response carries no body, so the §5 error envelope does not apply here and the status code alone is the answer. 400 is not listed because there is no request body to validate.
path Parameters
organizationIdNexa's Tesser organization ID, shared during onboarding, the same value as on the POST.
Verify webhook connectivity (op 4) › Responses
The receiver is reachable and the client certificate resolves to this organizationId. No body.