Skip to content

Search the Omeda Knowledge Base

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

  1. GET : For looking up GDPR consent for a customer.
  2. 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:

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

{  
   "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

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

Example POST response

{  
   "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.
Last Updated On
Tags:
Knowledge Base Feedback