Agent activity
Checking for WebMCP support
Requests are only sent after you confirm them. How this works
Ayonix · Interface
Event webhooks: how analytics events reach your systems
In short
Webhooks deliver analytics events to your endpoint over HTTP as they occur, which suits integration with operational systems that are not a VMS. This page describes the integration design and the controls a receiver needs; the concrete event schema and endpoint details are supplied by Ayonix under evaluation access.
Where events must reach a system that is not a VMS — a yard-management platform, a signage controller, a workforce tool — webhook delivery is usually the cleanest path. The design questions are the same for any webhook integration: how deliveries are authenticated, what happens when the receiver is down, how duplicates are handled, and how the receiver avoids becoming an attack surface. The concrete payload schema is defined by Ayonix and provided under evaluation access rather than invented here.
Compatibility
What is supported, stated explicitly
Every mechanism carries an explicit state. No ambiguous checkmarks are used, and no certification or marketplace status is claimed without evidence.
| Mechanism | State | Notes |
|---|---|---|
| Event delivery over HTTPS to a customer endpoint | Available through integration project | Endpoint, payload schema and event taxonomy are agreed during integration scoping. |
| Request signing for authenticity | Available through integration project | Signed requests let the receiver verify the sender. The specific scheme is confirmed with Ayonix. |
| Retry with bounded backoff | Available through integration project | Transient receiver failures should be retried with bounded exponential backoff and a dead-letter path. |
| Idempotency via a stable event identifier | Available through integration project | Each event carries an identifier so a receiver can discard duplicates after a retry. |
| Published, self-service webhook API | Not supported | Ayonix does not publish a public webhook API specification. Details are provided under evaluation access. |
What each state means
- Available through integration project
- The integration is delivered as a scoped engineering project against the vendor SDK. Plugin availability, supported versions and licensing are confirmed with Ayonix before design.
- Not supported
- Not available, and not on the current roadmap.
Operators
What this changes for the operator
- Events reach the operational system without an operator copying anything between consoles.
- A receiver outage does not lose events, provided retries and a dead-letter path are configured.
- Duplicate deliveries after a retry are discarded by the receiver rather than producing duplicate work.
Constraints
Limitations and the integration checklist
Limitations
- Webhook delivery is at-least-once in any robust design, so receivers must be idempotent.
- A receiver that responds slowly will cause retries and back-pressure; respond quickly and process asynchronously.
- Ayonix does not publish a public webhook specification, so the payload contract comes from evaluation access.
- Webhooks are unsuitable where the consumer needs historical query rather than live delivery.
Questions to settle before design
- Is the receiving endpoint HTTPS with a valid certificate and no plaintext fallback?
- Is signature verification performed before any payload parsing?
- Is handling idempotent on the event identifier?
- What is the retry policy, and where do permanently failed deliveries go?
- Does the receiver acknowledge quickly and process asynchronously?
- Are payload size limits and rate limits enforced on the receiver?
Frequently asked questions
Can I see the webhook payload schema?
It is supplied by Ayonix under evaluation access. This site does not publish a schema, because inventing one would mislead you into building against a contract that does not exist. Request evaluation access and build against the real definition.
How do I verify a delivery is genuine?
Through request signing, verified before any payload is parsed. Parsing first and verifying afterwards is a common and serious mistake, because it exposes your parser to unauthenticated input.
What if our endpoint is down?
A robust design retries with bounded backoff and routes permanently failed deliveries to a dead-letter path so nothing is silently lost. The exact policy is agreed during integration scoping.
Other integrations
- Author
- Gabriel Bamola, Chief Marketing Officer, Ayonix
- Technical review
- Dr Sadi Vural, Founder and Chief Executive Officer, Ayonix
- Published
- Last reviewed
Scope a Event webhooks integration
Integration scoping starts with confirming your product version, the mechanisms it exposes, and what your operators actually need to see. Send those details and an engineer will tell you what is achievable in your environment.