Home/Offers/Legal, Compliance & GovTech/Permit and Licence Intelligence API

Legal, Compliance & GovTech

Permit and Licence Intelligence API

Nobody plans to operate without a licence. They plan to renew it, and then the person who knew about it leaves.

Construction and field service software
Multi-site operators
Compliance platforms
Fleet and logistics operators
Franchise and hospitality groups

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

An organisation operating across several jurisdictions accumulates permissions the way it accumulates contracts. Trade licences, environmental permits, food registrations, waste carrier authorisations, vehicle operator licences, planning consents with conditions attached, professional registrations held by individual staff. Each has an issuing body, a renewal cycle, a condition set and someone who is informally responsible for remembering it.

Failures are rarely dramatic. A permit lapses because a renewal notice went to a former employee's inbox. A site opens before a registration completes because nobody knew the lead time was eleven weeks. A condition attached to a consent three years ago — monitoring, reporting, a restriction on operating hours — is breached by an operational change nobody connected to it. The cost arrives as an enforcement notice, a stopped site or an invalidated insurance position.

What makes this tractable is that most of it is knowable in advance. Requirements are published, lead times are broadly observable, renewal cycles are fixed, and conditions are written down in the consent document. The work is assembling the requirement rules per jurisdiction and activity, keeping them current as rules change, and turning a renewal date into something that actually reaches a named person with enough notice to act.

Who buys this

Construction and field service software, Multi-site operators, Compliance platforms, Fleet and logistics operators, Franchise and hospitality groups

Category: Legal, Compliance & GovTech

What the API returns

What comes back

Applicable permit and licence requirements for an activity, location and entity type
Issuing authority, statutory basis and application route per requirement
Expected lead times and typical determination periods where observable
Status tracking for submitted applications, including information requests
Condition register extracted from issued consents, with monitoring and reporting duties
Renewal calendar with escalating alerts and named ownership
Change notifications where a requirement or fee is altered by the authority
Coverage register stating which jurisdictions and permit types are modelled

Endpoints

Method	Path	Returns
POST	/v1/requirements/assess	Applicable requirements for an activity, site and entity
GET	/v1/requirements/{id}	Requirement detail, authority, route and lead time
GET	/v1/holdings/{entity_id}	Permits and licences held, with status and expiry
GET	/v1/holdings/{id}/conditions	Conditions attached to an issued consent
GET	/v1/calendar/renewals	Renewal and reporting deadlines with owners
WS	/v1/stream	Push status changes, requirement changes and deadline alerts

Request and response

illustrative

Request

{
  "entity_id": "ent_4412",
  "activity": "food_preparation_and_delivery",
  "sites": [
    { "site_id": "st_881", "address_country": "GB", "address_region": "GB-MAN" },
    { "site_id": "st_904", "address_country": "IE", "address_region": "IE-D" }
  ],
  "operations": { "waste_handling": true, "vehicles_over_3_5t": 2,
                  "late_hours": true },
  "include": ["lead_times", "conditions"]
}

Response

{
  "entity_id": "ent_4412",
  "assessed_at": "2026-10-21T09:00:00Z",
  "requirements": [
    { "requirement_id": "req_gb_food_reg",
      "site_id": "st_881",
      "name": "Food business registration",
      "authority": "Local authority environmental health",
      "basis": "statutory registration",
      "lead_time_days": { "p50": 28, "p90": 45 },
      "status": "held", "expires": null,
      "note": "No expiry; change of premises or operator requires re-registration." },
    { "requirement_id": "req_gb_waste_carrier",
      "site_id": "st_881",
      "name": "Waste carrier registration (upper tier)",
      "lead_time_days": { "p50": 14, "p90": 30 },
      "status": "expiring", "expires": "2026-12-04",
      "owner": "ops.manchester@example.com",
      "alerts": ["90d sent", "60d scheduled"] },
    { "requirement_id": "req_gb_late_hours",
      "site_id": "st_881",
      "name": "Late night refreshment licence",
      "status": "not_held",
      "blocking": true,
      "lead_time_days": { "p50": 56, "p90": 98 },
      "note": "Consultation period applies; representations may extend determination." }
  ],
  "conditions_due": [
    { "holding_id": "hold_1182", "condition": "quarterly noise monitoring report",
      "next_due": "2026-12-31", "source": { "document": "consent_2023_114",
      "clause": "7(b)" } }
  ],
  "coverage_note": "IE site: requirement set modelled at national level only; local authority variations not covered.",
  "advice_note": "Requirement assessment is operational guidance, not legal advice."
}

Where the data comes from

Authority guidance and statutory instruments	Published requirements, fees and application routes, which is the authoritative basis for every requirement rule
Public permit and licence registers	Many authorities publish holdings and applications, which supports status tracking and competitor or supplier checks
Application portals and status services	Where an authority exposes application status programmatically; many do not, and those fall back to manual update
Issued consent documents	The conditions only exist in the document, so the client's own consents are an essential source
Observed determination times	Published statistics or register-derived timings, which is how a realistic lead time is estimated rather than quoted from guidance
Your site, activity and entity records	The input that makes a requirement set specific rather than a generic checklist

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

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.

Requirement modelling as explicit, versioned rules per jurisdiction, activity and entity type, so an assessment can be reproduced and explained months later
Rule change tracking tied to regulatory monitoring, because a requirement set that silently goes stale is worse than no requirement set
Lead time estimation from observed determination data where available, reported as a distribution rather than the authority's optimistic guidance figure
Condition extraction from issued consent documents with clause-level citations, since conditions are the most commonly breached and least tracked obligation
Ownership and escalation modelling on every deadline — a renewal alert with no named owner is how the original failure happened
Status reconciliation between portal data, authority correspondence and the client's own records, with conflicts surfaced rather than resolved by precedence
Blocking-requirement identification so a site opening date reflects the longest lead time rather than the average one
Coverage register published as data, including where only national-level rules are modelled and local variation is not

What it changes for the business

Fewer lapses

Owned, escalating renewal alerts remove the single most common cause of operating without a valid permission.

Realistic opening dates

Lead-time distributions and blocking requirements let a site launch plan reflect determination periods.

Conditions actually tracked

Extracted condition registers turn buried consent clauses into scheduled, assigned tasks.

Multi-site visibility

A single holdings view across jurisdictions replaces the spreadsheet that one person maintains.

How it fits into your product

How it embeds

REST assessment calls from site onboarding and expansion workflows
Webhooks and WebSocket alerts into the operational tools that site managers actually use
Calendar integration with named ownership and escalation, so a deadline reaches a person rather than a dashboard
Document ingestion for issued consents, returning a condition register with citations
Holdings import so an existing estate can be brought under tracking without manual re-entry
Deployment inside your infrastructure where site and entity data cannot leave

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 weeks

Discovery 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

Is this legal advice on what we need?

No. It is a structured, versioned view of published requirements for an activity and location, with citations to the authority guidance behind each rule. Borderline cases — whether an activity falls within a definition, whether an exemption applies, how a condition should be interpreted — need a qualified adviser, and the API flags where a rule has known interpretive ambiguity rather than resolving it silently.

How complete is jurisdictional coverage?

Deliberately narrow and honest. We model the jurisdictions and permit types you actually operate in, and the coverage register states exactly what is modelled, including where only national-level rules are covered and local authority variation is not. A generic global permit database is a thing nobody can maintain accurately, and we would rather cover forty jurisdictions properly than claim two hundred.

Can you submit applications for us?

Mostly no. Few authorities offer programmatic submission, and many require signed declarations or identity verification that a third-party system cannot provide. We track requirements, lead times, status and renewals, and we pre-fill what the portal allows. The submission itself usually stays manual, and we would rather say that than imply end-to-end automation.

How accurate are the lead times?

They are estimates from observed determination data where it exists, presented as a distribution with a median and a ninetieth percentile. Where only authority guidance exists we label it as such, because published target times and actual times often differ substantially. Applications attracting objections or consultation can exceed both, and the API notes which requirement types are prone to that.

What if an authority changes a requirement?

Rule changes come through the same monitoring used for regulatory change, and affected assessments are re-evaluated and flagged. We cannot promise instant detection — some authorities update guidance pages with no notice at all — which is why the coverage register records the monitoring method and last-checked date per rule set.

All Legal, Compliance & GovTech offers →

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.

Discuss This Build Browse All Offers