Show DEV: DeltaRail — A REST API for EU Public Contract Modifications

DeltaRail | EU Procurement API — Sun, 11 Oct 2026 14:49:37 +0000

Why I started DeltaRail

European public procurement generates large amounts of publicly available information through Tenders Electronic Daily (TED).

New tenders receive considerable attention, but I wanted to explore another part of the procurement lifecycle: contract modifications after an award.

This led me to publish DeltaRail, a REST API that provides structured information derived from TED contract modification notices.

A simple API experiment

The currently documented endpoint is:

GET /v1/events/premium

It accepts an optional parameter:

limit

During testing, I tried three values:

Limit	Events returned	HTTP status
1	1	200 OK
10	10	200 OK
100	100	200 OK

These tests revealed an important distinction.

One API request is not necessarily one data record.

A developer can retrieve multiple events in a single request.

This matters when designing subscription plans, estimating consumption and deciding how much data to retrieve.

Example request

Here is a cURL example:

curl --request GET \
  --url 'https://deltarail.p.rapidapi.com/v1/events/premium?limit=10' \
  --header 'X-RapidAPI-Key: YOUR_API_KEY' \
  --header 'X-RapidAPI-Host: deltarail.p.rapidapi.com'

The response is structured JSON containing procurement modification events.

The API can be explored here:

https://rapidapi.com/Osteoarchanco/api/deltarail

Potential applications

Structured procurement information may be useful for:

Investigative journalism.
Public spending research.
Procurement monitoring.
Economic and market analysis.
Applications using AI to analyse public data.

An important limitation: DeltaRail does not currently document advanced search filters in this endpoint. Applications requiring additional filtering must implement it separately.

The available dataset should not be assumed to cover every TED notice. Critical findings should always be verified against the official source.

A question for developers

When building data APIs, what do you find more useful?

Higher request quotas, more records per request, or advanced filtering capabilities?

I would be interested in learning how other developers approach this trade-off.