Legal, Compliance & GovTech
Public Tender Matching API
Public contracts are published, searchable and still missed constantly — because the notice that matters is one of four hundred published that week.
- Bid management software
- Public sector suppliers
- Trade associations
- Consultancies
- Procurement marketplaces
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Public procurement is deliberately transparent and practically impenetrable. Notices appear across national portals, an EU-level journal, regional sites and individual authority pages, each with its own classification scheme and its own idea of a sector. A mid-sized supplier capable of winning the work simply does not have anyone whose job is reading four hundred notices a week to find the eight that are relevant.
What gets missed is not usually the obvious large framework. It is the smaller contract from an authority the supplier has never sold to, in an adjacent category, with a six-week deadline that has already consumed two weeks by the time anyone notices. Bid teams also waste substantial effort in the other direction, working up responses for tenders the organisation was never eligible for — turnover thresholds, required certifications, framework membership, consortium rules.
Both problems are matching problems, and both are tractable. Classification codes give a coarse first pass, but they are applied inconsistently and the useful signal is in the specification text. Eligibility is largely structured and checkable — financial thresholds, accreditations, past-performance requirements — which means a notice can often be ruled out before anybody reads it.
Who buys this
Bid management software, Public sector suppliers, Trade associations, Consultancies, Procurement marketplaces
What the API returns
What comes back
- Matched tender notices ranked against a supplier profile, with the reason for each match
- Eligibility assessment per notice against stated qualification requirements
- Explicit disqualifiers, so a no-bid decision can be made in minutes rather than days
- Deadline timeline including clarification windows and submission cut-offs
- Contract value, duration, lot structure and extension options where published
- Buyer history including past awards and incumbent supplier where records allow
- Framework and dynamic purchasing system membership requirements
- Coverage register stating which portals are monitored and at what cadence
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/profiles | Define or update a supplier capability and eligibility profile |
| GET | /v1/tenders/matches | Ranked matched notices for a profile with match reasons |
| GET | /v1/tenders/{id} | Full notice detail including lots and documents |
| POST | /v1/tenders/{id}/eligibility | Eligibility assessment against a profile |
| GET | /v1/buyers/{id}/history | A buyer's award history and incumbents |
| WS | /v1/stream | Push new matched notices and deadline changes |
Request and response
illustrativeRequest
{
"profile_id": "sup_2214",
"capabilities": ["facilities_management", "mechanical_maintenance"],
"regions": ["GB-NW", "GB-YH"],
"constraints": { "max_contract_value": 12000000,
"annual_turnover": 8400000,
"certifications": ["ISO14001", "SafeContractor"] },
"min_days_to_deadline": 14
}Response
{
"profile_id": "sup_2214",
"generated_at": "2026-10-21T05:00:00Z",
"matches": [
{
"notice_id": "ocds-9f1k-882104",
"buyer": "Greater Manchester NHS Trust",
"title": "Planned mechanical maintenance — acute estate",
"value": { "amount": 4200000, "currency": "GBP", "duration_months": 48 },
"match_score": 88,
"match_reasons": [
{ "reason": "capability_match", "detail": "mechanical_maintenance, CPV 50710000" },
{ "reason": "region_match", "detail": "GB-NW" },
{ "reason": "value_within_capacity", "detail": "4.2m vs 12m ceiling" }
],
"eligibility": { "status": "eligible", "checks_passed": 6,
"unmet": [] },
"deadlines": { "clarifications_close": "2026-11-07",
"submission": "2026-11-21", "days_remaining": 31 },
"incumbent": { "supplier": "Arden Facilities Ltd", "since": "2022-10" }
},
{
"notice_id": "ocds-9f1k-882337",
"match_score": 71,
"eligibility": { "status": "ineligible",
"unmet": [ { "requirement": "min_annual_turnover_15m",
"profile_value": 8400000 } ] },
"note": "Ruled out on turnover threshold; no bid effort required."
}
],
"coverage_note": "2 regional portals publish HTML only; polled twice daily."
}Where the data comes from
| National procurement portals | Primary publication for most public contracts, increasingly available as structured open data |
| Supranational journals and registers | EU-level and equivalent publication, which is authoritative for higher-value contracts |
| Open Contracting Data Standard feeds | Where a jurisdiction publishes to OCDS, which makes structured matching dramatically more reliable |
| Individual authority sites | Many smaller contracts never leave the buyer's own page, and these are collected only where terms permit |
| Award notices and contract registers | Past awards, incumbents and realised values, which is how buyer history becomes useful |
| Your supplier profile | Capabilities, turnover, certifications and framework memberships — the other half of the match, and the part only you hold |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Matching on specification text as well as classification codes, because CPV and equivalent codes are applied inconsistently and alone produce both misses and noise
- Eligibility checking as structured rule evaluation against stated requirements, with every unmet requirement named rather than folded into a score
- Explanation on every match, since a bid manager will not act on a ranked list they cannot interrogate
- Document bundle parsing for the specification and qualification documents, which is where the real requirements usually live rather than in the notice
- Deduplication across portals, as the same notice commonly appears on national, supranational and authority sites with different identifiers
- Deadline extraction with timezone and working-day handling, and change detection on deadlines, which move more often than suppliers expect
- Precision and recall measured against bid teams' own relevance judgements, reported per capability area rather than as one accuracy number
- Coverage monitoring per portal with alerting on publication gaps, since a silent portal looks identical to a quiet week
What it changes for the business
Fewer missed notices
Daily matched alerts across portals catch the adjacent-category contracts a manual search never reaches.
Less wasted bid effort
Named disqualifiers let a team no-bid in minutes instead of discovering a turnover threshold on day four.
Better qualified pipeline
Match reasons and buyer history give bid/no-bid decisions something concrete to weigh.
Earlier starts
Catching a notice in week one of six changes what a response can realistically contain.
How it fits into your product
How it embeds
- Daily matched digest plus WebSocket push for new notices against a saved profile
- Webhooks into bid management tooling so a match becomes a qualification task with the deadline attached
- Profile endpoints your users maintain themselves, versioned so a change in matching is explainable
- Deep links to the notice and document bundle on the source portal
- Multi-profile support for consultancies and associations running matching on behalf of many suppliers
- Per-tenant scoping so profiles and pipelines are isolated between your customers
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you cover every tender published?
No. Supranational journals and national portals are reliable and increasingly structured. The long tail of individual authority websites is not, and some publish in formats or under terms that make collection impractical or impermissible. The coverage endpoint states which portals are monitored, by what method and at what cadence, so a quiet result can be distinguished from a blind spot.
Is an eligibility assessment definitive?
It is a strong first filter, not a legal determination. Structured requirements — turnover thresholds, required certifications, framework membership — check reliably. Qualitative requirements such as comparable past performance or a technical capability narrative need human judgement, and the API marks those as requiring assessment rather than passing or failing them silently.
Will it tell us whether we can win?
No. It tells you whether you are eligible, whether the work matches your capabilities, who holds the contract now and what the buyer has awarded before. Win probability depends on your price, your response quality and competitors you cannot see, none of which is in the notice. We would not attach a win-likelihood number to this.
How fast are notices picked up?
Within minutes for structured feeds and OCDS publishers; twice daily for portals that only publish HTML. Deadlines are also tracked for change, because an extension or a correction notice that nobody saw is a common way a bid fails before it starts.
Can we match on behalf of many suppliers?
Yes, and that is the normal pattern for consultancies and trade associations. Profiles are tenant-scoped and isolated, which matters when two of your clients bid for the same contract — neither should be able to see the other's pipeline, and the architecture should make that impossible rather than discouraged.
Related blueprints
Permit and Licence Intelligence API
Permit and licence requirements, application status and renewal alerting across jurisdictions, as an API for operations and compliance software.
Regulatory Change Monitoring API
Monitoring of regulatory and legislative change, mapped to the functions it affects, delivered as an alert feed inside compliance software.
Contract Intelligence API
Clause extraction, obligation tracking and renewal alerting across a contract portfolio, as an API your legal or procurement software embeds.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.