Digital Governance
cancel
Showing results for 
Search instead for 
Did you mean: 

Training For Consent as a Service

Consent as a Service Privacy Information Collector (CaaS PI Collector) Documentation

The Consent as A Service Privacy Information Collector (CaaS PI Collector) is the data collector that customers use to send either a GET or POST requests to place their consent data into our storage structure for eventual reporting and serving.

Protocols

The GET route will work on http or https, as http will redirect to https.  However, the POST route only takes https requests.

 

Endpoints

 

GET

This endpoint has five expected query string values: c, r, u, d, a.

This endpoint has one expected header: token.

 

API Prefix

i.evidon.com/api/v1

 

Status Codes

204 - Successfully collected the request.

200 - Request hit the wrong endpoint but did not error.

All other status codes hold to their standard definitions and causes, there are no other codes outlined by the collectors.

 

Query string parameters

c - companyId: The internal identifier for the customer that is assigned at onboarding.

r - recordType:  The identifier for the type of record the customer is sending, per what they have already defined without our tool for setting up recordTypes.  This is used to make the d param interpretable.

u - userId: The identifier to tie the consent record back to the user.  If one is not passed in, one is generated based on the user's IP and useragent string.

d - data: The customer defined payload of json.  A base64 encoded as well as URI encoded string is expected here.

a - applicationId:  The internal identifier for the customer that is assigned at onboarding. 

 

Headers

token - This is generated in the CaaS dashboard.  These tokens map back to an applicationId and companyId.

The applicationId (a), companyId (c), are not needed if a token is sent, as the values from the token lookup overwrite the values from the query string.  However, the values themselves are required, so if a token is not there then they are required fields.

Example

An example request might look something like: 

https://i.evidon.com/api/v1?d=eyJ0ZXN0YWtleSI6InRlc3RhdmFsdWUiLCJ0ZXN0YmtleSI6InRlc3RidmFsdWUiLCJ0ZXN0Y2tleSI6InRlc3RjdmFsdWUiLCJ0ZXN0ZGtleSI6InRlc3RkdmFsdWUifQ==&u=abcdefg123456&r=customRecordType&a=1&c=242

With the header:

token: 863effdf6cf94d2d9971640dcc393ae3

And as far as generating the base64 encoded string, something along the lines of:

let jsonObj = {"testkey": "testvalue"};

let stringJsonObj = JSON.stringify(jsonObj);

let encodedJsonObj = Buffer.from(stringJsonObj).toString('base64');

let uriEncodedJsonObj = encodeURI(encodedJsonObj);

 

POST

This endpoint has two expected headers: token, content-type.

This endpoint expects a JSON body with five values: c, r, u, d, a.

 

API prefix

i.evidon.com/api/v1

 

Status Codes

204 - Successfully collected the request.

200 - Request hit the wrong endpoint but did not error.

Headers

token - This is generated in the CaaS dashboard. These tokens map back to an applicationId and companyId.

content-type - This should be application/json every time.

Body

c - companyId: The internal identifier for the customer that should have been assigned at onboarding. 

r - recordType: this is the identifier for the type of record the customer is sending us, per what they have already defined without our tool for setting up recordTypes.  This is used to make the d param interpretable.

u - userId: this is the identifier that is used for tying the consent record back to the user. If one is not passed in, one is generated based on the user's IP and useragent string.

d - data: this is the customer defined payload of json.  This is json object wrapped in the parent json that is the rest of the body.

a - applicationId: this is our internal identifier for the customer that should have been assigned at onboarding. 

The applicationId (a), companyId (c), are not needed if a token is sent, as the values from the token lookup overwrite the values from the query string.  However, the values themselves are required, so if a token is not there then they are required fields.

Example

An example request might look something like:

https://i.evidon.com/api/v1

With the headers:

token: 863effdf6cf94d2d9971640dcc393ae3

content-type: application/json

With the body:



   "c":242,

   "r":"customRecordType",

   "u":"abcdefg123456",

   "a":"1",

   "d":{ 

      "testakey":"testavalue",

      "testbkey":"testbvalue",

      "testckey":"testcvalue",

      "testdkey":"testdvalue"

   }

}

A demo site using multiple record types:  http://caas-demo.evidon.com/

 

Labels (3)
Version history
Revision #:
2 of 2
Last update:
‎08-14-2019 03:22 PM
Updated by:
 
Contributors
Looking for more?
Ask in Discussions
Developers

Peer-to-peer support  and answers on developing CMS templates, modifying privacy scripts or building integrations.

Digital Experience Management

Find answers and ask questions on content management, personalization and targeting.

Digital Quality Management

Find answers and ask questions on WCAG and SEO quality management.

Digital Governance

Find answers and ask questions on consent and monitoring solutions.