Reliability and audit guarantees

Mittr’s job is to make an action reliably land and be verifiable. These are the guarantees that make that true. They apply identically whether the action came from your code (a webhook) or an AI agent.

Every action is written to Postgres before Mittr attempts to deliver it. A crash, restart, or endpoint outage never loses the action, it is picked up and retried. There is no in-memory-only window where an action can vanish.

Failed attempts are retried with exponential backoff. Each attempt records its status code, latency, and error. When retries are exhausted, the action is dead-lettered rather than dropped, so nothing fails silently, and you can inspect or replay it. See Retry Strategies.

Every action carries an idempotency key. Repeated dispatches with the same key are deduplicated, so a retry, a replay, or an agent re-running a step does not fire the same side effect twice. This is the specific guarantee that makes agent actions safe: durable-execution runtimes and agent frameworks that re-run code on resume would otherwise double-send.

Outbound payloads are HMAC-signed so the receiver can verify authenticity. Delivery is SSRF-protected: private, internal, and metadata IP ranges are refused, so an attacker-supplied destination cannot be used to reach internal services. See Webhook Security.

Every action and every delivery attempt is recorded durably. This is not a debug view, it is the system of record for what your software and your agents did to the outside world:

• Which actions were dispatched, by whom, with what payload.
• Every attempt: when, to where, the response, the latency.
• What was retried, dead-lettered, or replayed, and by whom.

For AI agents this is the answer to “what did our agents actually do, and can we prove it.” Ordinary webhook traffic and agent actions share the same trail. See Compliance & Audit.

GET /api/v1/ledger/agent-actions returns exactly the actions your agents dispatched, each with its full delivery history inline. Ordinary webhook traffic never sets an agent run id, so the ledger is precisely the set of actions an agent caused. Admin-scoped, since it spans the whole workspace.

# Everything one agent run did, as CSV for a compliance review
curl -H "X-API-Key: mtr_your_key" \
  "https://app.mittr.io/api/v1/ledger/agent-actions?agentRunId=run_123&format=csv"

Each entry reports an outcome of delivered, in-flight, or dead-lettered, so the export answers “did it land” without interpreting internal status codes.

Any failed or dead action can be re-queued for another attempt, from the dashboard, the API, or an agent’s mittr_replay_event tool. Because delivery is idempotent, a replay is safe to run.

Durable-execution engines make your whole program recoverable. Mittr is narrower and complementary: it makes the outbound action reliable and provable at the boundary where your software touches another system. You do not rewrite your runtime; you dispatch the action to Mittr and inherit these guarantees.