Other parameters

Tuum offers optional header parameters that can be included to guarantee request deduplication or control localisation.

Ensuring deduplication (idempotency) with x-request-id

The x-request-id parameter allows you to safely retry POST requests without fear of creating duplicate resources. Simply assign it a value in a universally unique identifier (UUID, RFC 4122) format.

For example: "x-request-id": "63354623-d264-443a-9d47-09e7b356ef11"

How it works

• No value: If the x-request-id is missing, null, or empty, the system skips duplication checks and processes each POST as a separate request.

• Duplicate ID: If multiple POST requests reuse the same x-request-id—regardless of the payload—Tuum consistently responds with the same HTTP status and payload it returned for the first successful request with that ID.

• Unique ID: If you send multiple POST requests using different x-request-id values, Tuum processes each request independently and provides a distinct response for every request.

Duplication controls are not enabled on all POST endpoints. To check the status of a specific POST endpoint, please contact the Tuum team for clarification.

The table below summarises the use cases for using a UUID as the x-request-id header parameter value.

POST call / Request ID	Same request ID	No or unique request ID
Initial POST call	Unique response	Unique response
Duplicated POST call	Same as in the initial response	Unique response
Duplicated POST with updated data	Same as in the initial response	Unique response

Usage recommendations

When setting the x-request-id header, always generate a unique UUID for each request, regardless of which Tuum API you are accessing. Avoid reusing the same UUID for multiple requests.

Sample API calls

To view the sample API calls of using different x-request-id values, refer to the following examples in the API Cookbook:

• request with the same x-request-id

• request without x-request-id

Controlling localisation with Accept-Language

Using the Accept-Language optional header parameter, you can define the translation of the explanatory text in error messages. For the parameter value, use a two-character language code in lowercase (ISO 639-1).

Example for Finnish: "Accept-Language": "fi"

If a translation is not available in the requested language, the text will default to English as a fallback.