Aller au contenu principal
FIG 0.0 · TRIGGERS

Your own event bus.

Build your own trigger, call it however you want — by webhook, on a schedule, in bulk — and if it fails, it retries on its own, then drops into a dead-letter queue with an email. A real event bus, built into your CRM. No need for Zapier or Segment on the side.

Free 14-day trial

No credit card required.

evt_8f2a · commande-recue
POST /triggers/order-receivedReceived
Signature verified · schema validatedOK
Dispatch · retry ×2 (back-off)Network
Delivered · 200 responseDone
toncrm.io triggers: the event bus with its custom triggers, their integration guide and their execution history.
FIG 0.1 · THE EVENT

A trigger, called however suits you.

A trigger is a custom event you define yourself — "order received", "file approved", "external payment", whatever your business generates. Once created, you call it whichever way suits you: by webhook from an external system, on a schedule, or in bulk. It's your own event bus, inside your CRM, instead of a third-party service to wire up.

Webhook
From an external system, in real time.
Schedule
On a recurring schedule.
Batch
Up to 100 events in a single call.
Not to be confused with workflows: workflows are the visual automation you build (the what-to-do); triggers are the event layer underneath — the entry point your external systems and custom events come through, which can then feed a workflow.
FIG 0.2 · THE INTEGRATION

Signed, and yours in two minutes.

Every trigger comes with an integration guide: copy-ready code snippets (cURL, Node, Python, PHP, batch) with your real secret already in them, so a developer wires it up in minutes instead of digging through generic docs. It's built so an integration is safe by default, not as an afterthought.

Signed webhook
Secure signature, validated on both ends.
Rate-limited
So it doesn't get hammered.
Logged exposure
You know who saw the secret.
cURLNodePythonPHP
const res = await fetch(
  "https://api.toncrm.io/triggers/commande-recue",
  {
    method: "POST",
    headers: {
      "X-Signature": sign(body, SECRET),
      "Idempotency-Key": orderId,
    },
    body: JSON.stringify({ montant: 1290, devise: "CAD" }),
  }
);
Your real secret is already in the snippet
Dead-letter · evt_8f2a
Attempt 1 — network failure
Attempts 2 to 5 — back-off
Dropped to dead-letter + email
Re-fire Discard
FIG 0.3 · RELIABILITY

Fails? It retries on its own.

If a dispatch fails — the system on the other end is down, a network error — toncrm retries automatically, spacing out the attempts, up to five times. Still nothing? The event drops into a dead-letter queue and an email goes to the owner. Nothing gets lost silently.

And the dead-letter queue is a real interface where you can re-fire or discard each event, one by one. The engine guarantees the same event fires never twice, even with several processes running in parallel. Temporary outages fix themselves, and real errors end up in one clear place instead of vanishing into thin air.

FIG 0.4 · NO DUPLICATES

You can retry without duplicating.

When you integrate two systems, the same call sometimes ends up going out twice — a timeout on your end, a retry, a nervous finger. toncrm handles it with an idempotency key: if the same event arrives twice, it replays the original response instead of processing it a second time. You retry a call without risking a duplicate or firing the same thing twice.

It's the kind of detail that makes the difference between an integration that holds and one that spawns phantom bugs — the guarantee that turns a jittery system into one you actually build on.

Idempotency-Key : order_4821
1st callProcessed · 201 created
Same key, 2nd callOriginal response replayed
Zero duplicates, no matter the retries
Typed schema · validation
amountnumber
emailemail
delivery_datedate
statustext (expected) — got number
FIG 0.5 · NOT RAW JSON

Conditions and a validation.

A trigger isn't a pipe that swallows anything. You can set conditions on the event's content (continue only if the amount exceeds 1000) and remap the data before it's used.

And every event is validated against a typed schema — text, number, email, date, and so on — with clear errors that tell you exactly which field is off and what was expected. You decide what deserves to continue, and the data coming in is clean before it even touches the rest of your system.

FIG 0.6 · TRACEABILITY

Every firing knows where it comes from.

The same trigger can fire in several ways — and each one is traced to its source in the execution log. An external webhook, a schedule, a batch send, a manual replay, a test from the interface, a workflow chain or a command to the assistant: you always know why an event ran, not just that it ran.

On the routing side, your conditions go beyond a simple "equals": nine operators (equals, not equal, greater than, contains, starts with…) plus a remapping of the content before the condition. And a trigger can chain into a workflow — the event comes in, the automation takes over.

Trigger sources
Webhook Schedule Batch Replay Test Workflow chain Assistant
FIG 0.7 · REPLAY

Replay any event — with its original version.

You can replay any past event from the interface. And here's the clever bit: if you've changed the event's schema since, the replay uses the schema it had back then, not the current schema. In other words, a replay truly reproduces what happened, instead of crashing against a newer version.

Your events keep their schema history — a detail most tools forget, and one that saves you hours of debugging the day you need to understand what happened three weeks ago.

Event from May 28 · schema v2
Captured as-is at the time.
Replay today
Replayed with v2, not the current v4.
Reproduced identically
No surprises against a newer version.
FIG 0.8 · IN BULK

A hundred events in a single call.

To import or sync in bulk, you can send up to a hundred events in a single call, with partial-success handling: you know exactly which ones went through and which ones snagged, instead of all-or-nothing. Handy when you plug in a system that spits out a lot of data at once.

You can also manage your triggers by command to the AI assistant: list them, create them, test them, delete them, or regenerate the webhook secret.
FIG 0.9 · BY THE NUMBERS

The event bus, in brief.

Your own event bus, built into the CRM (no Zapier or Segment on the side)
Called by signed webhook · schedule · batch — or replay
Automatic retry (up to 5×) → dead-letter queue + email, with a re-fire/discard interface
Idempotency key: retry without duplicating
Conditions on the content + validation against a typed schema (10 types)
Reliable replay with the original schema (schema versioning)
Batches up to 100 events/call (partial success) · integration guide (5 languages)
FIG 1.0 · FAQ

Everything about triggers.

Workflows are the visual automation you build. Triggers are the event layer underneath: the entry point your external systems and custom events come through, which can then feed a workflow.

No — the event bus is built into toncrm. You create a trigger, call it by webhook, schedule or batch, with no third-party service.

It retries automatically (up to five times, spacing out the attempts), then drops into the dead-letter queue with an email to the owner — from where you can re-fire or discard it.

An idempotency key recognizes it and replays the original response, without processing it twice.

Yes, from the interface — and the replay uses the schema the event had back then, not the current schema.

Not yet — the focus is on the event bus and its integration with the CRM.
L'entrepreneur d'aujourd'hui
FIG 1.1 · GET STARTED

Wire up your first trigger.

14 days free, no card. Or book a demo, and we'll wire up your first webhook with you.

Free 14-day trial

We'll wire up your first webhook with you in a demo.

Essai gratuit 14 joursAppeler Clodyne

Ready to see toncrm.io for real? We show it to you set up for your trade.

Book a 15-minute demo — or start your free trial right away.

Free 14-day trial

No credit card · Setup done for you · French-language support

Features