Education & Workforce
Salary Benchmarking API
Every compensation decision is a benchmarking decision. The question a buyer will actually ask you is where the number came from.
- HR and payroll vendors
- Compensation consultancies
- Recruitment platforms
- Job boards
- Works councils and unions
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
Pay benchmarking is an old market with a structural problem. The traditional survey model collects submissions from participating employers, which produces clean, comparable data about a self-selected group — usually larger firms in a few sectors, reported on a cycle measured in quarters. Posting-derived data is fresher and far broader but reflects advertised pay rather than paid pay, and only for the subset of employers who disclose.
Neither source is wrong. Presenting either one as the market rate without saying which it is, how many observations sit behind it and what it actually measures is where benchmarking products lose credibility. A compensation manager who has done this before will ask about provenance in the first ten minutes.
Pay transparency obligations are reshaping the whole area. Advertised salary ranges are now mandatory in a growing list of jurisdictions, gender pay gap reporting is widening in scope, and the EU pay transparency directive brings employee rights to pay information and joint pay assessments where unexplained gaps exceed a threshold. That turns benchmarking from an internal planning tool into something that has to stand up when an employee asks why their range is what it is.
Who buys this
HR and payroll vendors, Compensation consultancies, Recruitment platforms, Job boards, Works councils and unions
What the API returns
What comes back
- Pay ranges by role, level and labour market, with percentiles and sample size
- Source attribution on every range — survey, disclosed posting, client submission or blended, never silently mixed
- Total compensation breakdown separating base, variable, equity and allowances where available
- Pay movement series showing how a range has shifted over time
- Geographic differentials between markets, with the comparison basis stated
- Internal-versus-market positioning when you supply your own pay data
- Compression and inversion indicators across your own levels
- Confidence and coverage flags, including explicit suppression where the cell is too thin
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/benchmarks/{role} | Pay range for a role, level and market |
| POST | /v1/benchmarks/batch | Benchmark a whole job architecture in one call |
| POST | /v1/positioning | Compare your own pay data against market ranges |
| GET | /v1/benchmarks/{role}/movement | How the range has moved over time |
| GET | /v1/differentials | Geographic differentials between two markets |
| GET | /v1/provenance/{benchmark_id} | Full source and methodology record for one figure |
Request and response
illustrativeRequest
{
"role": "data-engineer",
"level": "senior",
"market": "GB-LND",
"basis": "annual_base_fte",
"sources": ["survey", "disclosed_postings"],
"min_sample": 40
}Response
{
"benchmark_id": "bm_8831f",
"role": { "normalised": "data-engineer", "level": "senior" },
"market": "GB-LND",
"currency": "GBP",
"basis": "annual_base_fte",
"as_of": "2026-10-01",
"range": { "p10": 72000, "p25": 81000, "p50": 94000, "p75": 108000, "p90": 121000 },
"sample": { "total": 614, "employers": 188 },
"provenance": [
{ "source": "survey", "weight": 0.62, "observations": 381,
"collected": "2026-Q2", "measures": "paid_base_salary" },
{ "source": "disclosed_postings", "weight": 0.38, "observations": 233,
"collected": "last_90_days", "measures": "advertised_range_midpoint" }
],
"total_comp": { "variable_median_pct": 10.0, "equity_prevalence": 0.34 },
"movement": { "p50_change_12m_pct": 3.8 },
"transparency_note": "Advertised ranges and paid salaries are reported separately; they are not the same measure.",
"suppressed_cells": ["GB-LND / principal / equity_value"]
}Where the data comes from
| Licensed compensation surveys | Employer-submitted pay data, which is the only source that measures salaries actually paid — licensing terms usually restrict how granularly you may redisplay it |
| Disclosed salary in job postings | Broad and current, but advertised rather than paid, and only from employers who disclose; collected only from sources whose terms permit it |
| Official earnings statistics | National agency earnings distributions, which anchor the commercial sources to a representative population |
| Your customers' own payroll data | With agreement, contributed into a pooled benchmark — the most accurate input available and the one with the strictest handling rules |
| Collective agreements and public pay scales | Published scales in sectors where pay is set collectively, which make parts of the market exactly knowable |
| Cost and currency reference data | For cross-market comparison, with the basis of the adjustment made explicit rather than buried |
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.
- Separate estimation per source type, blended only with declared weights, so a buyer can always see how much of a figure is survey data and how much is advertised pay
- Job levelling onto a consistent architecture before any comparison, because the same title spans three levels across employers
- Disclosure-bias correction on posting-derived figures, calibrated against survey and official earnings distributions
- Minimum cell sizes on both observations and distinct employers, with suppression rather than publication when either threshold fails — this also prevents a single employer's pay being recoverable
- Ageing of survey data with an explicit decay, so a figure collected two quarters ago is not presented as current
- Differential privacy style noise and k-anonymity thresholds on any pooled payroll contribution, so no participant's pay can be reverse-engineered from the benchmark
- Equity and variable pay handled as separate fields rather than folded into one total, since prevalence varies far more than base pay does
- Back-testing of benchmark movement against subsequent realised pay changes, with accuracy reported per market
What it changes for the business
Credible ranges
Provenance on every figure means a compensation decision can be explained to the person affected by it.
Transparency readiness
Separate advertised and paid measures, plus auditable methodology, are what pay transparency obligations actually require.
Faster offer decisions
Recruiters get a defensible range at the point of offer instead of waiting for a consultancy cut.
Equity review
Positioning and compression analysis surface unexplained internal gaps before an employee or a regulator does.
How it fits into your product
How it embeds
- REST lookups at offer and review time, with batch endpoints for a full job architecture
- Positioning endpoint that takes your own pay data and returns market placement without storing it where you do not want it stored
- Deployment inside your infrastructure, which is the normal arrangement where payroll data is involved
- Provenance endpoint your product can link to directly, so an end user can see the methodology behind a number
- Embeddable range and positioning components for compensation review screens
- Per-tenant scoping and contribution controls where you operate a pooled benchmark across 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 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
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
Where does the data actually come from?
Licensed surveys, disclosed salaries in permitted job postings, official earnings statistics, published pay scales and — where clients agree — pooled payroll contributions. The API reports the weight and the measure of each component on every figure. We keep advertised pay and paid pay as separate measures, because blending them into one number quietly misstates what you are looking at.
Can we resell the benchmarks to our customers?
Partly, and the limits come from the survey licences rather than from us. Most permit derived ranges at a stated granularity and forbid redisplaying the underlying submissions or cutting the data below a minimum cell size. We establish exactly what you may pass on during discovery, in writing, because discovering it afterwards is expensive.
What happens in thin markets?
The cell is suppressed and the response says so. A median built from nine observations across three employers is not a benchmark, and publishing it would also risk exposing an individual employer's pay. Where you need a figure anyway, the honest options are to widen the geography, broaden the level band, or accept a range with explicit uncertainty.
Will this tell us what to pay someone?
No. It tells you what the market distribution looks like, from stated sources, with sample sizes. The decision involves internal equity, budget, the individual and your own pay policy, and pay transparency rules increasingly require you to be able to explain that reasoning. A benchmark is evidence for the decision, not the decision.
How current are the figures?
Posting-derived components refresh daily or weekly. Survey components are as current as the survey cycle, typically one to two quarters behind, and we age them explicitly rather than presenting stale data as live. Every response carries an as-of date per source.
Related blueprints
Job Market Intelligence API
Structured labour-market signal — salary ranges, skill demand and hiring trends — as a data layer inside your HR, recruitment or education product.
Workforce Planning Forecast API
Forecasts of future role demand, internal capacity and external skills supply, as a planning layer inside HR, ERP or public-sector workforce software.
Skills Assessment API
Standardised skill tests, scoring and gap analysis delivered as an API your HR or learning platform embeds under its own brand.
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.