How do I send an AI SRE’s finding about 5xx errors on an API to my own automation?

Tares sends each finding to your own automation through the write-back webhook, which POSTs it as JSON with run metadata. Turn on Write-back webhook under Deliver findings on the agent’s form and give it your URL. Transient failures are retried, and the body never carries a key or token. This applies to a finding about 5xx errors on your API the same way as to any other finding.

How it works

Every finding lands on the entity’s timeline first. The agent’s Deliver findings options then send it where people and systems already look, and the write-back webhook is one of them. The agent form is described on the delivery page, and the agents themselves belong to AI SRE.

• One POST per finding. Tares POSTs the finding as JSON to the URL you set. If you add a bearer token, Tares sends it as an Authorization header.
• Finding plus run metadata. The body holds the finding text and details about the run that produced it: the agent, the trigger, the key, the run and dispatch ids, the model, rounds, tool calls, start and finish times, duration and a prompt hash.
• No secrets in the body. The body never carries a key or token. The only credential Tares sends is the optional bearer token in the header.
• Retries. Transient failures are retried. A failed delivery never loses the finding, because it is already stored.
• Delivering is not acting. Sending a finding to your automation does not give the agent new powers. The tools boundary stands.

The webhook receives one of two events, finding or skipped, and you tell them apart with the event field.

Set it up

1. Prepare an HTTP endpoint in your automation that accepts a JSON POST. Decide whether it needs a bearer token.
2. Open the agent that watches your API, such as an incident first-look agent, and find its Deliver findings options.
3. Switch on the Write-back webhook row and enter your endpoint URL. Add the bearer token if your endpoint expects one.
4. Save the agent.
5. Make your endpoint read the event field. Handle finding as the result and skipped as a signal that a dispatched run was refused.

A finding body looks like this:

{
  "event": "finding",
  "agent": "incident-first-look",
  "trigger": "incident",
  "key": "api-server",
  "finding": "…the incident note…",
  "run_id": "run_9f2c81d4a6b3",
  "dispatch_id": "c0f35f8210…",
  "model": "claude-sonnet-4-6",
  "rounds": 2,
  "tool_calls": 3,
  "started_at": "2026-08-14T12:01:03+00:00",
  "finished_at": "2026-08-14T12:01:35+00:00",
  "duration_s": 32.6,
  "prompt_hash": "1c9f2d"
}

A skipped event tells your receiver that a run a trigger dispatched was refused before it started, so your automation does not wait for a finding that never comes:

{
  "event": "skipped",
  "reason": "in_flight",
  "message": "a run of this agent for the same key is already in flight",
  "agent": "incident-first-look",
  "trigger": "incident",
  "key": "api-server",
  "labels": {},
  "run_id": null,
  "dispatch_id": "c0f35f8210…",
  "in_flight_run_id": "run_9f2c81d4a6b3"
}

The reason field is one of three values:

• daily_cap: the agent already ran its daily cap of runs in 24 hours.
• budget_exhausted: the agent used up its budget_usd.
• in_flight: a run of the agent for the same key is already going, and in_flight_run_id names it.

The key and labels fields name the firing the way a finding would. A rerun, a bootstrap run or a hand-off sends no skipped event.

What you get

• Your automation receives the agent’s finding as JSON, together with the run metadata that lets you trace where it came from: run_id, dispatch_id, model, timings and prompt_hash.
• You can match findings to the firing that caused them by agent, trigger and key. For an API, the key in the example is api-server.
• Your payloads contain no key or token, so you can store or log them without exposing credentials.
• Retries cover transient failures. If delivery still fails, the finding is not lost, because it is already on the entity’s timeline.
• Your receiver learns about refused runs from the skipped event and the reason it carries, instead of waiting for a finding that will not arrive.

When something else fits

• If you want people to read the finding in a chat channel, use the Slack channel option on the same Deliver findings list. The workspace bot posts the full finding, and trigger subscription deliveries through that bot are also retried and recorded in the delivery ledger.
• The older per-agent Slack incoming webhook still works, but it is neither retried nor logged and is used only when no channel is set. Prefer the channel.
• For all delivery options and their details, see the delivery page.

Related