Persisting Consent

The APIs utilized by the Server-Side CMP API solution are stateless in nature so every request received will be considered new. Because of this, a new object called OTConsentObject was introduced in order to maintain the user's consent data from one instance/session to the next.

Here's a sample of the OTConsentObject. The application is not responsible for creating or manipulating the object, the API will handle the logic.

OTConsentObject:
{
    'lastLaunchDate': 'date number timestamp', 
    'shouldShowBanner’: 0/1,
    'dsid': "String",
    'appId': "String",
    'cdn': "String",
    'isAnonymous': 0/1,
    'expiryDate': 'date number timestanp';
    'lastConsentedDate': 'date number timestamp',
    'lastInteractionType': "String" ,
    'groupConsents': {‘C0001’: 0, 'C0002': 1},
    'sdkConsents': {‘S001’: 0, 'S002': 1},
}

As the application calls any of the 4 APIs in scope, the CMP API will convert the object into a Base64 format and return it in the response under otConsentString.

Here's a sample of the otConsentString:

eyJsYXN0TGF1bmNoRGF0ZSI6MTcxMzIxMTQyNjI4Nywic2hvdWxkU2hvd0Jhbm5lciI6MSwiZHNJZCI6ImI4NzViMzgyLTBhYzctNDlhOC1iZTI3LTM5MDg3OWNkNDAyYSIsImFwcElkIjoiM2UxODg1NjEtNTBmNi00NTMwLWJiNDktYWExNzgzNDM4MWM3LXRlc3QiLCJjZG4iOiJjZG4uY29va2llbGF3Lm9yZyIsImlzQW5vbnltb3VzIjoxLCJleHBpcnlEYXRlIjoxNzQ0NzQ3NDI2NTMxLCJsYXN0Q29uc2VudERhdGUiOjE3MTMyMTE0MjY1MzEsImxhc3RJbnRlcmFjdGlvblR5cGUiOiJQcmVmZXJlbmNlIENlbnRlciAtIENvbmZpcm0iLCJncm91cENvbnNlbnRzIjp7IkMwMDAxIjoxLCJDMDAwMyI6MSwiQzAwMDIiOjAsIkMwMDA0IjoxfSwic2RrQ29uc2VudHMiOnsiYWJkZmE0NjgtMmY4Ny00YzAzLWFlOWItOGZjMzFkMzQxYzZjIjoxLCIyMjUzZWM1Mi0xOGI0LTQ4NjgtOTAyZi0wMmY5YTE5ZTc5ODQiOjEsImIzNjgzMDc3LThkZjYtNDI2My05NjcyLTE0NmZjZmRlYmE4OCI6MCwiODhjZGQ5ZGYtNjNhZS00YmI3LThiZmMtNGFmNDg4MmNmZmI1IjoxfX0=

otConsentString decoded:

{
  "lastLaunchDate": 1713211426287,
  "shouldShowBanner": 1,
  "dsId": "b875b382-0ac7-49a8-be27-390879cd402a",
  "appId": "3e188561-50f6-4530-bb49-aa17834381c7-test",
  "cdn": "cdn.cookielaw.org",
  "isAnonymous": 1,
  "expiryDate": 1744747426531,
  "lastConsentDate": 1713211426531,
  "lastInteractionType": "Preference Center - Confirm",
  "groupConsents": {
    "C0001": 1,
    "C0003": 1,
    "C0002": 0,
    "C0004": 1
  },
  "sdkConsents": {
    "abdfa468-2f87-4c03-ae9b-8fc31d341c6c": 1,
    "2253ec52-18b4-4868-902f-02f9a19e7984": 1,
    "b3683077-8df6-4263-9672-146fcfdeba88": 0,
    "88cdd9df-63ae-4bb7-8bfc-4af4882cffb5": 1
  }
}

It will then be the application's responsibility to store the otConsentString in local storage and send it in subsequent calls for any of the APIs used. The consent string should be updated once a new one from the latest API used is received. The next page/section goes into more detail about how to send it in the API call.

Example workflow:

1. ☃️ First time user, banner in scope ☃️
   App launched ➡️ Banner API called, no otConsentString is passed in the header ➡️ Store the otConsentString returned from the banner response ➡️ User taps 'Allow All' on the banner ➡️
   Save and Log consent API called with otConsentString passed in the header along with preferences set in the payload ➡️
   Update the otConsentString stored with the latest one from the save consent API

2. ☃️ Returning user, preferences changed ☃️
   App launched ➡️ Banner API called with last saved otConsentString to check if a banner should be shown ➡️ Store new otConsentString from the banner API response ➡️ Call preference center API with otConsentString passed in the header ➡️ Store new otConsentString from preferences API response ➡️ User rejects all ➡️ Save consent API called with otConsentString passed in the header along with preferences set in the payload ➡️ Replace previous otConsentString with the new one from save consent API

🚧

IMPORTANT

Ensure the string is not modified or corrupted or the OneTrust API worker may not be able to ingest and decode it as expected.

FAQ

1. Is there a size limit of the otConsentString?
   The string should not exceed a typical size of 8 - 16kb. The request header itself has a size limit of 32kb.