canonical: https://jentic.com/apis/atatus.com/atatus # Atatus API The Atatus API exposes performance and error monitoring data captured by the Atatus application, browser, and infrastructure agents. It is project-scoped: every endpoint takes a project id and returns the pages, ajax calls, routes, transactions, errors, web vitals, or report rollups associated with that project. The surface is read-oriented - useful for piping monitoring data into dashboards, reliability reviews, and AI-driven incident summaries rather than configuring the monitoring agents themselves. ## For AI agents Pull pages, errors, transactions, ajax calls, and web vitals from an Atatus project to feed dashboards, alerts, or AI incident summaries. ## Scope Does not handle agent installation, alerting rules, or user management - use for reading captured monitoring data (errors, transactions, routes, web vitals) only. ## Capabilities - List monitored pages for a project and drill into a single page by id via `/projects/{projectId}/pages` - Retrieve error events captured by the Atatus agents through `/projects/{projectId}/errors` - Inspect ajax call performance and routes seen by the browser agent - Read transaction-level performance for back-end services using `/projects/{projectId}/transactions` - Pull Core Web Vitals (LCP, FID, CLS) for a project from `/projects/{projectId}/webvitals` - Retrieve scheduled reports for a project to syndicate them into other systems ## Use cases ### Reliability Dashboard Backfill SRE teams build internal dashboards that combine APM data with deploy and incident metadata. The Atatus API's project-scoped endpoints (/transactions, /errors, /routes, /webvitals) let an ingestion agent backfill a metrics store for each project, on a schedule, without exporting from the Atatus UI. The result is a unified reliability view across services that already report into Atatus. Example prompt: For project id 'acme-prod', list errors and slowest transactions for the last 24 hours and write them to the reliability data warehouse ### AI-Generated Incident Summary When an incident hits, on-call engineers want a one-paragraph summary of what's happening across pages, routes, and transactions. An LLM agent calls `/projects/{projectId}/errors` and `/projects/{projectId}/transactions` for the affected window, then summarises the top failing routes and slow transactions for the incident channel. Time-to-first-summary moves from a manual dig to under a minute. Example prompt: Fetch the last 30 minutes of errors and slowest transactions for project 'acme-prod' and produce a 5-bullet incident summary ### Web Vitals Tracking for Marketing Marketing and front-end teams want to track Core Web Vitals for the public-facing site over time, separate from APM. The `/projects/{projectId}/webvitals` endpoint returns LCP, FID, and CLS for the project, so a tracking agent can record weekly snapshots and flag regressions tied to releases. This keeps SEO-relevant performance metrics under continuous review. Example prompt: Pull `/projects/{projectId}/webvitals` for the marketing-site project and alert if LCP exceeds 2.5 seconds ### Atatus Insights Through Jentic Through Jentic, an AI agent answering an APM question searches by intent ('show me top errors today') and Jentic returns the matching Atatus operation with its project-id parameter. The X-API-KEY credential is held in your Jentic One instance, so the agent never sees the secret. This makes monitoring data answerable directly in any LLM chat or ops workflow. Example prompt: Use Jentic to search 'list top errors for project today', load GET `/projects/{projectId}/errors`, and execute with the active project id ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/projects/{projectId}/pages` | List monitored pages for a project | | GET | `/projects/{projectId}/errors` | List error events for a project | | GET | `/projects/{projectId}/transactions` | List transactions for a project | | GET | `/projects/{projectId}/routes` | List back-end routes for a project | | GET | `/projects/{projectId}/ajax` | List ajax calls for a project | | GET | `/projects/{projectId}/webvitals` | Get Core Web Vitals for a project | ## Key resources - **Pages** — List and inspect monitored pages for a project - **Errors** — Retrieve error events captured by the Atatus agents - **Ajax** — List ajax calls observed by the browser agent - **Routes** — List back-end routes with performance and error rates - **Transactions** — Inspect transaction-level performance data - **Web Vitals** — Pull Core Web Vitals (LCP, FID, CLS) for a project - **Reports** — Retrieve scheduled report rollups for a project ## Why Jentic - **Setup:** Wiring Atatus by hand means handling its X-API-KEY header auth and passing the project id on every monitoring read for errors, transactions, and web vitals. Through Jentic you install once, import the Atatus API from the API Directory, store the key once, and your agent calls it while Jentic sets the header. - **Permission scoping:** Atatus puts the project id in the URL path (`/projects/{projectId}/errors`), so a rule can pin your agent to reads for one project. The spec exposes only GET reads of captured monitoring data, so no write operation is available regardless of what you allow. - **Credential handling:** Your Atatus X-API-KEY value is stored once, encrypted, by your own Jentic One instance and set as the X-API-KEY header at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'list top errors for a project', and Jentic returns the matching Atatus operation with its project-id parameter so the agent calls the right endpoint without reading the reference docs. ## Related APIs - **New Relic** — Full-stack observability platform with APM and infrastructure - **Sentry** — Error-tracking and performance monitoring platform - **Raygun** — Crash and APM platform with real user monitoring ## FAQ ### What authentication does the Atatus API use? The Atatus API uses an API key in the X-API-KEY header. Through Jentic, the key is held in the encrypted vault and the header is set at call time, so the secret never enters the agent's context. ### Can I list errors for a specific Atatus project? Yes. GET `/projects/{projectId}/errors` returns the captured error events for the given project, and GET `/projects/{projectId}/errors/{errorId}` returns the detail for a single error. Combine them to build an error-triage workflow scoped to the project. ### What are the rate limits for the Atatus API? The spec does not encode an explicit rate limit. Atatus throttles per workspace API key, so the safe pattern is to back off on HTTP 429 responses and prefer batched range queries over polling per id. ### How do I get Core Web Vitals for a project through Jentic? Search Jentic for 'get core web vitals for a project', load GET `/projects/{projectId}/webvitals`, and execute with the project id. Jentic injects the X-API-KEY and validates the project-id parameter before the request is sent. ### Can I retrieve transactions by id with the Atatus API? Yes. GET `/projects/{projectId}/transactions` lists transactions for a project, and GET `/projects/{projectId}/transactions/{transactionId}` returns the single-transaction detail used for drill-downs in incident reviews. ### Does the Atatus API support configuring the monitoring agents? No. The API surface is read-oriented around captured monitoring data - pages, ajax, routes, errors, transactions, web vitals, and reports. Agent configuration still lives in the Atatus dashboard. ### Can I limit what my agent is allowed to do with the Atatus API? Yes. Because Jentic One is self-hosted, your own rules decide which Atatus operations and credentials the agent may use. Atatus carries the project id in the URL path, such as GET `/projects/{projectId}/errors`, so a rule can pin the agent to reads for a single project. The API also exposes only GET reads of captured monitoring data like errors, transactions, routes, and web vitals, so no write operation is available regardless of what you allow.