Osano Consent Management API
Official vendor OpenAPI document · agent-readySecurityComplianceapiKey14 EndpointsREST
For 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.
Use for: Record a user's cookie consent decision, Get the current consent status for a subject, Open a GDPR data deletion request for a customer, List all open data subject requests
Not supported: Does not handle authentication, payment processing, or marketing email delivery - use for consent capture, DSR workflows, and cookie disclosure only.
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.
Install Jentic One Beta
Connect the Osano Consent Management API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Osano Consent Management API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fosano.com%2Fosano" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fosano.com%2Fosano" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Osano Consent Management API.
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
Patterns agents use Osano Consent Management API for, with concrete tasks.
★ 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.
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.
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.
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.
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
14 endpoints — the osano consent management api is the programmatic backbone of osano's privacy platform.
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
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
Why Jentic?
What agents get from Jentic-routed access to this vendor.
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 isolation
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.
Intent-based discovery
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
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Osano Consent Management API through Jentic.
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.
GET STARTED