Defra publishes a developer guide and the technical specification openly, which is genuinely helpful and slightly misleading. Helpful because you can see exactly what is required before committing. Misleading because reading a clean specification makes the work look like a fortnight.
Here is where the time actually goes.
Mapping your data to theirs is most of the job
Your system has fields. Defra has fields. They are not the same fields, and the gap is where the work lives.
Your descriptions are free text written by whoever was on the weighbridge. Your quantities may be in whatever unit the ticket used. Your customer record is a name in your accounts system, not an identifier anyone else recognises. Every one of those has to become something Defra will accept, consistently, including for the records you created before anyone thought about this.
On a typical job this is more than half the effort, and it is the part that determines whether submissions get accepted later.
Then you build against the spec
Straightforward by comparison. Authenticate, format the payload, send it, read the response. A competent developer working from the published guide will have this working in test in days.
The trap is treating a working test submission as done. Test environments are forgiving. Yours is a controlled payload you constructed. Production is a Tuesday afternoon with a mis-keyed weight and a supplier whose name has an apostrophe in it.
The unhappy path is the real product
What separates an integration that holds up from one that quietly stops working is entirely about failure handling.
- Rejections. Something will be refused. Somebody has to find out, in language that says what to fix.
- Retries. Connections drop. A failed submission has to try again rather than vanish.
- Duplicates. Retries must not submit the same movement twice, which means every movement needs an identity that survives a restart.
- Corrections. A weight gets amended the next morning. The submitted record has to be amended too.
- Silence. The worst failure is the one nobody notices. If nothing has been submitted for six hours during working hours, somebody should hear about it.
That last one is the difference between a compliance gap of an hour and a compliance gap of a quarter.
Going live, and staying live
Cutover is deliberately dull. Run in parallel for a period, compare what your system thinks it sent against what was accepted, and only then stop the old process. Nobody should be switching off a manual route on the strength of one good test.
After that, the ongoing job is keeping pace. Specifications move, particularly between Phase 1 and Phase 2. An integration is not a thing you finish, it is a thing you maintain, and anyone telling you otherwise has not run one.
A realistic shape
For a single site with a readable system: a few weeks, most of it in mapping and failure handling rather than the API itself. Multiple sites, several data sources, or messy historical descriptions will be longer. We scope before quoting for exactly that reason, because the variable is your data, not their specification.
Want to know what shape yours is? A look at what your system records, and how consistently, tells us most of what we need. It is a short call and you get a straight answer. Book a call