Gigya Job Openings

Using the REST API

Skip to end of metadata
Go to start of metadata

Introduction

The SAP Customer Data Cloud REST API is at the core of our platform. On top of the REST API, SAP Customer Data Cloud offers a set of Server Side SDKs that wrap around the API. The Server Side SDKs make it simple to integrate our service in server applications of various development environments.

Check out our Server Side SDKs documentation and find out if there is an SDK available for your preferred language. Otherwise, please continue with this guide and learn how to use our REST API directly.

Requests

The SAP Customer Data Cloud server-to-server API uses a REST-like interface. This means that the API method calls are made over the internet by sending HTTP GET or POST requests to the SAP Customer Data Cloud REST API server and the response is returned as JSON / JSONP. In some cases, the response may also be returned in XML, for backward compatibility. Nearly every software development environment provides methods for communicating over HTTP with a REST server.

Requests to our REST API should be signed for security purposes. The recommended best practice is to generate a bearer token for the signature. An alternative solution is to use application or user keys and a secret. In addition, the less recommended approach is to use the OAuth 2.0 standard or our proprietary authorization method. Use one of the following guides to start making REST API calls, using your preferred authorization method:

 

The REST API Reference provides specification to the various supported API methods.

Important: When using the REST API, all post data must be URL Encoded prior to being sent to the SAP Customer Data Cloud server, whether in the query or body of the request. If sending in the body, all parameters must be of content-type "www-form-urlencoded".

Handling Unknown Parameters

When calling an API, parameters that are not found in the method signature are ignored and discarded by default, allowing the request to be processed. In such a case, any parameters which have been ignored appear in the response, as follows:

 

{
  "statusCode": 200,
  "errorCode": 0,
  "statusReason": "OK",
  "callId": "b0cce660845e4e40bf3d4663953564f3",
  "time": "2015-01-04T08:48:28.537Z",
  "ignoredParams": [
    {
      "paramName": "ignoreMe",
      "warningCode": 403007,
      "message": "This parameter was not recognized as valid for this API method with your security credentials nor was it recognized as a standard Gigya control parameter."
    }
  ]
}

To force an API call to fail with an error response when unknown parameters are encountered, pass the 'checkParams' control parameter with a value of 'true'.

This parameter can be passed for all API calls, and if its value is 'true', the server will return an error for any undefined parameter that was passed in the request (on a first find policy). See below the response from the same request as the example above, however, this time with checkParams=true:

 

{
  "errorMessage": "Permission denied",
  "errorDetails": "These parameters were not recognized as valid for this API method with your security credentials nor were they recognized as standard Gigya control parameters: ignoreMe",
  "statusCode": 403,
  "errorCode": 403007,
  "statusReason": "Forbidden",
  "callId": "2b5401d43d664fc1846b02d2e26733f3",
  "time": "2015-01-04T09:01:57.746Z"
}