Copy-paste complete/Synthetic samples labeled/Keys issue at activation
Documentation.
This documentation covers three things: the planned records API and its exact request and response shapes, the protocol discovery surface that is live on this domain today, and the planned MCP server. Every example below is copy-paste complete, every sample record is synthetic and labeled as such, and no endpoint serves real records today. API keys are issued at activation; the shapes are published now so people and agents can build against them first.
Quickstart
How do I make a lookup?
One GET request with one identifier and one bearer key. The planned endpoint is GET /v1/records/lookup, it takes the identifier you already hold as a query parameter, and it returns one record with a provenance object naming the supply contract, source file, and contract date. The examples below are complete as written: replace the example key with a real one at activation and they run unchanged.
curl "https://www.scrapelessdata.com/v1/records/lookup?email=jane@example.com" \ -H "Authorization: Bearer sd_key_EXAMPLE"
const res = await fetch(
'https://www.scrapelessdata.com/v1/records/lookup?email=jane@example.com',
{ headers: { Authorization: 'Bearer sd_key_EXAMPLE' } }
)
const record = await res.json()
console.log(record.provenance.supply_contract)import requests
res = requests.get(
"https://www.scrapelessdata.com/v1/records/lookup",
params={"email": "jane@example.com"},
headers={"Authorization": "Bearer sd_key_EXAMPLE"},
)
record = res.json()
print(record["provenance"]["supply_contract"]){
"record_id": "rec_01HZX4M7P0",
"name": "Jane Example",
"city": "Cheyenne",
"state": "WY",
"suppressed": false,
"provenance": {
"supply_contract": "sc_2026_wholesale_0417",
"source_id": "src_compiled_us_b2c_v9",
"contracted_at": "2026-07-14"
},
"latency_ms": 41
}The response is always one record or one structured error, never a page of results to re-rank. A suppressed record returns with suppressed: true and no personal fields.
Reference
Which endpoints exist today?
Nine endpoints on this domain answer real requests right now, and all of them are discovery and status surfaces rather than record lookups. They are listed first because an agent reading this page should know exactly what it can call before reading about anything it cannot. The two planned endpoints follow, marked as planned, with shapes frozen so integrations written today survive activation.
Live now
| Method | Path | Description |
|---|---|---|
| GET | /.well-known/ucp | UCP manifest: organization identity, planned capabilities with URLs, transport bindings, and health. Also served at /.well-known/ucp/manifest.json. |
| GET | /.well-known/acp/config.json | ACP configuration: endpoints, payment block with accepting_orders false, and a catalog of the three planned tiers, each flagged not purchasable. |
| GET | /.well-known/acp.json | ACP discovery document: merchant identity and a pointer to the full configuration. |
| GET | /.well-known/ap2/mandates.json | AP2 trust configuration: issuer DID, supported mandate types, and the public P-256 signing key. Mandate issuance begins at activation. |
| POST | /api/acp/checkout | Returns a structured not-accepting-orders response with the onboarding path. Accepts nothing and charges nothing. |
| POST | /api/acp/negotiate | Returns a structured status response describing the planned tiers. No negotiation occurs before activation. |
| GET | /llms.txt | Compact plain-text company summary for language models. The long form is at /llms-full.txt and structured JSON at /ai-context.json. |
| GET | /api/check-endpoint?domain=example.com | Free tool: checks any domain for UCP, ACP, AP2, llms.txt, and agent.json surfaces and reports what it finds. |
| GET | /api/ucp?health=true | Health check for the protocol surface. Returns status healthy while the discovery surface is serving correctly. |
Planned, shapes frozen
| Method | Path | Description |
|---|---|---|
| GET | /v1/records/lookup | Exchanges one identifier (email, and at launch additional identifier types documented here) for one record with its provenance object. Requires a key and completed certification. |
| POST | /api/agents/register | Machine-first registration: an agent submits structured JSON (agent name or DID, operator email, intended use) and receives a pending account id. Documented at /agents. |
The same contracts are declared machine-readably: UCP, ACP, AP2, plus llms.txt and ai-context.json.
Errors and limits
What does every error mean?
Seven status codes cover the entire planned records API, each with a stable machine-readable error name and a message written for the agent that has to act on it. Errors name the failing parameter, rate limits announce themselves in standard headers before you hit them, and suppression is a visible response state rather than a silent omission. This table is the contract; if it ever changes, the changelog records the change.
| Status | Error name | Meaning and resolution |
|---|---|---|
| 200 | ok | One record returned. A suppressed record still returns 200 with suppressed set to true and no personal fields, so opt-out compliance is visible rather than silent. |
| 400 | invalid_request | The identifier is missing or malformed. The message names the exact parameter, because an agent cannot fix what a human-oriented error hides. |
| 401 | unauthorized | The key is missing, revoked, or malformed. Keys are shown once at issuance and stored hashed; a leaked key is revoked, never recovered. |
| 403 | certification_required | The account exists but has not completed end-user certification, or the request falls outside its certified permitted use. |
| 404 | no_match | No record matches the identifier. This is a billable lookup in the planned design, and the response says so explicitly. |
| 429 | rate_limited | The per-key rate limit is reached. Standard X-RateLimit headers describe the window; the JSON body carries retry_after_seconds. |
| 503 | unavailable | The index is unavailable. Safe to retry with backoff; the status endpoint reports the incident. |
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1767225600
{
"error": "rate_limited",
"message": "Per-key rate limit reached. Retry after the reset timestamp.",
"retry_after_seconds": 18
}MCP
How do agents connect directly?
The planned MCP server is designed as a first-class integration path, not an afterthought, because a growing share of this audience never reads docs at all: their agent connects to a server, discovers the tools, and writes the integration itself. The design exposes two tools, record lookup and company search, each returning the same provenance object as REST, authenticated by OAuth against the same account and certification gates. It launches with key issuance.
{
"mcpServers": {
"scrapeless-data": {
"url": "https://mcp.scrapelessdata.com",
"auth": { "type": "oauth" }
}
}
}Tool schemas publish here when the server does. The ACP configuration already declares MCP among its planned transports, so agents reading the machine surface today can anticipate the connection path.
Docs questions, answered plainly
Can I call the records API right now?
No, and the docs do not pretend otherwise. Every records-API example on this page runs against the planned endpoint shapes with synthetic data, marked as such where it appears. What you can call today is the protocol discovery surface listed in the reference: the UCP manifest, the ACP configuration, the AP2 trust configuration, llms.txt, and the free endpoint checker all serve real responses from this domain right now, and they describe the planned product truthfully.
Why publish documentation before the API is live?
Because the spec is the source of truth this audience builds against, and publishing it first is the honest version of a launch. An agent or a developer can wire up the request shapes, error handling, and provenance parsing today, then swap in a real key at activation without changing a line. It also imposes discipline on us: the shapes documented here are contracts, and if one changes before launch, the changelog records exactly what moved and why.
How will the MCP server work?
The planned MCP server exposes the same product as the REST API through tools an agent discovers on connection: a record lookup tool and a company search tool, each with typed parameters and the same provenance object in results. Access is designed to ride on the same account, certification, and per-key limits as REST, with OAuth for the editor connection, so plugging the server into an editor is configuration rather than integration work. It launches alongside key issuance, not before.
What are the rate limits?
Planned per-key limits are sized generously against each tier bucket and reported live on every response through X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers, with a JSON 429 body carrying retry_after_seconds. The exact numbers publish with activation because honest limits can only be set against measured infrastructure. The commitment that stands now: limits are printed in these docs, enforced per key, and never a discovery you make in production.
Build against the shapes.
The request shapes, the error contract, and the provenance object are published and stable. Create an account, wire the integration against the synthetic shapes, and when keys issue at activation the only change in your code is the key.