Observed API turns traffic already captured by Busymate into a reviewable API contract. It is built for reverse engineering, integration work, migration audits, and keeping undocumented APIs understandable as they change.
Open API → Observed API, give the project a name and one or more exact hostnames, then choose Build from traffic. Busymate reads only traffic your account can already see.
What Busymate stores
The source of truth is an immutable observation graph, not an OpenAPI file. Each revision stores:
- the operations, statuses, time window, source types, confidence, and sample counts actually observed;
- an evidence map from each emitted operation, parameter, response, media type, and schema node to capped capture references;
- a deterministic OpenAPI 3.1 projection;
- whether the selected capture window reached its entry cap;
- drift from the preceding revision.
This distinction matters: a capture can prove that behavior was observed, but it cannot prove that an unobserved endpoint does not exist.
Inference and review
Strong identifiers such as numbers, UUIDs, dates, long hexadecimal IDs, and high-entropy tokens become path parameters automatically. Human-readable slugs are deliberately conservative: after three related paths repeat with different values, Busymate proposes a template and waits for you to choose:
- Accept template — merge the paths under the suggested template;
- Keep separate — preserve each literal path;
- Exclude — leave those paths out of the contract.
A decision is durable. Refreshing appends a new revision using all current decisions; it never edits an earlier revision.
Schemas aggregate every selected observation and every member of captured arrays. A field is marked required only after at least two object samples and only when it appears in every sample. JSON, form-encoded, multipart field structure, and MessagePack are decoded. Unsupported or failed decodes remain explicitly marked opaque instead of being guessed.
Secret-safe by construction
Generated graphs, OpenAPI documents, exports, and artifacts contain structural names, reviewed/static path shapes, and types, but never captured examples or header/query/body values. Authorization headers, cookies, tokens, and credentials are not copied into generated output.
The original entries remain governed by the existing capture retention and row-level security policies. Evidence links retain entry/request IDs and timestamps only.
Export, drift, and proof artifacts
Use JSON or YAML to download a deterministic OpenAPI 3.1 document. Refresh after new traffic to record added operations, missing observations, changed statuses, and changed schema shapes.
The reviewed revision can also generate a TypeScript fetch client, a Node mock server, or Vitest contract tests. Mocks return explicit 501 placeholders rather than replaying captured bodies. Generated live tests auto-run only non-parameterized GET, HEAD, and OPTIONS operations; writes remain todo until you deliberately supply safe fixtures.
Create proof artifact renders the selected revision as a self-contained private report at its tenant-aware canonical route: https://busymate.ai/artifact/<slug> for the platform tenant, or https://<tenant-slug>.busymate.ai/artifact/<slug> for a white-label tenant. Publishing wider remains a separate, explicit artifact visibility change.
Scope, schedules, and lifecycle
Open Project settings to edit hosts, device UUIDs, absolute time bounds, and the 1–2,000-entry evidence cap. Saving a definition always rebuilds immediately, so the latest displayed revision cannot silently describe an older scope.
Schedules accept a requested interval from 15 minutes to seven days. Busymate reports that request separately from the measured p90 interval between successful refreshes. Until two genuine successes exist, schedule health is unverified, not healthy. Three consecutive failures produce one coalesced notification; a later successful revision archives that alarm using positive recovery evidence. Drift events notify per new revision and arrive over Realtime.
Archiving preserves revisions and evidence, disables the schedule, and hides the project from the default list. Restoring makes it editable again. Permanent deletion cascades the project store, but any separately published artifact remains independent.
MCP and BusyBro
The same workflow is available through thirteen MCP tools: list_api_projects, create_api_project, update_api_project, set_api_project_archived, delete_api_project, set_api_project_schedule, refresh_api_project, get_api_revision, list_api_candidates, review_api_candidate, export_api_spec, generate_api_asset, and list_api_drift. (Publishing an Observed-API revision as a visual report is a Busymate AI artifact — since #1985 La, artifacts are Busymate AI only, so the former publish_api_artifact MCP tool was removed from the DevTools MCP; the report still publishes via the observed-api service action and the bmai MCP create_artifact.)
These are owner-scoped tools. Every write is confirm:true. MCP, BusyBro, and the dashboard all call the same handlers and rely on the same database policies, so a different interface cannot widen the traffic or projects a caller may see.