For Agents
1. Create an API key
In your project settings, open the API Access section and create a key. Keys are scoped to a single project, so the agent only sees that project's errors. The full key is shown once at creation.
2. Connect over MCP
ObserverKit hosts an MCP server at https://api.observerkit.com/mcp. One command connects Claude Code; any MCP client works the same way.
claude mcp add --transport http observerkit \
https://api.observerkit.com/mcp \
--header "Authorization: Bearer <YOUR_API_KEY>"Tools: list_error_groups, get_error_group, list_error_events, resolve_error_group, ignore_error_group. Stack traces include the original source lines around each frame, so the agent usually sees the broken code before opening a single file.
3. Or use the REST API directly
# List active error groups from the last 30 minutes
curl -s "https://api.observerkit.com/v1/errors/groups?status=active&since=30m" \
-H "Authorization: Bearer <YOUR_API_KEY>"
# Full detail for one group (symbolicated frames with source context)
curl -s "https://api.observerkit.com/v1/errors/groups/<GROUP_ID>" \
-H "Authorization: Bearer <YOUR_API_KEY>"
# Mark it resolved after fixing
curl -s -X PATCH "https://api.observerkit.com/v1/errors/groups/<GROUP_ID>/resolve" \
-H "Authorization: Bearer <YOUR_API_KEY>"The since parameter accepts ISO 8601 timestamps or shorthand like 30m, 2h, and 7d. Responses are rate limited per key.
Autonomous error fixing
With a scheduled task, your agent can triage and fix new errors on its own. Paste this prompt into a Claude Code scheduled task after connecting the MCP server:
Check ObserverKit for errors and fix them.
1. Call the ObserverKit MCP tool list_error_groups with status "active".
2. If there are no active groups, stop.
3. For each group, call get_error_group and read the symbolicated stack
trace and source context lines.
4. Find the bug in this repository, fix it on a new branch, run the tests,
and open a pull request describing the error and the fix.
5. After the pull request is open, call resolve_error_group for that group.
If the fix was wrong, ObserverKit reopens the group automatically when
the error recurs, so the next run will pick it up again.
Never merge the pull request yourself.The loop is idempotent: only active groups get picked up, resolving marks them done, and a bad fix reopens the group automatically when the error recurs. Pull requests stay the human checkpoint.