Webhook event types
in one envelope
Every asynchronous thing the platform does emits an event, and every event has the same envelope. Handling a second capability's events is a new case in a switch statement, not a second parser.
Sandbox profiles are simulated and cost nothing. No card, no commitment.
ADDING THE SECOND ONE
The second capability should cost almost nothing.
What it actually takes to start handling events from something you have not used before.
Look up the types
The catalogue of event types is an endpoint, not a page that drifts from the platform.
Add a case
The envelope is identical, so only the type string and the payload body are new.
Fire it in the sandbox
Drive the transition against a simulated resource and watch your handler receive it.
That is the integration
No new endpoint, no new signature scheme, no new parser.
One envelope is a decision that costs the platform something and saves every integration something.
WHO IT IS FOR
For integrations that will grow
The cost of an event-driven integration is not the first capability. It is the fifth, when every one has arrived with its own shape.
Growth should be cheap. Fire a simulated event at your handler today, at no cost.
WHAT YOU GET
One envelope, and a catalogue you can read from code
What can happen, what shape it arrives in and what already has, all from the API.
- Envelope
- The same for every capability: type, id, time, and the object the event is about.
- Catalogue
- The event types are an endpoint, so a client can enumerate them rather than hard-coding a list.
- Coverage
- Everything asynchronous emits one. If it happens without you asking, there is an event for it.
- Replay
- History is replayable, so a handler deployed late can be caught up rather than starting blind.
- Signing
- Delivered signed, so a handler verifies origin before acting.
- Keys
- Test and live emit separately, so rehearsing a handler cannot be confused with production traffic.
- Retries
- Delivery is retried with backoff, and a redelivery carries the same event id so your handler can be idempotent too.
- Errors
- One shape everywhere: a type, a code, a message, the parameter at fault and a link. Never a bare 500 with a stack trace.
- Reference
- One published OpenAPI specification. The server validates against it, the SDKs are generated from it and the sandbox mocks from it.
WORKS WITH
Switch on the next one the same way
Nothing new to sign and nothing new to integrate. The same call with a different noun.
QUESTIONS
Events on Telyne
Is the envelope different per capability?
No. Type, id, time and the object the event concerns, identically for every capability. Only the type string and the payload body differ, which is what makes adding the second capability cheap.
How do I know which event types exist?
The catalogue is an endpoint. A client can enumerate the types rather than hard-coding a list copied from a page that has since changed.
What happens if my handler does not recognise a type?
Ignore it. New types are added over time and a handler that ignores what it does not recognise keeps working, which is why the clients behave that way by default.
Can I replay events?
Yes. History is replayable, so a handler deployed after the fact can be caught up rather than starting from whenever it happened to come online.
Are events signed?
Yes, in delivery. A handler verifies the signature before acting, which is what allows a public endpoint to be untrusting.
Write one handler before you switch anything on
No approval step and nothing to sign. The sandbox is open now, and production access opens in the order requests arrive.
One email at launch. Nothing else, and unsubscribe in one click.
We send a link to confirm the address. Unconfirmed addresses are deleted after 30 days.
Complex requirement or an existing estate to move? Talk to us.