Webhooks overview

Call+ webhooks push signed HTTPS POST requests to an endpoint you register with us, so your systems can react to Call+ business events without polling. The first available event, plan.launched, carries the figures a payroll system needs to prepare the fiche complémentaire for a launched plan: the benefit in kind (ATN/VAA), the professional withholding tax (précompte professionnel) and the social contributions, plus the identifiers to match the beneficiary, the employer and the accounting firm.

Webhooks are not part of the simulation request flow. Running a simulation with POST /api/v1/simulations never triggers a webhook — a simulation is a hypothetical calculation. The plan.launched event is sent later, only if and when a Call+ plan is actually launched. See The plan.launched event.

Delivery model

Subscriptions. You only receive the event types your integration is subscribed to. New event types are opt-in — you will never start receiving an event type you did not ask for.
Per-firm consent. For events that carry an accounting firm's data, delivery additionally requires that firm's explicit consent, with an agreed activation date. You only receive events for firms that opted in, and only for plans launched from that date onward. See Delivery, retries & onboarding.
Signed requests. Every delivery is signed with a shared secret (HMAC-SHA256). Always verify the signature before trusting a payload. See Verifying webhook signatures.
At-least-once. The same event can be delivered more than once (retries, redelivery after an outage). Deduplicate on eventId — it is stable for the lifetime of the event.
No ordering guarantee. Treat each event independently.

One envelope for every event

Every webhook body uses the same envelope; only data varies per event type:

{
  "eventId": "3f8e9a3c-6a68-4c69-9a1d-1f9f8b1f2a34",
  "eventType": "plan.launched",
  "apiVersion": 1,
  "occurredAt": "2026-08-10T12:00:00+02:00",
  "data": { }
}

Field	Description
`eventId`	UUID, unique per event — use it as your idempotency key.
`eventType`	The event type, e.g. `plan.launched`. Also sent as the `X-Callplus-Event-Type` header.
`apiVersion`	Integer schema version of this event type. Each event type is versioned independently.
`occurredAt`	ISO 8601 timestamp of when the event was recorded on our side.
`data`	Event-specific payload.

Within an apiVersion, changes are additive — parse leniently and ignore fields you do not recognize. A breaking change bumps the apiVersion of that event type only.

Event catalog

Event type	What it carries	Status
`plan.launched`	Fiche complémentaire figures and matching identifiers at plan launch	Available
`plan.updated`	Corrected figures or dates after launch	Planned
`plan.settled`	Dénouement: exit date and exit value	Planned
`simulation.completed`	Simulation result summary	Planned

What v1 does not do

No correction events. If figures or dates change after launch (exceptional), no follow-up event is sent in v1 — plan.updated is the planned successor.
No cancellation events.
No pull API. Webhooks are push-only; there is no endpoint to re-fetch past events. If you missed a delivery, contact us and we can redeliver it.