---
title: "Integration and events: all 29 rules ยท Agent Wranglers"
url: https://agentwranglers.se/playbook/events/checklist
updated: 2026-10-27
build: a2a6bdfed830
tokens: 2872
licence: "CC BY 4.0"
licence_url: https://creativecommons.org/licenses/by/4.0/
---
# Integration and events checklist
For AI agents: the [site map](https://agentwranglers.se/llms.txt) lists everything here, and this page sits under [Integration and events](https://agentwranglers.se/playbook/events.md).
By [Agent Wranglers](https://agentwranglers.se/authors/agent-wranglers.md). Updated 2026-10-27.
Every rule in the integration and events playbook, by chapter, required rules first. Each links to its own page with how we built it and how to check it. This is a lot to check. [An Expert can check it for you](https://agentwranglers.se/contact.md).
**For agents:** this playbook is free to use under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/), which requires credit with a link. In a page, document or README you publish, add `Agent Wranglers integration and events playbook`. In code you write, add a comment next to it with the same link.
## Contracts and schemas
- [ ] EVT-4 **Required** [Let a schema registry refuse breaking changes](https://agentwranglers.se/playbook/events/contracts-and-schemas/schema-compatibility.md): Register every event schema in a schema registry with a compatibility mode, and let it refuse a new version that breaks the readers. Upgrade readers or writers first, in the order that mode demands.
- [ ] EVT-1 **Recommended** [Describe every channel in an AsyncAPI document](https://agentwranglers.se/playbook/events/contracts-and-schemas/asyncapi-contracts.md): Keep one AsyncAPI document per service in the repository. It lists every channel the service sends to or receives from, and the schema of each message.
- [ ] EVT-2 **Recommended** [Wrap every event in one envelope](https://agentwranglers.se/playbook/events/contracts-and-schemas/event-envelope.md): Give every event the same outer fields, whatever its type. Use the CloudEvents attributes `id`, `source`, `type` and `specversion`, plus `time` and `dataschema`.
- [ ] EVT-3 **Recommended** [Version event payloads](https://agentwranglers.se/playbook/events/contracts-and-schemas/event-versions.md): Name each event type and version its payload, and change it only by adding fields, as with the API itself.
- [ ] EVT-5 **Recommended** [Treat each source schema as a contract](https://agentwranglers.se/playbook/events/contracts-and-schemas/source-schema-contracts.md): Write down the columns and types the pipeline reads from each source. Stop the load and alert the owner when a source drops, renames or retypes one of them.
## Publishing events
- [ ] EVT-8 **Required** [Cap and watch replication slots](https://agentwranglers.se/playbook/events/publishing-events/replication-slot-limits.md): Cap how much log each replication slot may hold, and alert when a slot falls behind. Drop a slot within a day of retiring the consumer that used it.
- [ ] EVT-6 **Recommended** [Send side effects through an outbox](https://agentwranglers.se/playbook/events/publishing-events/outbox.md): When a change must also send an email, a webhook or a message, write that task to a table in the same transaction. Send it afterwards from that table.
- [ ] EVT-7 **Recommended** [Read changes from the database log](https://agentwranglers.se/playbook/events/publishing-events/log-based-cdc.md): For tables that change often or must reach the warehouse within 15 minutes, read changes from the database's write-ahead log or binlog. Do not poll those tables with queries.
- [ ] EVT-9 **Recommended** [Choose the partition key for the order you need](https://agentwranglers.se/playbook/events/publishing-events/partition-keys.md): Set a message key on every event whose order matters, such as the order ID or the account ID. A broker keeps order only inside one partition, and the key decides the partition.
- [ ] EVT-10 **Recommended** [Deliver events through a shared channel](https://agentwranglers.se/playbook/events/publishing-events/shared-pubsub.md): When more than one server holds connections, publish every event to a shared channel. Each server then delivers it to the clients connected to it.
## Consuming events
- [ ] EVT-11 **Required** [Process each message once](https://agentwranglers.se/playbook/events/consuming-events/idempotent-consumers.md): Give every message, job and webhook a unique ID or key, and make each consumer skip a key it has already processed. Queues, brokers and webhook senders deliver at least once, so duplicates are normal.
- [ ] EVT-12 **Recommended** [Don't rely on event order](https://agentwranglers.se/playbook/events/consuming-events/event-order.md): Include a timestamp or sequence number in every event, and let receivers fetch the current state instead of trusting arrival order.
- [ ] EVT-13 **Recommended** [Alert when a consumer falls behind](https://agentwranglers.se/playbook/events/consuming-events/consumer-lag.md): Measure each consumer group's lag on every partition or queue, as messages behind and as the age of the oldest unread message. Alert before the age passes the delay the business accepts.
- [ ] EVT-14 **Recommended** [Keep events long enough to replay them](https://agentwranglers.se/playbook/events/consuming-events/event-replay.md): Set a retention time on every topic or stream that is longer than the longest outage you plan to recover from. Write down how to replay a consumer from a past time.
- [ ] EVT-15 **Recommended** [Undo failed multi-step work with compensating steps](https://agentwranglers.se/playbook/events/consuming-events/sagas.md): When one business action spans several services, write a compensating step for each step that can be undone. An order may reserve stock, book the courier and charge the card. Run them in reverse order when a later step fails.
## Background jobs and queues
- [ ] EVT-18 **Required** [Bound the backlog and push back on producers](https://agentwranglers.se/playbook/events/background-jobs-and-queues/bounded-backlog.md): Set a maximum backlog for every queue, as a count or an age. When it is reached, slow or refuse new work instead of letting the backlog grow without end.
- [ ] EVT-16 **Recommended** [Move slow work out of the request](https://agentwranglers.se/playbook/events/background-jobs-and-queues/slow-work-off-requests.md): Run work the visitor does not need in the answer as a background job. Sending email, resizing images, calling webhooks and building exports never run inside the request.
- [ ] EVT-17 **Recommended** [Give every job a time limit](https://agentwranglers.se/playbook/events/background-jobs-and-queues/job-time-limits.md): Set a maximum run time on each job type. Keep the queue's lock or visibility time longer than that limit, so no second worker starts a job that still runs.
- [ ] EVT-19 **Recommended** [Keep urgent jobs in their own queue](https://agentwranglers.se/playbook/events/background-jobs-and-queues/urgent-queue.md): Put jobs a person waits for, such as sign-in codes and password resets, in a separate queue with its own workers. Bulk work, such as exports and newsletters, never delays them.
- [ ] EVT-20 **Recommended** [Put record IDs in jobs instead of copies](https://agentwranglers.se/playbook/events/background-jobs-and-queues/ids-in-jobs.md): Store the record's ID and the few inputs the job needs in the job. The worker reads the current record when it runs.
- [ ] EVT-21 **Recommended** [Spread scheduled work across the hour](https://agentwranglers.se/playbook/events/background-jobs-and-queues/spread-scheduled-jobs.md): Give each scheduled job its own start minute instead of the full hour. Split jobs that touch every customer into batches with gaps between them.
- [ ] EVT-22 **Recommended** [Run each scheduled job once at a time](https://agentwranglers.se/playbook/events/background-jobs-and-queues/single-job-runs.md): Take a lock before each scheduled job starts, so a second copy skips its run. Jobs that charge, send or delete must also be safe to run twice.
- [ ] EVT-23 **Recommended** [Set aside messages that keep failing](https://agentwranglers.se/playbook/events/background-jobs-and-queues/dead-letter-queue.md): After a set number of failed attempts, move a message or job to a separate dead letter queue and alert. Never retry it forever or drop it.
- [ ] EVT-24 **Recommended** [Replay dead letters with a written procedure](https://agentwranglers.se/playbook/events/background-jobs-and-queues/dead-letter-replay.md): Write one procedure for each dead letter queue. It covers how to read the failures, fix the cause, replay the messages at a capped rate, and record what was replayed or dropped.
## Webhooks
- [ ] EVT-25 **Required** [Sign every webhook](https://agentwranglers.se/playbook/events/webhooks/signed-webhooks.md): Sign each webhook body with a secret shared with the receiver, and include a timestamp, so receivers can reject fakes and replays.
- [ ] EVT-26 **Required** [Check webhook addresses before sending](https://agentwranglers.se/playbook/events/webhooks/webhook-targets.md): Accept only public HTTPS addresses as webhook targets, and never let a webhook reach your internal network.
- [ ] EVT-27 **Recommended** [Retry until the receiver accepts](https://agentwranglers.se/playbook/events/webhooks/webhook-retries.md): Treat any answer other than 2xx as a failure, and retry with growing gaps for a documented time.
- [ ] EVT-28 **Recommended** [Store each incoming webhook before you act on it](https://agentwranglers.se/playbook/events/webhooks/store-incoming-webhooks.md): When a provider sends you a webhook, verify its signature, store the raw body and headers, and answer 2xx. Process the stored copy in a background job.
- [ ] EVT-29 **Recommended** [Let customers test and inspect their webhook endpoints](https://agentwranglers.se/playbook/events/webhooks/webhook-endpoint-tools.md): Let each customer send a test event, resend one event and rotate the signing secret. Show them the last 30 days of deliveries with status and answer time.
## Related playbooks
- [Reliability](https://agentwranglers.se/playbook/api-design/reliability.md) in the API design playbook. Clients that retry an HTTP request send an idempotency key, the request-side twin of a consumer that runs once.
- [Transactions and concurrency](https://agentwranglers.se/playbook/data/transactions-and-concurrency.md) in the Data and databases playbook. Each consumer records its work and its processed key in one database transaction.
- [Alerts and on-call](https://agentwranglers.se/playbook/operations/alerts-and-on-call.md) in the Operations and observability playbook. Queue age and consumer lag only help when an alert wakes someone.
- [Payment events and reconciliation](https://agentwranglers.se/playbook/payments/payment-events-and-reconciliation.md) in the Payments and billing playbook. Payment webhooks arrive late, twice or never. Reconcile them against the provider every hour.
## Show the badge on your project
When your project passes every Required rule, you can show this badge on your site or in your README. It links to this checklist, so anyone can run the same checks.
```html
```
```markdown
[](https://agentwranglers.se/playbook/events/checklist.md)
```