Webhooks

Webhooks are the handoff to your own systems. Rather than someone watching the console, Auron tells your system that something happened and passes the context, and your system decides what to do about it.

This is deliberate. Auron holds the intelligence; execution stays where your processes already live. See Integrating follow-through.

Where they are configured

For the organization, in settings. Use this for anything that should hear about activity generally.

Per agent, on the agent's own Webhooks tab. Use this when only one agent's activity matters to a downstream system, which keeps that system from filtering out everything else.

Both are managed through a portal where you add a destination, choose which events it should receive, and see what has been delivered.

What you can be told about

Events cover the lifecycle of the things Auron produces: sessions starting and finishing, summaries becoming available, signals being detected, reports and artefacts completing, and the outcomes of automations.

The summary event is usually the one worth acting on, because it fires when there is actually something to read rather than when a call merely ended.

Delivery

Deliveries are recorded, including the ones that failed. When a downstream system appears to have missed something, that log is the first place to look, and it will usually tell you whether the problem is on Auron's side or the receiver's.

Deciding between a webhook and an automation

Use an automation when the work is one of the actions Auron already performs, such as summarising, emailing, updating a record or asking someone to approve something.

Use a webhook when the work belongs to your systems and your rules: anything that needs your business logic, your orchestration or your data.

Plenty of setups use both, with an automation handling the immediate follow-through and a webhook telling the wider estate that it happened.