Developer Guidelines

Status and Error Codes

Following list describes common types of client statuses on API calls that receive request bodies: All CDQ Cloud Platform services provide a response object comprising an HTTP status code and optionally a response entity (e.g. a business partner). The response entities are described by the particular web method documentation. The following listing defines the meaning of HTTP status codes in the context of CDQ Cloud Platform services:

Status 200XXXXX

Status 201XXXXX

Status 400XXXXX

Status 429XXXXX

Status 500XXXXX

Storing data

Features and Profiles

Endpoints provide features in order to enable configurability to optimize performance. Features are very specific to the endpoint, however, following generic features can be distinguished.

For convenience, most common configurations of the features are provided in terms of profiles which also can be selected in the endpoint. If no profile or feature is selected explicitly, a default profile will always be applied. In most cases, consumers do not need to configure features or profiles - they may use the endpoints as-is.»

Pagination

Responses that return multiple items will be paginated to 50 items by default. You can specify further pages control with the following query parameter:

Paging over whole resource

The whole resource can be retrieved using endpoint supporting pagination. Reading loop should include page read endpoint call with startAfter property, filled with the content of nextStartAfter from the previous page read result. When nextStartAfter property is empty, then reading loop should finish processing.

Example

var startAfter = null
do
    var page = resource.readPage(limit, startAfter)
    process(page)
    startAfter = page.nextStartAfter
while (null != startAfter)

Quotas

For every customer we apply the following quotas:

• Maximum of 50 jobs per day per workspace.

Firewall ports

For secure communication, the following ports are required for the CDQ Cloud Platform:

Rate Limiting

Rate limiting is per API Key. Default is 20 requests per second maximum.

Request Size Limiting

Payload size

For most CDQ's endpoints, the maximum acceptable payload size of the request is set to 10 MB.

Exceptions from this limit are gathered in below table:

Upload file size

The same Request Size Limit applies to uploading the file.

• For uploading files <= 10 MB read File Upload instruction.
• For uploading files > 10 MB read Request Upload instruction.

Schema

Blank fields are omitted and not includes as null in order to optimize payload sizes. All timestamps are returned to ISO 8601 format

TLS Certificates

When connecting to our API, it may be necessary for some particular clients to explicitly download and import the TLS certificate chain (Root, Intermediate, Server). Please download the certificate chain here:

Currently active

Please note that the certificates are renewed every year and need to be updated in your certificate management system (if available).

Certificate Details

The certificates were rated A at the time of issue, according to SSL Labs.

The details of the certificates are as follows:

RSA Certificates

For customers who do not support elliptic curve algorithm in their systems, we provide RSA certificates below.

History

Versioning

Understanding version numbers

Each API or App release is uniquely identified by a version number. The structure of the version follows the standards of Semantic Versioning 2.0.

Format and example:

<MAJOR>.<MINOR>.0+<BUILD TAG>
25     .45     .0+202007747438

• Major: Incremented when incompatible API changes are releases
• Minor: Incremented when functionality or fixes are released in a backwards compatible manner
• Build: Timestamp of the build

Each API or App has its own release cycle and thus its own dedicated version. Release notes are published here.

Incompatible API changes

Incompatible API changes include ("breaking changes"):

• End-of-life of an endpoint
• Removal of a property in the request/response model
• Removal of an enum value in the request/response model

Versioning and release strategy

In order to support and operate multiple API versions in parallel, we apply the following versioning strategy:

https://api.cdq.com/reference-data/rest/businesspartners/lookup
https://api.cdq.com/reference-data/rest/businesspartners/v2/lookup

Tags

The following tags are used in the API documentation for quick reference to versions.

• V1, V2, .. ,VX: Refers to the major version of an API
• latest: Refers to the latest version of an API

Version selector by tags

End-of-life

Implementation

Schema

The following guidelines support developers to build rocket-solid client implementations.

S1: Safe consumption of API responses Be aware that in the API response blank fields are omitted and not included as null. Your client implementation needs to check if values are present in the payload before using them - otherwise your application may generate null pointer exceptions or similar.

{
  "internationalBankIdentifier" : "DE34XXXXXXXXXXXXXXXXX"
  "lastPaymentDate" : "2021-18-45"
  "country" : "DE"
  ..
}

{
  "internationalBankIdentifier" : "DE34XXXXXXXXXXXXXXXXX"
  // ATTENTION: field "lastPaymentDate" is null so it will not be part of the response
  "country" : "DE"
  ..
}

Specifications

CDQ APIs are available via REST or SOAP 1.2. The below table provides links to download CDQ APIs specification in JSON, YAML, WSDL or WADL format.

Your opinion matters!

We are constantly working on providing an outstanding user experience with our products. Please share your opinion about this tutorial!

Mail our developer-portal team: developer-portal@cdq.com