> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # CCPA/CPRA Posture: Consumer Rights on Orbit > Map the CCPA/CPRA consumer-rights verbs — know, delete, correct, opt out of sale, limit sensitive PI, non-discrimination — onto Orbit's operator DSAR verbs and the self-service portal, run the 45-day SLA clock, and wire California's state-level gating into the rest of your posture. # CCPA/CPRA Posture: Consumer Rights on Orbit The [DSAR](/compliance/dsar) page documents the request pipeline end to end; this guide is the CCPA/CPRA posture around it — which consumer-rights verb covers which statutory right, when to apply it, how California's state-level gating interacts with the request lifecycle, and how the jurisdiction code and `consumer_categories` subdivision carry through your organisation's records. It is the California counterpart to [Assembling a GDPR Posture End to End](/compliance/gdpr-posture-guide), and it sits in the same per-jurisdiction posture group in the nav. This page describes Orbit's platform controls. It is **not legal advice.** Whether CCPA/CPRA applies to you — the revenue, volume, or data-sale thresholds in Cal. Civ. Code §1798.140(d), the service provider vs. contractor distinction, what "selling" or "sharing" covers for your use — depends on your business. Confirm with qualified counsel. ## The tenant-owned framing Same model as every other posture on Orbit ([posture overview](/compliance/posture-overview)): * **Every control here defaults open.** A new tenant has no pending requests, no portal link published, no retention window set, and no binder generations. Nothing on this page is mandated, and nothing here gates sending by itself — you assemble the posture; the platform enforces what you set. * **Orbit is the conduit and the ledger.** It carries the request from intake to fulfilment, runs the verification gate and the SLA clock, and keeps the auditable record. It never decides whether CCPA/CPRA applies to you, never files with the California Privacy Protection Agency or the Attorney General for you, and never answers a consumer's legal question on your behalf. * **Statutory citations below are signposts, not determinations.** The platform tracks the clock and the verbs; whether a specific request is valid, which exemption applies (for example the B2B or employee carve-outs), or whether 45 days is shortenable in your case sits with your counsel. *** ## Section 1 — The consumer-rights verb map The CCPA (2018) and its CPRA amendment (effective 2023) define eight consumer rights. Each maps onto an operator `request_type` on `POST /compliance/dsar`; the public portal exposes a friendlier subset that resolves onto the same verbs. The full intake, schema, and portal flow are on [DSAR](/compliance/dsar) — this table is the posture view. | Statutory right | Citation | Operator `request_type` | Public portal verb | | -------------------------------------------------------------------------------------------------- | ------------------------------ | ----------------------- | ------------------ | | **Right to know** — what PI you collect, use, disclose, sell | §1798.100, §1798.110 | `know` | `access` | | **Right to delete** | §1798.105 | `delete` | `delete` | | **Right to correct** inaccurate PI | §1798.106 (CPRA) | `correct` | — | | **Right to data portability** | §1798.100(d) / §1798.130(a)(2) | `portability` | `portability` | | **Right to opt out of sale/share** — including "sharing" for cross-context behavioural advertising | §1798.120 | `opt_out_sale` | `opt_out` | | **Right to limit use of sensitive PI** | §1798.121 (CPRA) | `limit_sensitive_pi` | — | | **Right to non-discrimination** for exercising a right | §1798.125 | `non_discrimination` | — | Two structural notes: * **The statutory clock is 45 days.** Filing a request with `applicable_jurisdiction: "ccpa"` or `"cpra"` starts a 45-day SLA clock — the response window in §1798.130(a)(2). The SLA dashboard tiers scale to that window (amber at 30–38 days, red at 39–45, breach past 45; escalation flagged at day 40). Track it with `GET /compliance/dsar/sla`, detailed on [DSAR](/compliance/dsar#sla-dashboard). * **The CCPA-only verbs refuse a GDPR jurisdiction.** `opt_out_sale`, `limit_sensitive_pi`, and `non_discrimination` have no GDPR equivalent, so filing one without setting `applicable_jurisdiction: "ccpa"` or `"cpra"` is rejected with `422 VALIDATION_ERROR` — the `gdpr` default only covers rights that exist under GDPR. ## Section 2 — When to apply each verb The pipeline is rights-driven, not request-driven: you file the verb the consumer actually asked for, and higher-assurance verbs require an operator verification decision before fulfilment proceeds ([DSAR → Verify or reject identity](/compliance/dsar)). * **`know`** — access requests. For California consumers you usually attach `consumer_categories` to scope the answer; the subdivision is in Section 4. * **`delete`** — erasure. Tracked as its own resource so you can audit and intervene before data is destroyed, with a signed proof-of-deletion certificate once it executes — the receipt a consumer or regulator holds as evidence the §1798.105 right was fulfilled ([DSAR → Proof-of-deletion certificate](/compliance/dsar)). * **`correct`** — CPRA's rectification right. Also the nearest verb for a restriction-style claim where accuracy is disputed — file the accuracy half as `correct` and narrow processing in parallel (see the worked pair on [DSAR](/compliance/dsar)). * **`portability`** — machine-readable export. Lands as a signed, time-limited download link on the request row. * **`opt_out_sale`** — sale/share opt-out under §1798.120, including cross-context behavioural-advertising "sharing" added by the CPRA. Fulfilment flows into the same suppression layer every send reads ([Opt-Out & Suppression Lists](/compliance/opt-out-suppression)), so the opt-out is enforced before dispatch, not merely recorded. * **`limit_sensitive_pi`** — CPRA's §1798.121 restriction on using sensitive PI beyond authorised purposes. File it to narrow processing in a lawful, tracked way; it is also the CCPA/CPRA analog you pair with a GDPR restriction claim. * **`non_discrimination`** — §1798.125 claims. Rare in practice, but filing them on the same pipeline keeps them against a 45-day clock with the rest. A request filed under the wrong verb still burns the clock — the reclassification path is operator-side (`applicable_jurisdiction` and `request_type` can be corrected after intake), so reclassify early rather than letting a mis-filed `know` ride out as one. *** ## Section 3 — California's state-level gating in the posture CCPA/CPRA is a **US state** law, not a federal one — and Orbit's country map reads the US as one row while California rides as a state-level jurisdiction inside it. Two consequences to hold together: 1. **The country map stays country-shaped.** [Country rules](/compliance/country-requirements) and the [country-rules console](/guides/compliance-country-rules-console) carry one US row per channel (`iso: "US"`) — what the destination accepts, sender registration, opt-out text. Answering "what does California add?" is a posture question you answer *here*, on the state-jurisdiction surfaces below — the map deliberately does not fragment countries into states. 2. **State-level gating is handled on three surfaces, and none of them touches the DSAR lifecycle itself:** | Surface | What it gates | Where it resolves state to | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | **Outbound dialing windows** | The federal TCPA window plus the mini-TCPA state overlays — the intersection computes the binding send window | [US Calling Windows](/compliance/state-calling-windows) | | **Recording/consent gates** | Two-party-consent states (California among them) at set-time | The area-code → state union map, consumed identically by the quiet-hours and consent gates | | **Jurisdiction codes** | A fine-grained code (`US-CA`, `EU`, `UK`, …) stamped at write time on records such as call recordings, so the erasure sweep and the regulatory-audit read can resolve the jurisdiction | [Data residency](/compliance/data-residency-overview) | **How that interacts with the DSAR lifecycle:** the DSAR lifecycle is fully driven by the jurisdiction you file **at intake**. When a California consumer files — or you reclassify an incoming request — `applicable_jurisdiction: "ccpa"` or `"cpra"` starts the 45-day clock, and `request_type` picks from the CCPA-only verbs. The `US-CA` code on a record simply tells fulfilment and audit reads which rows fall under the California jurisdiction; it does not gate intake, verification, or the clock. Keep the two wires separate: state gating on send/recording surfaces, jurisdiction-at-intake on the DSAR pipeline, and nothing on either surface blocks the other. *** ## Section 4 — The organisational subcategories the API accepts For access requests (`request_type: "know"`) you can attach `consumer_categories` — the CCPA §1798.100(b) notice-at-collection categories the consumer is asking about. The compliance API accepts GDPR and CCPA/CPRA classes together; this subdivision is the CCPA one. The full enum is defined on [DSAR → Request types](/compliance/dsar#request-types) and the [API reference](/api-reference/endpoints/compliance); the values: `identifiers`, `customer_records`, `protected_classifications`, `commercial`, `biometric`, `internet_activity`, `geolocation`, `sensory`, `professional`, `education`, `inferences`, `sensitive_pi`. Scope the answer with the category list that matches what the notice-at-collection covers: an access request that asks about `internet_activity` and `geolocation` fulfils against those two categories, not against the whole enum. The list is also what your organisation's own records (the [privacy register](/compliance/privacy-register) activities and the [evidence binder](/compliance/evidence-binder) export) should mirror so the consumer-facing answer and the internal record agree. *** ## Section 5 — Where this page sits in the posture group This page sits in the Compliance nav group alongside the other per-jurisdiction posture guides — [GDPR](/compliance/gdpr-posture-guide), [TCPA](/compliance/tcpa-posture-guide), [STIR/SHAKEN](/compliance/stir-shaken-posture-guide), and [HIPAA](/compliance/hipaa-posture-guide) — and the California wire it documents reads four sibling surfaces: the [country rules](/compliance/country-requirements) map, the [state calling windows](/compliance/state-calling-windows) intersection, the [DSAR](/compliance/dsar) pipeline itself, and the [consent](/compliance/consent-management) records an opt-out lands on. ## Related references * [DSAR](/compliance/dsar) — intake, verification, SLA clock, the proof-of-deletion certificate. * [Posture overview](/compliance/posture-overview) — the tenant-owned framing this guide extends. * [Country Compliance Requirements](/compliance/country-requirements) — the country-map row the California wire rides inside. * [State Calling Windows](/compliance/state-calling-windows) — the federal+state intersection for US sends. * [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) — the suppression layer an `opt_out_sale` fulfilment writes into. * [Consent Management](/compliance/consent-management) — the consent records a California request may ask you to honour. * [Evidence Binder](/compliance/evidence-binder) — the export that reads your request history back for a buyer or authority. * [API Reference → Compliance](/api-reference/endpoints/compliance) — full request/response schemas (regenerated from the live API).