If you have ever tried to get Playwright test data out of a reporting tool programmatically, you know the problem. You call the list endpoint, get statuses, then make a separate call per run for errors, another for coverage, another for spec breakdown. By the time you have enough data to post something useful to a PR or a CI pipeline export, you have chained four requests and written more glue code than the feature itself.
The TestDino Public API handles this differently. One parameter changes what you get back from a single run detail call. That difference is what makes building a Playwright reporting API integration actually worth the time.
Note: TestDino is Playwright-only. Cypress, Vitest, Jest: not supported.
The ?include= Parameter
Default call to a run detail endpoint returns run metadata: status, duration, branch, environment, test counts. Lean and fast.
Add ?include=errors,coverage,specs,artifacts and the same request returns:
-
errors:failures grouped by error message with stack traces -
coverage:Istanbul code coverage metrics for that run -
specs:spec files with flattened test cases and individual status per test -
artifacts:authenticated download URLs for Playwright traces, screenshots, videos
One call. No chaining.
GET /{projectId}/test-runs/{runId} include=errors,coverage,specs,artifacts
The ?include= parameter only works on two endpoints. GET /{projectId}/test-runs/{runId} accepts errors, coverage,specs,artifacts, all. GET /{projectId}/test-cases/{caseId} accepts history, all. List endpoints, analytics, and dashboard endpoints do not support it.
Full Endpoint List
Base URL:
https://api.testdino.com/api/public/v1/{projectId}/
Auth: Bearer token with tdp_ prefix, public-api scope. Generate from Project Settings. Token is scoped to one project. Project A token returns 403 on project B.
Rate limits: 100 req/min per token, 200/min per IP. Every response includes RateLimit-Remaining and RateLimit-Reset. PDF generation is 1/min per token.
GET /token-info # verify PAT, read project and org metadata
GET /test-runs # list runs, filter by branch/env/developer/tag/date
GET /test-runs/{runId} # run detail + ?include=errors,coverage,specs,artifacts
GET /test-cases/{caseId} # test case detail + ?include=history
GET /specs # spec file health: pass rate, flakiness score, duration
GET /test-case-explorer # aggregated metrics across runs
GET /analytics/summary # summary metrics and trend data
GET /dashboard # project health overview
GET /manual-tests # manual suites, cases, steps
POST /reports/pdf # generate a PDF report
GET /filters # environments, branches, developers, tags in a project
GET /usage # subscription usage and allocation
Full auth and error handling: docs.testdino.com/api-reference/conventions
Five-minute quickstart: docs.testdino.com/api-reference/quickstart
What You Can Actually Build
1. GitHub PR Annotation
The pain before: Reviewers merging without knowing if tests passed. The "can you check" comment in every PR thread.
After CI finishes, a workflow step calls the latest run for that branch, pulls pass rate and top failed test names with errors via ?include=errors, posts a PR comment. Reviewer sees test status without leaving GitHub.
GET /test-runs?branch=feature/my-branch&limit=1
GET /test-runs/{runId}?include=errors
2. Nightly Digest Email
The pain before: Engineering leadership has no visibility into test health trends unless someone manually checks and reports.
A scheduled script paginates through the previous day's runs, aggregates pass rate and failure counts per branch, grabs the five most flaky spec files via GET /specs, formats a plain text email, sends it. Director reads it before standup. Automated. Nobody had to remember.
3. Client-Facing Status Page
The pain before: Clients emailing "what is the current test status" weekly.
A script pulls the latest run and writes pass rate, timestamp, and branch to a Notion database or simple webpage. Clients check it themselves. No TestDino account required on their end. Those messages stop.
4. Flakiness Heat Map
The pain before: Knowing a suite is getting unstable but not knowing which files are pulling the numbers down.
GET /specs returns per-file flakiness scores across runs. GET /test-cases/{caseId}?include=history&historyStatus=flaky gives per-test flaky history. Combine them into a weekly view that surfaces exactly which files and tests are degrading. Teams that build this catch the problem before it becomes a standup conversation.
5. MCP: Querying Test Data from an AI Tool
The TestDino MCP server is a separate access path from the REST API. Two versions:
A. Local MCP Install via npx, connect Cursor, Claude Code, or Claude Desktop. The IDE tool queries live run data directly during your session.
npx @testdino/mcp
B. Remote MCP Hosted at mcp.testdino.com, connects ChatGPT, Claude on the web, and other remote-MCP-capable tools. No local install.
The pain before: Copying stack traces into an AI prompt and hoping it reasons correctly from pasted context.
The practical shift with MCP: You ask "what error pattern appeared most in staging this week" and the assistant queries actual run data to answer. Not a guess. Not training data. Your data.
Based on the public alternatives comparison, no other Playwright reporting tool has a remote MCP server.
Access and Availability
The API and MCP are included on every plan. There is no separate API tier, no add-on, and no unlock. You can start on the free plan and make your first API call today without a credit card.
Most alternatives in this space gate their API behind paid plans or charge significantly more for equivalent access. Full breakdown on the alternatives comparison page.
Top comments (0)