GDPR Permission API

Summary

This API provides capabilities to find whether a customer has given GDPR consent for a url, or to store such information to Omeda’s database.

General Technical Requirements

HTTP Headers

The HTTP header must contain the following elements: x-omeda-appid a unique id provided to you by Omeda to access your data. The request will fail without a valid id. content-type a content type supported by this resource. See Supported Content Types for more details. If omitted, the default content type is application/json.

Content Type

If omitted, the default content type is application/json. JSON application/json

JSON is the preferred data exchange format, because it is lightweight and, in most cases, faster to process and utilizes less bandwidth. There are many available open-source JSON libraries available. See json.org for details.

Supported HTTP Methods

GET : For looking up GDPR consent for a customer.
POST : For storing GDPR consent data for a customer and url.

Base Resource URI

Note: customer can be found either by customerId or anonymousId depending on which URI is used, and both GET and POST use the same URI pattern:

CODE

Production: https://ows.omeda.com/webservices/rest/brand/{brandAbbreviation}/consent/customerid/{customerId}
            https://ows.omeda.com/webservices/rest/brand/{brandAbbreviation}/consent/olyticsanonymousid/{anonymousId}

Testing:    https://ows.omedastaging.com/webservices/rest/brand/{brandAbbreviation}/consent/customerid/{customerId}
            https://ows.omedastaging.com/webservices/rest/brand/{brandAbbreviation}/consent/olyticsanonymousid/{anonymousId}

brandAbbreviation is the abbreviation for the brand customerId the encrypted or non-encrypted Omeda customer ID for the customer anonymousId the Olytics anonymous id for the customer

Field Definition

The following tables describe the data elements that can be sent to this API. In addition to the below elements, a SubmissionId element will also be returned with all responses. This is a unique identifier for the web services response. It can be used to cross-reference the response in Omeda’s database.

GET Response Elements

Consent Elements

Element Name	Always Returned…	Data Type	Description
AlternateId	No	String	this is the alternate ID for the customer (typically Olytics anonymous id)
ConsentDate	Yes	Date	the date when consent was received
ConsentDomain	Yes	String	domain for the customer consent
ConsentTypeCode	Yes	Integer	consent type (will be built upon later, as of 1/2019 it is always 1 aka website)
OmedaCustomerId	Yes	Integer	the internal customer identifier
StatusCode	Yes	Integer	0 for consent = “no”, 1 for consent = “yes”

Example GET Response

CODE

{  
   "Consents":[  
      {  
         "ConsentDate":"2018-05-17",
         "OmedaCustomerId":454824,
         "AlternateId":"05baf4ed-c969-4416-8d98-a35434180854",
         "StatusCode":0,
         "ConsentDomain":"olytics.omedastaging.com",
         "ConsentTypeCode":1
      },
      {  
         "ConsentDate":"2018-12-04",
         "OmedaCustomerId":454824,
         "AlternateId":"05baf4ed-c969-4416-8d98-a35434180854",
         "StatusCode":1,
         "ConsentDomain":"google.com",
         "ConsentTypeCode":1
      },
      {  
         "ConsentDate":"2018-03-14",
         "OmedaCustomerId":454824,
         "StatusCode":1,
         "ConsentDomain":"yahoo.com",
         "ConsentTypeCode":1
      }
   ]
}

POST Request Elements

Attribute Name	Required?	Description
ConsentDate	optional	date that consent was recorded
IpAddress	optional	IP Address that consent was received from
Url	required	url that consent relates to
Consent	required	description of the consent, should be a String “yes”, “no”, or “clr”

Example POST request

CODE

{
   "Consent":"Yes",
   "Url":"https://www.google.com",
   "ConsentDate":"2018-03-14 15:22:11"
}

Example POST response

CODE

{  
   "ResponseInfo":[  
      {  
         "Message":"Consent was updated successfully",
         "OmedaCustomerId":454824
      }
   ],
   "SubmissionId":"cd9ec7ab-46f8-4930-8cee-3cd6d839f7d6"
}

Response – Failure

If an error occurs repeatedly, please contact your Omeda representative.

HTTP Response Codes

Status	Description
400 Bad Request	Typically, this error occurs when the request does not follow the specifications.
403 Forbidden	Typically, this error occurs when the credentials are erroneous. Potentially, an incorrect x-omeda-appid.
404 Not Found	Typically, this error occurs with a malformed URL or the resource that is searched for is not found.
405 Method Not Allowed	Typically, this error occurs when the resource accessed is not allowed by the HTTP Method utilized. Make sure you employ the correct HTTP Method (POST) for this request.
500 Internal Server Error	In the rare case that there is a server-side problem, this response will be returned. This generally indicates a problem of a more serious nature, and submitting additional requests may not be advisable. Please contact Omeda Account Representative.

Table of Contents