When something happens, tell your own systems.
A deal is won, a lead is qualified, leave is approved, an invoice is paid, a contract is signed. An automation that starts on that event can call your endpoint with the fields you choose — no polling, and no integration to buy.
How it works.
- Pick the event.
Each module publishes its events to automations — for example
crm.deal.won,hrm.leave.approvedorsales.invoice.paid. The workflow starts every time it fires. - Add an HTTP request step. Choose the method and URL, add headers, and build the body from the event's fields. Each request can wait up to 60 seconds for your endpoint.
- Decide what happens on failure. Retry the step up to five times, or let the rest of the workflow carry on.
- Read every run. The run inspector shows each run of the workflow, step by step — what was sent and whether it succeeded.
What your endpoint receives.
Exactly the body you build. For a deal-won workflow with a shared-secret header:
POST https://your-service.example.com/hooks/deals
Content-Type: application/json
X-Shared-Secret: <your secret, set on the step as {{ resource.deals_webhook_secret }}>
{
"event": "crm.deal.won",
"dealId": "{{ id }}"
} What to know today.
- Public addresses only
- Requests to private and internal network addresses are refused, so a workflow cannot reach inside your own network by mistake.
- No signature yet
- Requests are not signed. Send a secret in a header and check it before your endpoint does anything.
- Design for repeats
- A retried step can deliver the same event more than once, so make your endpoint safe to call twice with the same data.
- Same rules as everyone
- A workflow runs within the permissions of the person who built it, and its runs are recorded like any other change in Odexy.
Send your first event.
Build it in Automations: a trigger, one HTTP request step, and your endpoint.
