Consent-Receipt Integrity Binding

curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/recording-consent/integrity" \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "call_id": "call_9f2ab1",
    "consent_receipt_id": "rcpt_a1b2"
  }'

{
  "data": {
    "verified": true,
    "consent_receipt_id": "rcpt_a1b2",
    "binding_status": "bound"
  },
  "meta": {
    "request_id": "req_j1r9",
    "timestamp": "2026-09-27T14:05:11.000Z"
  }
}

curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/recording-consent/integrity" \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "call_id": "call_9f2ab1",
    "consent_receipt_id": "rcpt_a1b2"
  }'

{
  "data": {
    "verified": true,
    "consent_receipt_id": "rcpt_a1b2",
    "binding_status": "bound"
  },
  "meta": {
    "request_id": "req_j1r9",
    "timestamp": "2026-09-27T14:05:11.000Z"
  }
}

A recording-consent receipt states “the parties on this call consented to recording”. A recording file holds the audio. On their own, neither proves the two belong together — a stored receipt carries a plain recording pointer, so audio could be swapped under the same id and the pointer would still resolve. Orbit’s recording surface already seals each recording with a content SHA-256 and a per-tenant tamper-evident hash chain (see Call Recording Consent for the recording surface). The consent-receipt integrity binding chains one more link:

consent receipt → recording content hash + integrity-chain hash → signature

Orbit mints a portable, HMAC-signed digest that binds the receipt’s immutable fields to the bound recording’s content hash and (when the recording is sealed) its integrity-chain hash. Any later edit to the receipt, a swap of the audio bytes, or a re-pointed recording pointer invalidates the signature. You can ship the digest alongside an exported recording so a downstream auditor — finance, healthcare eDiscovery, or outside counsel — can verify provenance without API access, the same posture the signed export digest gives recordings.

The binding is tenant-owned and optional. Orbit never mandates it; you configure the posture you want and call the digest endpoints only if you need auditable receipt-to-recording provenance. This page describes platform tooling, not legal advice.

Endpoints

Two endpoints on the recording-consent API surface handle issuance and offline verification:

Operation	Endpoint
Mint a digest	`POST /api/v1/compliance/recording-consent/integrity`
Verify a digest	`POST /api/v1/compliance/recording-consent/integrity/verify`

Mint a digest

Send the call and receipt identifiers; Orbit resolves the receipt rows and the bound recording’s seal, signs the digest, and returns it.

curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/recording-consent/integrity" \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "call_id": "call_9f2ab1",
    "consent_receipt_id": "rcpt_a1b2"
  }'

The response data is the full signed digest object (schema below). A 404 with RECORDING_CONSENT_RECEIPT_NOT_FOUND means the receipt id did not resolve to a live row for this call — capture consent before minting a digest.

Verify a digest

Submit the full digest object back; Orbit recomputes the signature over the signed fields and reports whether it is intact. Verification performs no writes.

curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/recording-consent/integrity/verify" \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "digest": {
      "consent_receipt_id": "rcpt_a1b2",
      "call_id": "call_9f2ab1",
      "recording_id": "rec_7c9d",
      "consent_method": "ivr_announcement",
      "consent_state": "granted",
      "jurisdiction": "us-ca",
      "consent_text_version": "v1",
      "captured_by": "user_84kd",
      "captured_at": "2026-09-27T14:03:11.000Z",
      "revoked": false,
      "recording_content_sha256": "8f…3a",
      "recording_integrity_hash": "c2…9b",
      "binding_status": "bound",
      "issued_at": "2026-09-27T14:05:02.000Z",
      "signature": "0d…e4"
    }
  }'

{
  "data": {
    "verified": true,
    "consent_receipt_id": "rcpt_a1b2",
    "binding_status": "bound"
  },
  "meta": {
    "request_id": "req_j1r9",
    "timestamp": "2026-09-27T14:05:11.000Z"
  }
}

verified: false tells you the submitted digest was altered after issuance (or the signature hex was malformed) — treat it as a failed provenance check, not a transport error.

Digest schema

The signed payload carries every field a verifier needs; the signature is an HMAC-SHA256 (hex) over the canonicalised field set below (sorted-key canonicalisation, so key order is irrelevant but the field set must match exactly).

Field	Type	Meaning
`consent_receipt_id`	string	Logical receipt id the audit trail groups its rows under.
`call_id`	string	The call the receipt and recording anchor to.
`recording_id`	string \| null	Bound recording id, or null when consent predates the artifact.
`consent_method`	string	How consent was captured (for example `ivr_announcement`).
`consent_state`	string	`granted`, or `declined` if any party row declined.
`jurisdiction`	string \| null	Jurisdiction tag recorded at capture.
`consent_text_version`	string	Version of the disclosure text presented.
`captured_by`	string	User id (or `system`) that captured the consent.
`captured_at`	string (ISO-8601)	Earliest capture instant across the receipt’s party rows.
`revoked`	boolean	True when any party row has been withdrawn (GDPR Art 7(3)).
`recording_content_sha256`	string \| null	SHA-256 hex of the recording’s media bytes.
`recording_integrity_hash`	string \| null	The recording seal’s current chain hash, when sealed.
`binding_status`	enum	One of the four binding statuses below.
`issued_at`	string (ISO-8601)	Instant the digest was issued. Re-issuing the same fields at the same instant reproduces the same signature.
`signature`	string	HMAC-SHA256 (hex) over the canonicalised fields above.

Binding statuses

`binding_status`	Meaning
`bound`	Receipt is bound to a sealed recording — both the content hash and the integrity-chain hash are present.
`bound_unsealed`	Recording exists with a content hash but no integrity-chain seal yet; the digest still binds the content bytes.
`recording_unavailable`	The receipt points at a recording, but that recording row is missing or tombstoned (for example after GDPR erasure). The receipt audit trail outlives the audio, so this is an expected terminal state, not an error.
`unbound_no_recording`	The receipt carries no recording pointer — consent was collected before the artifact finalised.

recording_unavailable and unbound_no_recording still produce a signed digest: the absence of a recording is part of the attested provenance and is itself data you hand to an auditor.

Configuring a tenant posture

Per Orbit’s tenant-owned compliance model, this binding is an optional, tenant-controlled posture — never a platform mandate. Decide and document your posture:

Off (default posture). If receipt-to-recording provenance is not a requirement, do nothing — receipts and recordings still exist; you simply never mint a digest.
Evidentiary posture on. Mint a digest at (or immediately after) recording completion for calls flagged by your compliance checklist, and store the digest object alongside the exported recording artifact. Verification is then a stateless replay: recompute the signature and compare, without re-deriving from live rows.

Whatever posture you pick, record it in your internal compliance runbook so an auditor can see the decision was deliberate. Issuing and verifying digests is audit-logged under the digest-issuance action.

Privacy-carve risks

Two deliberate design choices shape what the binding does and does not do:

Nothing new is stored. The digest is computed deterministically from already-persisted receipt rows, the recording seal, and the platform signing secret, then returned to you — it is stored nowhere on Orbit’s side. Re-issuing with the same fields and issued_at instant reproduces the same signature, so loss of a stored digest is recoverable and the signing surface stays minimal.
Receipts outlive recordings. When a GDPR erasure tombstones the recording, the receipt row survives (the audit trail is the point), and any digest already issued flips to a well-defined terminal status: recording_unavailable. Verification of that earlier-issued digest still succeeds, because the signature was minted over the fields that described the binding at issuance time — but any new digest you mint after erasure attests recording_unavailable rather than bound.

Keep both facts in mind when you design your evidence binder: store the digest next to the exported artifact while the artifact exists, and treat recording_unavailable on a fresh issuance as an expected post-erasure state rather than a tamper signal.

Getting Started

Channels

Channels (Voice)

AI Agents

Flows

Numbers & Verify

Concepts

Features

Billing

Webhooks

Security & SSO

Compliance

Legal

Brand & press

Changelog

Endpoints

Mint a digest

Verify a digest

Digest schema

Binding statuses

Configuring a tenant posture

Privacy-carve risks

​Consent-Receipt Integrity Binding

​Endpoints

​Mint a digest

​Verify a digest

​Digest schema

​Binding statuses

​Configuring a tenant posture

​Privacy-carve risks

Consent-Receipt Integrity Binding

Endpoints

Mint a digest

Verify a digest

Digest schema

Binding statuses

Configuring a tenant posture

Privacy-carve risks