canonical: https://jentic.com/apis/osano.com/osano

# Osano Consent Management API

The Osano Consent Management API is the programmatic backbone of Osano's privacy platform. It records and retrieves user consent decisions, runs data subject rights (DSR) workflows for access, deletion, and portability requests, manages cookie and vendor consent across web properties, and exposes consent analytics. With 14 endpoints across Consent, DSR, Vendors, Configuration, and Analytics, Osano is built for teams meeting GDPR, CCPA, LGPD, and similar regulatory regimes.

## For AI agents

Record and retrieve user consent, automate GDPR and CCPA data subject requests, and manage cookie consent across websites through Osano. Agents can capture consent receipts and orchestrate DSR fulfilment.

## Scope

Does not handle authentication, payment processing, or marketing email delivery - use for consent capture, DSR workflows, and cookie disclosure only.

## Capabilities

- Record a user's consent decision with subject ID, purpose, and timestamp
- Retrieve the current and historical consent state for a given subject
- Open, list, and update data subject rights requests for access, deletion, and portability
- Look up vendor and tracker disclosures used by an Osano-protected property
- Pull consent analytics aggregated across web properties
- Apply configuration changes to consent banners and disclosure rules

## Use cases

### Server-Side Consent Capture

Web and mobile apps post consent decisions to /consent so the consent of record lives in Osano rather than in localStorage or a cookie alone. The endpoint accepts subject ID, purpose, and decision, returning a consent receipt that can be referenced in audit logs. Integration takes a day for a single property, longer when multiple jurisdictions and purposes need separate purpose strings.

Example prompt: Record consent for subject 'user-42' to purpose 'marketing_email' with decision 'true' by POSTing the consent payload to /consent.

### Data Subject Request Automation

Privacy teams automate intake and tracking of data subject requests with the /dsr endpoints. Agents create a request via POST /dsr with subject identifiers and request type, then list and update outstanding cases via GET and PUT `/dsr/{dsrId}.` This replaces email-based DSR queues and gives compliance teams a structured trail for each access, deletion, or portability request.

Example prompt: Create a deletion DSR for subject 'jane.doe@example.com' by POSTing to /dsr with type 'deletion', then poll GET `/dsr/{dsrId}` until status changes from 'open' to 'completed'.

### Consent History Audit

Auditors and DPOs use GET `/consent/history` and GET `/consent/subject/{subjectId}` to reconstruct exactly what a user consented to and when. The history endpoint returns paginated decisions with timestamps and purposes, which is essential for proving compliance during regulator inquiries. Pairing this with internal user IDs lets the agent retrieve the full consent timeline for any customer in a single call.

Example prompt: Retrieve the consent history for subject 'user-42' by calling GET `/consent/subject/user-42` and return the timeline of purpose decisions.

### AI Agent Privacy Workflow via Jentic

Customer service AI agents that handle privacy questions need to look up consent and open DSRs without privileged credentials in their prompts. Through Jentic, the agent searches for 'open a data subject request', loads the POST /dsr schema, and executes the call with a scoped API key held in the vault. This keeps Osano's API key off the agent's transcript while still enabling end-to-end DSR intake.

Example prompt: Use Jentic to search 'open a data subject request', load the POST /dsr schema, and execute it with the customer's email and request type from the conversation.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/consent` | Record a consent decision |
| GET | `/consent/{consentId}` | Retrieve a consent receipt by ID |
| GET | `/consent/subject/{subjectId}` | Get all consent decisions for a subject |
| GET | `/consent/history` | List historical consent decisions |
| POST | `/dsr` | Create a data subject request |
| GET | `/dsr` | List data subject requests |
| GET | `/dsr/{dsrId}` | Get a specific DSR |
| PUT | `/dsr/{dsrId}` | Update a DSR's status |

## Key resources

- **Consent** — Record, retrieve, and audit user consent decisions and history
- **DSR** — Create, list, and update data subject rights requests for access, deletion, and portability
- **Vendors** — Vendor and tracker disclosures used by Osano-protected properties
- **Configuration** — Consent banner and disclosure configuration for properties
- **Analytics** — Aggregated consent analytics across properties

## Why Jentic

- **Setup:** Wiring the Osano Consent Management API by hand means setting up its X-API-Key header auth and mapping the consent, DSR, and history routes yourself. Through Jentic you install once, import Osano from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** You choose which Osano operations the agent may call, so you can limit it to the operations it needs, such as reading consent records and consent history, while opening a data subject request or updating one stays out of the allowed set unless you add them.
- **Credential handling:** Your Osano API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'record a consent decision' or 'open a data subject request', and Jentic returns the matching Osano operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Segment API** — Segment routes customer events while Osano enforces consent over which destinations they reach.
- **Mixpanel API** — Mixpanel records product analytics events that should be gated on consent decisions captured in Osano.
- **Auth0 Management API** — Auth0 stores user identities; Osano stores their consent decisions linked to those identities by subject ID.

## FAQ

### What authentication does the Osano Consent Management API use?

Osano uses an API key passed as an HTTP header. The OpenAPI spec declares a single apiKey scheme with the key supplied in a request header. Through Jentic the API key is stored encrypted in your Jentic One instance and injected at call time, so it never appears in an agent prompt or logs.

### Can I open a GDPR data subject request with the Osano API?

Yes. POST /dsr creates a new data subject request, accepting the subject's identifiers and the request type (access, deletion, or portability). You list outstanding cases with GET /dsr and update status with PUT `/dsr/{dsrId}` as the request moves through review, fulfilment, and closure.

### What are the rate limits for the Osano Consent Management API?

The OpenAPI spec does not declare hard rate limits; in practice Osano applies per-tenant fair-use throttling and returns a 429 status with a Retry-After header when a tenant exceeds its limit. For high-volume consent capture, batch decisions and back off on 429.

### How do I record a consent decision through Jentic?

Through Jentic, search for 'record user consent', load the POST /consent schema, and execute it with the subject ID, purpose, and decision boolean. Jentic injects the Osano API key from the vault and returns the consent receipt with its consentId.

### Can the Osano API return historical consent for a single user?

Yes. GET `/consent/subject/{subjectId}` returns the full consent history for a subject, and GET `/consent/history` returns a paginated cross-subject log filtered by date or purpose. Use the per-subject endpoint when fulfilling a DSR access request, and the cross-subject log for audit reporting.

### Is the Osano API free to use?

Osano has a free tier with limited monthly traffic suited for evaluation; production use is on paid plans tied to monthly visitors and properties. The API itself is included with all paid plans at no per-call cost.

### Can I limit what my agent is allowed to do with the Osano Consent Management API?

Yes. Jentic One is self-hosted, so your own rules decide which Osano operations and credentials the agent may use. You can allow read-only calls such as GET `/consent/subject/{subjectId}` for a subject's consent history and GET `/consent/history`, while leaving write operations like POST /dsr to open a data subject request or PUT `/dsr/{dsrId}` to update one out of the allowed set unless you add them. Because the scope is set by the operator, the agent can only invoke the Osano endpoints you have explicitly granted it.