Support diagnostics and audit-feed pull endpoints

This page documents two of the engine’s server-to-server pull surfaces, the read-only endpoints under /support, distinct from the /admin console API. A third, GET /metrics, is a Prometheus scrape under the same credential mechanism and is covered separately on the metrics endpoint. It is written for a developer wiring vendor support tooling to fetch a diagnostics bundle, or a SIEM collector to poll the hash-chained audit feed. All three endpoints sit outside the admin authentication model and are reached with a platform-issued bearer scoped to exactly one read. None can reach an admin route, a restore, or your data.

The two endpoints exist because the product holds nothing on the vendor side. The absence rules out the two answers a support team usually reaches for, a vendor-held Cloudflare token and a vendor dashboard seat. In their place an Owner mints a time-boxed credential per scope. The diagnostics scope lets vendor support pull the signed and sealed support bundle during a ticket; the audit-feed scope lets your own collector poll the audit events on a schedule. The credential lifecycle, minting and revocation, is owned by pull credentials; this page is the wire-level reference for the endpoints themselves.

The two endpoints

A single handler serves both routes, switching on the path and rejecting anything but a GET to one of the two with a 404 (handleSupportPull, engine/src/admin/support-ingest.ts).

Both require a bearer credential for the matching scope. A request with no bearer, or one that fails the check, is a 401 with the body { "error": "unauthorised" } and no other detail. A successful pull is recorded on the grant best-effort, so the customer sees a usage trail without that record ever blocking the response (handleSupportPull, engine/src/admin/support-ingest.ts).

The bearer credential

The credential is a client and secret pair issued per scope. It is presented as one opaque bearer of the form client-id, a dot, then the secret, because a single field fits every collector’s configuration form and the vendor’s support tooling alike.

GET /support/audit-feed?afterSeq=0&limit=500 HTTP/1.1
Host: console.example.com
Authorization: Bearer dpc_AbCdEf012.dps_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The check is constant-time against a stored hash, with server-side expiry enforced first. The engine splits the bearer on the first dot, confirms the client id matches the active grant for the scope and that the secret carries the expected dps_ prefix, then compares the SHA-384 of the presented secret against the stored 96-character hex hash in constant time. An expired grant is refused before the hash is even compared (checkIngestCredential, engine/src/admin/support-ingest.ts). The secret itself is never stored: only its SHA-384 persists, the secret is shown once at grant time, and a failed presentation neither logs nor echoes the presented value.

Each scope has its own lifetime, set when the credential is minted and clamped by the engine. The diagnostics scope is short, for the life of a ticket; the audit-feed scope is long, for an always-on collector. Both clamp a requested value to a minimum of sixty seconds (INGEST_TTL_CAPS_SECONDS and the clamp in ingestTtlSeconds, which mintIngestCredential calls, engine/src/admin/support-ingest.ts).

GET /support/diagnostics

The diagnostics endpoint returns the support bundle, sealed to the vendor support key when configured and signed by your engine once the signing ceremony completes. The handler builds the bundle on demand and returns it as raw JSON (handleSupportPull calling sealedSupportBundle, engine/src/admin/support-ingest.ts).

The bundle is tamper-evident, which is detection rather than prevention: the engine signs the canonicalised document with its own run signer, a hybrid of Ed25519 and ML-DSA-87, so support can detect an alteration after your engine produced the file. When the vendor support key is configured, the signed bundle is additionally sealed with the same hybrid X25519 and ML-KEM-1024 capsule the archive uses for its recipients, so only the holder of the matching vendor identity can open it.

Because the signer and the vendor key are each either present or absent, the bundle takes one of four states, and the endpoint never returns an envelope it cannot produce. The endpoint returns the strongest envelope available, and the kind field names it.

The exhaustive field-by-field account of what the bundle carries and what it can never contain lives in the support bundle. In short, every field is presence-only, a coarse enumerated outcome, or a label you chose, so the bundle carries no customer backup data, no keys, and no secret values.

GET /support/audit-feed

The audit-feed endpoint returns the engine’s hash-chained audit events for a SIEM collector to pull on a schedule. Each event links to the one before by hash, so the feed is tamper-evident as a chain: a removed or altered event breaks the linkage. The endpoint is sequence-cursored so a collector can checkpoint exactly where it stopped and resume without gaps or duplicates (handleSupportPull, the audit-feed branch, engine/src/admin/support-ingest.ts).

The cursor is validated strictly and the page size is not, and the asymmetry is deliberate. afterSeq is your checkpoint, so a malformed value is refused with a 400 and { "error": "afterSeq must be a non-negative integer" } rather than being coerced to 0. Silently coercing it would replay the whole retained log on every poll and hide the client bug that produced the corrupt cursor. limit is only a page-size hint, so an out-of-range value is clamped rather than refused (handleSupportPull, engine/src/admin/support-ingest.ts).

The response is a page of events in ascending sequence order, plus the chain head, so a collector can both advance its cursor and verify continuity against the current chain tip.

{
  "kind": "downpipe-audit-feed",
  "v": 1,
  "afterSeq": 0,
  "nextAfterSeq": 412,
  "earliestSeq": 1,
  "gapBefore": false,
  "headSeq": 412,
  "headHash": "sha384:9f1c...the-current-chain-tip-hash",
  "count": 412,
  "events": [
    { "seq": 1, "ts": "2026-06-19T01:02:03.000Z", "prevHash": "sha384:...", "hash": "sha384:..." }
  ]
}

To consume the feed, poll with afterSeq set to your last nextAfterSeq, ingest the returned events, and advance your cursor. Verify continuity by checking that each event’s prevHash equals the previous event’s hash, and that the last hash you have ingested matches headHash once you have caught up. When count comes back as zero you are at the tip and nextAfterSeq equals the afterSeq you sent.

Verification is out of band

The signature on the diagnostics bundle and the hash chain on the audit feed are both verified away from the browser. The console does not hold the verifying key for the bundle, so it never verifies a signature client-side; full verification is an out-of-band step performed by whoever holds the appropriate key or runs the collector. The audit chain is likewise verified by the collector that pulls it, by walking prevHash to hash and comparing the tip to headHash. There is no client-side or in-browser verification path for either feed, which is consistent with how the rest of the product treats verification of signed artefacts.

Failure modes

Both endpoints share a small, deliberately coarse set of responses, so a caller can distinguish a wrong path, a bad credential, and a momentarily unavailable Durable Object without the surface ever becoming an oracle.

A redirect to a team login page, or any HTML where JSON was expected, is the edge talking, not the engine. It means Cloudflare Access is in front of the hostname and the collector has no way through it yet. The engine’s own responses are always JSON or a plain-text status with no detail, never an HTML page.

Where this fits

These two endpoints are the wire-level surface. For minting, using, and revoking the diagnostics credential as an Owner, see pull credentials. For the bundle’s exhaustive field list, the signed-then-sealed construction, and the four bundle states in depth, see the support bundle. For the audit log’s guarantee, how to verify the chain, and how to export it before the fixed-cap rollover, see the audit log. For standing up a collector against the audit-feed scope, see the SIEM audit feed.

Last updated 25 September 2026.