Request headers
Information about simulating API requests
This page describes the optional headers which can be passed as part of the request.
Simulation
On the synchronous endpoints only it is possible to send a request in simulation mode. This means that the request is validated, enriched and transformed in an internal backend request, but not executed or persisted. This is particular convenient when using definitions, to be able to troubleshoort how inputs are transformed into the actual request.
In case of a simulated request following header need to be included:
key | value |
x-request-simulate | true |
Request Type
On asynchronous and synchronous endpoints it is possible to provide a request type. This provides more context about the request itself. The request type is only for information purposes at the moment. And will be stored as a key/value together with the applicable transaction in the request tracker (API monitoring dashboard), in case the endpoint is tracked (default enabled for async endpoints and disabled for sync endpoints).
To be able to filter on Request Type in the API monitoring dashboard, you need to add these request types as a tenant code with code type requestType.
This can be very convenient if there are multiple different requests flowing through the same API and you want to inspect or filter certain requests only.
For example:
- AccessPoint patch requests on PVNED
- MasterDataUpdate →
edsncar_mastdata_MASTERDATA_UPDATE - Allocation Data →
tnntmmc_allocsrs_ALLOCATION_SERIES_NOTIFICATION_N101 - Measurement Data →
tnntmmc_msrmntsr_MEASUREMENT_SERIES_NOTIFICATION_N10
To provide the request type along following header need to be included:
key | value |
x-request-type | <string> |
Correlation ID
On asynchronous endpoints only it is possible to provide your own correlation id. In case it is provided, the backend will take this correlation id instead of generating an own correlation id. This correlation id will be stored in all logging and together with the applicable transaction in the request tracker (API monitoring dashboard), in case the endpoint is tracked (default enabled for async endpoints).
This can come in handy when you want to subscribe to updates related to this correlation id (see also here Asynchronous API).
The correlation id need to be unique in the environment (across different tenants if there are more than 1). Otherwise this will mess up the tracking of the request.
To provide the correlation id following header need to be included:
key | value |
x-correlation-id | <UUID> |