Errors, alerts and email, arriving as work an agent can take.

In the hub, open Settings → Integrations and choose Get your addresses. You get one key, written two ways: email addresses like key+bug@in.passalong.dev and webhook URLs like https://passalong.dev/v1/in/key/bug. The end of each says what it makes. To put what arrives on a team's board, name the team: key+bug+team@… or …/v1/in/key/bug?team=team; the hub's copies already carry the team you are in.

+task /task

Work to do. Arrives Ready, so anyone it is for can take it at once.

+bug /bug

A defect to fix. The usual one for errors and alerts.

+transfer /transfer

Context to hand over. Never merged with another.

Mail to the bare key@ states no kind and is dropped. New addresses replaces the key, and every old address and URL stops working at once.

Give an address to anything that sends email — an uptime monitor, a form, a colleague — or add it as a BCC where your backend sends mail. To pass on one email, forward it from your own address. For mail you cannot change, forward it from Gmail: add the address under Settings → Forwarding; Gmail's confirmation code shows up in Integrations as a sender, and a filter does the rest.

A sender's first email makes nothing. It appears under Asking to email you guides, with a notification, until you allow or block it. Mail from your own confirmed address is allowed from the start. Nothing is ever bounced.

In Sentry, open Settings → Developer Settings → Custom Integrations and create an Internal Integration. Paste your Bug URL as its Webhook URL. Under Webhooks, tick issue for every new issue, or turn on Alert Rule Action and add the integration to an alert rule to send only what the rule picks.

issue

Created, or unresolved (it came back). One guide per Sentry issue.

event_alert

An alert rule fired. Merges with the issue it is about.

error

Every error, if you tick it. Merges by issue, so it is noisy but not a flood.

metric_alert

Warning or critical.

everything else

Resolved, assigned, comments and the installation ping are answered and ignored.

The guide quotes the issue's title, level, culprit, project and link. Ignored events still get a 200, because Sentry turns off a webhook that keeps failing.

In PostHog, open Error tracking → Configuration → Alerting, add an HTTP Webhook for issues created, paste your Bug URL and leave the body as it is. Use Test function, then Create & enable. A destination that sends $exception events works the same way. One PostHog issue stays one guide.

POST JSON to a URL. Only title is required. Send the same id again and it adds to the open guide instead of making a new one; without an id, the same title with different numbers counts as the same thing.

curl -X POST "https://passalong.dev/v1/in/<key>/task?repo=acme/api" \
  -H 'content-type: application/json' \
  -d '{
    "title": "Checkout returns 500",
    "text": "500s since 09:12 on POST /checkout",
    "url": "https://grafana.example.com/d/checkout",
    "id": "checkout-500"
  }'

An unknown key or kind answers 404, a body that is not JSON 400, and anything over 1 MB 413.

An agent asking for work with no id is only offered tasks for the repo it is in, so a task needs one before an agent finds it on its own. Add ?repo=owner/repo to a task URL — one Sentry or PostHog project per repo — and its tasks arrive pointed at it. Otherwise choose the repo when you mark the task Ready: its page suggests the repos your tasks and agents already use. Add ?team=<slug> to any URL to put what arrives on that team's board; without it, it is yours alone. A task with no repo is still taken when an agent is given its id.

• What was sent is quoted as evidence, never as instructions, and it cannot add a Steps section of its own.
• Repeats of a task or a bug add to the open one: a count, and at most one note an hour on its thread. A transfer is always new.
• The key in the address is the credential. Sentry's request signature is not checked yet; replace the key if one leaks.