OneTrust is committed to providing reliable and timely API services. As such, we're working based on certain service level objectives (SLOs) to maintain the integrity of the services. For clarity, these service levels are objectives only and not a commitment or guarantee.
Overview
Universal Consent & Preference Management APIs are in an available state 99% of the time. Requests have a 99% latency within their satisfactory threshold of 500ms or less and less than 0.5% of requests return a 5XX error status response.
The service is considered available when the service is above its Service Level Objective (SLO) and the error rate is below its Service Level Objective (SLO). The service needs to simultaneously meet both of its SLO targets to be considered available. If either target is not met, the service is considered unavailable. For example, if the service becomes unavailable for a 10-minute period, the availability score will be 99.90% for the week (1 430 minutes of availability out of 1 440 minutes in a week) and 99.97% for the month (43 190 minutes of availability out of 43 200 minutes in the month.)
API Uptime
- The POST /v1/consentreceipts API has a 99.99% uptime.
- The GET /v3/datasubject-profiles has a 99.95% uptime.
- The GET /v3/datasubjects/profile has a 99.95% uptime.
Availability during Maintenance Periods
The following endpoints remain available during maintenance:
- POST /privacyportalxx.onetrust.com/request/v1/consentreceipts
- GET /preferences/v3/datasubjects/profile
- GET /preferences/v3/datasubject-profiles
- GET /v1/preferences
- GET /v4/datasubjects
- GET /v4/linktokens
Additionally, preference centers remain accessible during maintenance periods.
All other consent endpoints are not available during maintenance periods.
Consents that trigger during a maintenance period will queue up and trigger integration workflows once the maintenance period is over.
API Response
99% of the time, a response will be returned < 500 ms for the following APIs:
- POST /v1/consentreceipts
- GET /v1/datasubjects/profiles
- GET /v1/preferences
- GET /v1/receipts
- POST /v2/receipts
- GET /v3/datasubjects/profile
99% of the time, a response will be returned < 1000 ms for the following API:
- GET /v2/preferences
95% of the time, a response will be returned < 1000 ms for the following APIs:
- GET /v4/datasubjects/basic-details
- GET /v4/datasubjects/details
- GET /v4/datasubjects/ds-profiles
- GET /v4/datasubjects/profiles/{purposeGuid}
API Performance Based on Page Size
- GET /v3/datasubject-profiles
The performance of this API will vary depending on the page size of results:
- Between 1000-2000 data subjects, 98% of the time, a response will be returned < 5 seconds.
- Between 500-1000 data subjects, 99% of the time, a response will be returned < 3 seconds.
- For 500 data subjects, a response will be returned < 2 seconds.
- For 20 data subjects (default), a response will be returned < 2 seconds.
Universal Consent & Preference Management API Performance
- POST /v1/consentreceipts writes to storage in < 5 seconds 99% of the time.
- Data is available from GET /v1/receipts in < 5 seconds 99% of the time.
- Data is available from POST /v2/receipts in up to 30 seconds 99% of the time.
Data Availability
- New data is available from GET /v1/datasubjects/profiles in up to 30 seconds 99% of the time.
- New data is available in GET /v1/preferences (Cross Device) returns payload in up to 30 seconds 99% of the time.
- New data is available from GET /v3/datasubject-profiles in up to 30 seconds 99% of the time.
- New data is available from GET /v3/datasubjects/profile in up to 30 seconds 99% of the time.
Example Workflow Scenarios
Scenario #1: GET /v1/receipts
- When a call is made to POST /v1/consentreceipts for a data subject, the user should wait five seconds before trying to retrieve the receipt by making a call to the GET /v1/receipts API.
Scenario #2: POST /v2/receipts
- When a call is made to POST /v1/consentreceipts for a data subject, the user should wait five seconds before trying to retrieve the receipt by making a call to the POST /v2/receipts API.
Scenario #3: GET /v1/datasubject/profiles
- When a call is made to POST /v1/consentreceipts for a data subject, the user should wait up to 30 seconds before trying to retrieve the data subject profile by making a call to the GET /v1/datasubjects/profiles API.
Scenario #4: GET /v3/datasubjects/profile or GET /v3/datasubject-profiles
- When a call is made to POST /v1/consentreceipts for a data subject, the user should wait up to 30 seconds before trying to retrieve the data subject profile by making a call to the GET /v3/datasubjects/profile or the GET /v3/datasubject-profiles APIs.
Scenario #5: GET /v1/preferences
- When a call is made to POST /v1/consentreceipts for a data subject, the user should wait up to 30 seconds before trying to retrieve the data subject preferences by making a call to the GET /v1/preferences API.