API

The API brings tenders from procuris into your own system, without retyping. An API is an interface through which two programs exchange data. It delivers the same data that procuris itself uses: notices from TED (the EU's official journal for tenders), bund.de and more than 90 procurement portals.

A tender should be one record in your system, not several. If a notice appears on several portals, procuris merges it into one record. If procuris detects a duplicate only later, it archives the newer record and points to the one that remains. How your system handles this is described in the data model.

The data gets a new state at most once per hour. A request returns the latest state at procuris, not the state the contracting authority publishes at that moment.

What you get

A record describes one tender with the details of its notice. It contains title, description, tender number, contracting authority with contact, submission deadline and participation deadline, contract value, CPV codes for the sector, region, procedure type, lots, status and original source. If the contracting authority has not published a contract value, procuris delivers an estimate where one exists and marks it as an estimate. If there is neither a published nor an estimated value, the field holds null, meaning no value. The data model lists the fields with type and example.

The API does not deliver four things from procuris:

• the Fit, meaning how well a tender matches your company, from 0 to 100
• your saved searches, meaning stored searches that keep running every morning and email new tenders
• their hits, meaning the tenders a saved search has found
• the tender documents, meaning the documents the contracting authority provides for your bid

Your system gets hits with Fit through webhooks with the event search.hit. The API cannot deliver them later, because it knows neither Fit nor saved searches.

What companies use the API for

• Sales: Construction tenders from your region land as opportunities in your CRM (the software for customers and sales opportunities). If all tenders matching your filters should go into the CRM, you need the API and webhooks: the API for the initial load (the one-time transfer of the data) and the nightly sync, webhooks for changes in between. If only the hits of your saved searches should go into the CRM, webhooks without the API are enough. Both variants are described in CRM and ERP.
• Planning: Submission deadlines and contract values are in your ERP (the software for orders and planning) or your BI tool (the software for analysis) after the nightly sync, instead of being transferred by hand.
• Market monitoring: Compare tenders in one sector over several years, because the archive goes back to January 2022.

What your IT provides

Your IT needs three things, but no access from outside. Unlike with webhooks, your system fetches the data instead of receiving it. Your network therefore does not have to accept requests from outside.

• a service that runs hourly or nightly and is allowed to make outgoing HTTPS requests
• a secret store (a protected place for credentials) for the token
• a list of which procuris field goes into which field of your system. Your system creates records by the fixed id of a tender and updates them by the same id.

Most of the work is the field list, not the sync. Your IT decides for each field where it belongs in your system and what it is called there. The sync itself consists of six steps, described under Filters and timing.

Your first request

Once access is set up, four steps are enough for the first request.

GET /v1/tenders?cpv=45000000&nuts=DEG&updated_since=2026-09-24T00:00:00Z&limit=5 HTTP/1.1
Host: api.procuris.eu
Authorization: Bearer <your token>
Accept: application/json

At a glance