Skip to main content
GET
Fetch a signed SMLTP compliance receipt

Compliance Receipts

When a completion is routed through the SMLTP gateway, SecureAI produces a signed compliance receipt — cryptographic proof of the policy that governed the call. This endpoint fetches that receipt by its bundle id. Receipts exist only for gateway-routed deployments. On direct-provider deployments there is no gateway to sign receipts, and this endpoint returns 404.

Endpoint

Where the bundle id comes from

Completion responses expose the bundle id whenever an SMLTP entitlement is minted for the call:
  • Classic endpoint: metadata.smltp.bundle_id (and a ready-made metadata.smltp.receipt_url).
  • OpenAI-compatible endpoint: secureai.smltp_bundle_id.
The bundle id (an entitlement id such as jti-…) is returned even on native/direct-provider deployments. The signed receipt at that id, however, only exists when traffic is routed through the SMLTP gateway — on direct deployments this endpoint returns 404 (see below).

Authentication

Request Example

Response

200 OK

The receipt object is the signed payload emitted by the gateway. See SMLTP Security for how receipts fit into the transparency and audit model.

404 Not Found

400 Bad Request

Returned when the bundle id is missing or longer than 128 characters.

Notes

  • Receipts are held in the gateway’s in-memory store for a limited time. For long-term proof, rely on the hash-chained audit log — the authoritative, immutable record. See Immutable Logs.
  • Not every deployment routes through the gateway; treat a 404 as “no gateway receipt for this call,” not an error in your integration.

Authorizations

Authorization
string
header
required

API key authentication using Bearer token format. Example: Authorization: Bearer sk-your-api-key-here

Path Parameters

bundleId
string
required
Maximum string length: 128

Response

The signed receipt object