Overview
Here’s a quick overview to give our users some context before getting started with the API.
1 Connecting to the API
In order to connect to the API, you need to add the API key to the header.
The header should look like this:
Header: {
"api_key": "xxx"
}
1.2 Acceptance Environment
Within ETPA there are two different environments that can be used. One of them is the acceptance (ACC) environment.
The Acceptance environment is a pre-production environment designed to closely mirror Production in terms of configuration, data structure, and integrations. Its primary purpose is to validate that the system meets business requirements and that end-to-end processes work correctly before going live.
Think of it as the final testing ground before real customers or production data are involved.
The acceptance environment for the platform is available at https://acc-platform.etpa.nl. You can use this environment to test the platform’s functionality.
The acceptance environment is where every participant and/or broker can get familiar with the application, API, and SSE. We highly recommend using the API and/or SSE of acceptance first before connecting your software to the production (PROD) environment.
Multiple versions of the API are available, indicated in the URL.
1.3 Production Environment
Once your software works correctly with the ACC environment, you can switch to the production (PROD) environment by changing the endpoint URL. It is recommended to declare the URL in one place in your code for easy switching.
PROD endpoints:
-
API:
https://trading.etpa.nl/public-api/{version}/electricity/{API} -
SSE: (Server Sent Events )
https://trading.etpa.nl/{CHANNEL}
⚠️ Make sure you use the correct API key of a PROD account with the correct user role/rights. The API key of ACC will not work in PROD.
2 Pagination
Our API uses different types of pagination to limit the data you can retrieve.
2.1 API Pagination 1.0
The Order, Reporting, Wallet, and Trading APIs make use of pagination.
This means that the amount of returned data is limited to prevent timeouts (since these APIs can return a lot of data).
- You can set the maximum number of returned items with the parameter:
- The data is sorted by time, meaning the latest entry is always first in the list.
- To retrieve additional data, use the parameter:
cursorwith thenextCursorvalue. This will return the next set of results.
2.2 API Pagination 2.0
In the new APIs, a more advanced pagination is used.
This pagination offers more options and allows users to customize input.
For some APIs this pagination is mandatory.
2.2.1 Request
When making a GET request with Pagination 2.0, include the following parameters:
page=0&size=10
page => current page. The first page is always the first page.
size => the amount of data you want to retrieve in your response. The minimum value
is 1 and the maximum value is 100.
2.2.2 Response
When the request is executed, the response will include pagination details.
It will look something like this:
{
"content": [
// list of results
],
"pageable": {
"sort": {
"empty": true,
"unsorted": true,
"sorted": false
},
"offset": 0,
"pageNumber": 0,
"pageSize": 10,
"paged": true,
"unpaged": false
},
"last": true,
"totalPages": 0,
"totalElements": 0,
"size": 10,
"number": 0,
"sort": {
"empty": true,
"unsorted": true,
"sorted": false
},
"first": true,
"numberOfElements": 0,
"empty": true
}
3 Rate Limiting
Our API enforces a rate limit to ensure fair usage and maintain performance. Each client is allowed a maximum of 30 requests at a time.
3.1 How It Works
- You start with 30 available requests.
- Every 2 seconds, 1 additional request is added to your quota, up to the maximum of 30 requests.
- For example:
- If you make 1 request, you will have 29 requests remaining.
- After 2 seconds, your quota will increase by 1, bringing you back to 30 requests.
- Note: Your total number of requests cannot exceed 30.
3.2 Exceeding the Limit
If you exceed the allowed number of requests, the API will return a 429 Too Many Requests error:
{
"status": 429,
"error": "Too Many Requests",
"message": "You have exhausted your API Request Quota"
}
4 Sent Server Events (SSE) Stream Update Behavior
For orderbook and trade streams, only updates to the current state are transmitted; past events are not replayed.
Trades (intraday/expost): The initial message contains the current day's trades up to that point. Subsequent messages include only new trades as they occur.
Orderbook (intraday/expost): The initial message provides the current state of the orderbook. Subsequent messages contain incremental updates reflecting changes to the orderbook.