Around 30.2 million people were paid through UK payroll in December 2025, every one of them reported to HM Revenue and Customs through Real Time Information on or before payday [1]. Behind each of those payments sits a Full Payment Submission carrying tax, National Insurance and deduction data in a strict HMRC format [2]. A payroll API is the mechanism that lets software generate those figures and file that submission automatically, without a person keying anything into a government portal.
The term describes an application programming interface that exposes payroll calculation and reporting as a set of programmable endpoints. Instead of a screen an operator clicks through, the payroll runs as code: a system sends employee and pay data in, and receives calculated tax, National Insurance, net pay, payslips and RTI submissions back. For developers building HR platforms, ERPs or accounting tools, it turns UK payroll from a product to buy into a capability to embed.
This article sets out what a payroll API actually does, how it fits into the HMRC reporting chain, what separates a genuine payroll engine from a simple data connector, and what a development team should check before choosing one. It is written for software teams, product leaders and technical founders weighing whether to build payroll themselves or call an engine that already holds HMRC recognition.
Key takeaways
- A payroll API exposes payroll calculation and HMRC reporting as programmable endpoints, so software can run UK payroll without manual data entry.
- Every UK payroll must file a Full Payment Submission on or before each payday under Real Time Information [2].
- HMRC recognition certifies that software meets the specification for sending RTI submissions such as the FPS and EPS [3].
- Late RTI filing carries fixed monthly penalties from £100 to £400 depending on headcount, plus a 5% charge after three months [4].
- An embeddable payroll engine differs from a data-sync integration API: the engine performs the payroll, the connector only moves data between existing systems.
What a payroll API is, in practice
An API is a contract between two pieces of software. One system makes a request in an agreed format, and the other returns a response in an agreed format. A payroll API applies that pattern to the full lifecycle of paying employees: registering an employer, adding workers, running a pay period, producing payslips, and submitting the results to HMRC.
The defining feature is that the calculation logic lives on the server side. When a platform sends gross pay, a tax code and a National Insurance category for an employee, the engine applies the current PAYE tax tables and NI thresholds and returns the exact deductions. For the 2026-27 tax year, that means applying a Personal Allowance of £12,570, basic-rate income tax of 20% up to £50,270 [5], and employer National Insurance of 15% on earnings above the £5,000 Secondary Threshold [6]. The calling application never has to encode those rules itself.
The core objects a payroll API models
Most payroll APIs are organised around a small set of resources that mirror how payroll works in real life. Understanding these objects is the fastest way to read any payroll API's documentation, because the naming is broadly consistent across the category.
| Resource | What it represents | Typical operations |
|---|---|---|
| Employer | The PAYE scheme, its reference and settings | Create, read, update |
| Employee | A worker, their tax code, NI category and pay details | Create, read, update, mark as leaver |
| Pay run | A single pay period for a group of employees | Create, calculate, finalise |
| Payslip | The calculated result for one employee in one period | Read, download PDF |
| RTI submission | The FPS or EPS sent to HMRC | Create, submit, check status |
A pay run ties the objects together. The platform opens a pay run for a period, the engine calculates each employee's payslip, and on finalisation it generates the Full Payment Submission that reports every payment to HMRC [7]. Moonworkers, an HMRC-recognised UK payroll platform, structures its HMRC-recognised payroll API around exactly this object model, so a developer reading the reference recognises the shape immediately.
Calculation is the hard part, not the plumbing
Sending a request over HTTP is straightforward. The value of a payroll API is in the accuracy of what comes back. UK payroll requires the engine to apply income tax across three tax regimes (England and Northern Ireland, Scotland with six bands, and Wales), National Insurance across more than a dozen category letters, student loan deductions across five plans, auto-enrolment pension assessment, and every statutory pay category [5][6]. Encoding those rules once, correctly, and keeping them current every April is the work most teams underestimate when they consider building payroll in-house.
How a payroll API connects to HMRC
The reason payroll cannot simply be a spreadsheet is Real Time Information. Since RTI became mandatory across the UK in 2013, employers must report payroll data to HMRC electronically on or before the date each employee is paid [2]. A payroll API is the component that constructs and transmits those reports.
The two RTI submission types
RTI is built on two main electronic returns, and a competent payroll API produces both. The Full Payment Submission is the workhorse, sent every time employees are paid; the Employer Payment Summary reports amounts that reduce what the employer owes HMRC.
| Submission | When it is sent | What it reports |
|---|---|---|
| Full Payment Submission (FPS) | On or before every payday | Pay, tax, NI, student loans and statutory payments per employee [[8]](https://www.gov.uk/hmrc-internal-manuals/debt-management-and-banking/dmbm519215) |
| Employer Payment Summary (EPS) | Monthly, when applicable | Statutory pay recovery, Apprenticeship Levy, nil payments [[9]](https://www.gov.uk/hmrc-internal-manuals/debt-management-and-banking/dmbm519220) |
The FPS must contain mandatory employer and employee information, the payroll ID, starter and leaver details, and the full breakdown of NI, tax, student and postgraduate loan repayments, and statutory payments [8]. An Employer Payment Summary is required in specific circumstances, such as reclaiming statutory maternity pay or reporting a month with no payments at all [9]. A payroll engine that only produces an FPS is incomplete.
Recognition, authentication and testing
Software that submits RTI must meet HMRC's published specification, and software that passes is listed as HMRC-recognised [3]. Recognition is granted against the Real Time Information specifications for the relevant tax year, and developers apply to HMRC's Software Developer Support Team to obtain it [10]. For any UK payroll product, this is the entry threshold rather than a distinguishing feature, because every serious product in the market holds the badge.
Connecting to HMRC's services also involves the technical scaffolding that the HMRC Developer Hub documents. HMRC uses the OAuth 2.0 standard to issue access tokens, which are then passed as bearer tokens on each API call [11]. Certain submissions require fraud prevention headers that identify the origin of the request, and HMRC provides a validator to check them [12]. Every integration is expected to be proven in a sandbox against the base URL `https://test-api.service.hmrc.gov.uk` before production credentials are granted [13]. A payroll API abstracts most of this away, so the platform embedding it does not have to implement OAuth flows or header logic against HMRC directly.
Why the filing rules make an API worth it
The strict timing of RTI is what makes automated filing valuable. An FPS is expected on or before payday, and a late return can trigger a penalty [4]. HMRC does allow a short grace window: no late-filing penalty arises where the FPS reaches HMRC within three days of the payment date [4]. Beyond that, the penalties are fixed and scale with headcount.
| Employees in the PAYE scheme | Monthly late-filing penalty |
|---|---|
| 1 to 9 | £100 |
| 10 to 49 | £200 |
| 50 to 249 | £300 |
| 250 or more | £400 |
Where a failure continues beyond three months, HMRC may add a further penalty of 5% of the tax and Class 1 National Insurance that the missing return should have shown [14]. A payroll API that submits the FPS automatically at the moment a pay run is finalised removes the human step that causes most late filings. This is the practical case for embedding payroll software rather than relying on a manual portal upload each period.
The free tool sets the floor, not the ceiling
The government publishes a free desktop application for the smallest employers. It is capped at nine employees, does not produce payslips, and does not assess auto-enrolment [3]. It is the baseline against which any commercial payroll capability has to justify itself. For a software platform serving businesses that outgrow nine staff, need payslips, or must assess pensions, that free tool is not an option, which is precisely the gap a payroll API fills.
Embeddable engine versus data-connector API
A frequent point of confusion is that two very different products both get called a payroll API. The distinction matters when a team is choosing what to integrate.
A data-connector API belongs to a payroll product the customer already uses. Its purpose is to pull payroll data out and sync it with adjacent tools, for example pushing figures into an accounting ledger. The customer cannot run payroll through it, because the payroll still happens inside the host product.
An embeddable payroll engine works the other way around. The API is the payroll product. Another platform calls it from inside its own interface, and the end user never has to open a separate payroll account. This is the model that lets an HR platform or ERP deliver full UK payroll to its users without becoming a payroll company itself. Teams evaluating whether to build an embeddable UK payroll engine into their product should confirm which of the two models a given API actually offers.
What a genuine engine exposes
Beyond calculation and RTI, a complete payroll engine handles auto-enrolment assessment on every pay run, with schemes such as NEST, Smart Pension and The People's Pension supported natively. It produces the year-end documents, the P60 for employees on payroll at 5 April and the P45 for leavers. It covers the Construction Industry Scheme where relevant. A platform embedding payroll should map its requirements against this full statutory surface, because gaps only surface at month-end or year-end when they are most expensive to discover. Accountants running this across many client schemes typically rely on a multi-client payroll dashboard built on the same engine.
What to check before choosing a payroll API
Selecting a payroll API is a technical and a compliance decision at once. A short evaluation checklist keeps both in view.
The first check is HMRC recognition, confirmed against the official list [3]. The second is the statutory coverage: PAYE across all three regimes, National Insurance across every category letter, student loans across all five plans, auto-enrolment, statutory pay and year-end forms [5][6]. The third is developer experience: public documentation, a sandbox, and self-serve access so a team can evaluate the API without a sales process. Moonworkers publishes its full API documentation openly for exactly this reason.
The fourth check is the pricing model. Some payroll products charge a fixed licence per employee per month; others charge per payslip, so cost scales with payroll activity rather than headcount. The fifth is independence: a payroll engine tied into a wider accounting or HR suite forces the buyer into that ecosystem, while a standalone HMRC-recognised engine carries no such constraint. For occasional or one-off needs, a lighter option such as an instant payslip generator may fit better than a full integration.
Conclusion
A payroll API turns UK payroll from a system a business logs into a service software can call. Its real substance is not the HTTP layer but the calculation engine underneath: the current PAYE, National Insurance, student loan and pension rules applied correctly on every pay run, and the Full Payment Submission filed to HMRC on or before payday. HMRC recognition proves the reporting meets specification, and it is the floor every serious product clears, not a differentiator.
The direction of travel is towards more embedding. As HR platforms, ERPs and bureau tools increasingly want to deliver UK payroll inside their own products rather than send users elsewhere, the payroll engine becomes compliance plumbing that other software calls. The teams that understand the difference between a data connector and an embeddable engine, and that treat statutory coverage as non-negotiable, are the ones that ship payroll features without inheriting payroll's regulatory risk.
Frequently asked questions
Is a payroll API the same as HMRC-recognised payroll software?
Not automatically. HMRC recognition certifies that a piece of software meets the specification for sending Real Time Information submissions such as the FPS and EPS [3]. A payroll API can hold that recognition, but the label "payroll API" on its own does not guarantee it. A team should confirm the specific product appears on HMRC's recognised list before relying on it for live filing.
Can a payroll API file RTI submissions to HMRC automatically?
Yes. A payroll engine constructs the Full Payment Submission from the finalised pay run and transmits it to HMRC electronically, on or before payday as RTI requires [2]. It also produces the Employer Payment Summary when one is due, for example to reclaim statutory pay or report a nil payment month [9]. Automating the submission removes the manual step that causes most late-filing penalties.
What happens if a payroll submission is filed late?
HMRC applies a fixed monthly penalty based on the number of employees in the scheme, ranging from £100 for one to nine employees up to £400 for 250 or more [4]. No penalty arises if the FPS reaches HMRC within three days of payday. A failure continuing beyond three months can attract a further penalty of 5% of the tax and National Insurance due on the missing return [14].
Do developers need to build against the HMRC Developer Hub directly?
Not when using an embeddable payroll engine. HMRC's own APIs use OAuth 2.0 for authentication and require fraud prevention headers on certain submissions, all tested in a sandbox before going live [11][13]. A recognised payroll API handles that layer on the platform's behalf, so the developer integrates against one clean interface instead of implementing HMRC's transport and authentication rules themselves.
