Use published business information in your application.

A successful read

Every published business answers on a public URL. No account, no key, nothing to install — swap in the publisher's slug, which is the last segment of their public page address:

curl -s https://x-protocols.com/b/{publisher} -H 'accept: application/json'

{
  "publisher": {
    "slug": "{publisher}",
    "display_name": "…",
    "verified": true,
    "website": "https://…",
    "website_verified": true,
    "url": "https://x-protocols.com/b/{publisher}",
    "query_api": "https://x-protocols.com/t/{publisher}/mcp"
  },
  "records": [
    { "id": "SKU-123", "type": "product",
      "title": "…", "url": "https://x-protocols.com/b/{publisher}/product/SKU-123",
      "attributes": { "…" }, "updated_at": "2026-09-11T09:12:00Z" }
  ],
  "bulk_export": "https://x-protocols.com/b/{publisher}/dump.jsonl"
}

That is the whole crawl surface: the same URL a person reads as a page. bulk_export is the cheapest way to ingest a publisher wholesale — one JSON object per line. query_api is where you ask questions instead of fetching everything, which is the rest of this page.

Authentication

Most publishers can be read with no credentials at all. Anonymous read is on by default — publication is the point of the platform — so the crawl surface, the discovery documents, the feeds and, for most publishers, the query endpoint all answer an unauthenticated request.

A bearer token does two things: it identifies you for rate limiting, and it is required for a publisher who has closed anonymous reads. That publisher answers an unauthenticated request with 401 unauthorized.

Authorization: Bearer kc_live_<prefix>_<secret>

Publishers create and rotate their own keys in Developer access. Keys are rate-limited per plan; exceeding the limit returns 429 with a Retry-After header. A revoked key stops working within the tenant cache TTL, not instantly.

Your first query

The query endpoint speaks MCP over Streamable HTTP — JSON-RPC 2.0 over a single POST. Ask what a publisher offers before you ask it anything:

curl -s https://x-protocols.com/t/{publisher}/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Then call one. Every answer comes back in the same envelope whatever the tool was, so you learn the shape once and apply it to every business on the registry:

curl -s https://x-protocols.com/t/{publisher}/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"knowledge.search","arguments":{"query":"opening hours on Sunday"}}}'

The envelope carries result, a coverage block, a freshness contract, expires_at, a revocation_url and an Ed25519 attestation. The next two sections are the two of those you cannot skip.

Understanding coverage

Coverage has four states. Two of them return records.

The invariant, if you read one line of this page:

status == "resolved"  <=>  covered && answers_request && unresolved is empty

coverage.agent_instruction is a sentence written for a model rather than for you: pass it through to whatever is composing the reply. It changes with the state, and it is the same sentence on every publisher.

Verification

Every answer carries an Ed25519 signature over the whole envelope, and the address of the key that signed it. Fetch the publisher's keys from their JWKS document, match the kid in the envelope, and check the signature — about fifteen lines in any language. Worked example, with the canonical payload rules and the expiry and revocation checks: Verify a response.

Retired keys stay published, so an envelope signed before a rotation stays verifiable. Always match on kid; never assume the first key in the set.

A signature proves the envelope is intact and came from that key. Who that key belongs to is a separate question, answered by the authority evidence on a publisher's own verification page at /b/{publisher}/verify — where each proof is printed with what it does and does not establish. Control of a domain name is one accepted proof; it is not the only one, and it is not what makes a publisher readable here.

Feeds and live data

Three different things keep a publisher's data current, and they need different amounts of engineering:

A publisher who sells nothing answers the ACP feed with 404 not_syndicated. That is the correct outcome, not an error: a dentist has no product catalogue, and inventing an empty one would be a claim they never made.

Outbound webhooks

Instead of polling for changes, a publisher's own systems can be told the moment their catalogue changes. Subscriptions are created in Developer access — no route here creates one; this section is for whatever receives the POST.

One delivery per write call, not per record: a bulk import of a thousand rows fires one record.upserted event carrying all of them, not a thousand deliveries.

Event types and payload

Headers

Verifying a delivery

HMAC-SHA256, hex-encoded, prefixed sha256= — the same scheme in both directions, so a verifier already written for an inbound live-data push can be reused here unchanged:

signature = "sha256=" + hex( HMAC_SHA256(secret, timestamp + "." + raw_request_body) )

Sign the exact bytes of the request body, before any JSON re-serialization — re-encoding first is the most common reason a verifier disagrees with a correct signature. The secret is shown once, at subscription creation, in Developer access.

Retries and auto-disable

A non-2xx response or a connection failure is retried with backoff starting at 1 minute and doubling up to a 15-minute cap, for up to 8 attempts total before that one event is given up on. A subscription whose endpoint exhausts every attempt on 5 consecutive events is automatically disabled — visible and re-enableable in Developer access, rather than silently retrying a dead endpoint forever.

Errors

A not_covered answer is a 200, not an error. It is the API working as designed.

Every endpoint

Query

Discovery

Public data

Live data

Syndication

Operations