Overview
What the OngoingAI API returns, where it lives, and how these docs stay true to it.
The OngoingAI API answers three questions about any ecommerce domain: what platform it runs, which technologies are installed, and what changed. Every answer is assembled from completed observations of the live storefront and carries the dates that support it.
| Base URL | https://api.ongoing.ai |
| Version | /v1 in the path. Additive changes are non-breaking; removals and renames go to /v2. |
| Auth | Authorization: Bearer oai_live_… (workspace API key) |
| Format | JSON in, JSON out. Timestamps are RFC 3339 UTC. |
| Contract | /v1/openapi.json, OpenAPI 3.1 |
| Interfaces | REST here, plus a GraphQL endpoint used by our own surfaces. A workspace key authenticates REST. |
| Discovery | / names the interfaces, /v1 lists the operations a deployment actually serves. Neither needs a key. |
What is live in this release
GET/v1/account validates a key and returns plan limits and remaining allowance.
GET/v1/stores/{domain} returns one store profile.
POST/v1/stores/enrich returns a batch of profiles, up to your plan's enrich_batch_max.
GET/v1/technologies lists the vocabulary those profiles use.
GET/v1/usage reports consumption this period.
Store history, signal search, watchlists, webhooks, and asynchronous jobs are defined in the contract and arrive in later releases. An operation appears in the reference only once it is served.
How to read a store profile
A profile is not a claim about the site today. It is a claim about the last completed observation, and the observation object tells you when that was and how much it covered. Two rules follow from that:
- Absence is not removal. A technology missing from
technologiesmeans it was not seen in that observation's scope. Confirmed removals are separate events with their own dates. - Unknown is not negative. A
404 not_foundor ano_matchresult means the domain is not in the corpus yet. It says nothing about whether the site is a store.
Observations and evidence covers this in detail. Agents reading these docs programmatically get the same rules in every operation's x-agent-notes.
How these docs stay accurate
The reference section is generated from the API's own route definitions. Inputs, outputs, examples, and the notes on each operation come from the same source the server validates against, and a release that changes any of them regenerates this site. The Markdown version of every page is built from the same content.