DIWASS API vs web portal: which one fits your volume?
Every DIWASS user eventually faces the same choice: file through the government web portal, or integrate the API. There is no single correct answer - but there is a wrong way to decide, and that is to guess. The right path comes down to one number: how many cross-border shipments you notify each month.
What the government web portal covers
DIWASS ships with a government-provided web portal, and it covers the baseline legal requirement in full. You can file notifications, update statuses and confirm receipts through it manually. For occasional cross-border activity - a handful of shipments a month - that is genuinely enough: no integration project to run, no development work to plan, no ongoing upkeep to own.
The trade-off only shows up as volume grows. Nothing about the portal breaks. It just scales linearly with your staff time, because every shipment is typed in by a person.
What manual filing actually costs
A fully manual notification cycle is four steps, and none of them are hard. The problem is that they repeat, per shipment, indefinitely.
Each cycle takes 33 minutes or more. At a modest 40 shipments a month, that is over 22 hours of pure administrative time every month - roughly three working days spent re-typing data you already have.
What the DIWASS API actually solves
DIWASS exposes a SOAP/XML API with message-level security for direct system-to-system integration. The point is not speed for its own sake - it is that data stops being re-entered, and validation moves to the moment of booking.
No double entry
Shipment data moves from your existing ERP or TMS straight into DIWASS. Teams never re-type what they have already recorded.
Eural codes checked in real time
The system validates the Eural code against the relevant permit at the point of booking - not days later, and not at the border.
Status updates sync automatically
Announced, Moving, Received and Completed sync back to the ERP without anyone watching a portal screen.
Receipt confirmations match reality
On the processor side, confirmations can be matched against real arrival data, which protects the three-working-day confirmation window.
Done properly, the same shipment cycle drops from 33 minutes to three to five - roughly an 88% cut in processing time, and the 22-plus hours a month at 40 shipments drops to almost nothing. The cost sits upfront instead: this is an integration project, not a form to fill in, and it needs proper planning against whatever ERP or TMS is already in place.
DIWASS API vs web portal, by monthly volume
The thresholds are about staff time and error probability, not about compliance status. The portal is legally sufficient at any volume. It simply stops being operationally sufficient long before it stops being legal.
What integration actually depends on
DIWASS compliance is not only about the notification itself. It depends on the operational data behind it: which material moved, from where, on which vehicle, and confirmed by whom.
If that data already lives in a structured, connected system, integration is a fairly short technical step. If it is still scattered across spreadsheets and inboxes, the integration project quietly turns into a data cleanup project first - and that is the part that takes the time, not the API.
Where this lands in Evreka's product split
Once volume and data readiness are clear, the choice generally maps to one of three paths.
Evreka360 - DIWASS-native waste ERP →
Compliance built in rather than added later. Best for producers, processors and high-volume carriers who want one system for operations and notifications.
Wasteform - the document-only path →
Annex VII, IA and IB plus national variants like the Begeleidingsbrief, e-IDF and Begleitschein. Fits EU-wide document needs without replacing your ERP.
Custom Integration →
Built around the ERP environment you already run, when replacing it is not on the table.
DIWASS API vs web portal, in short
Is the DIWASS web portal enough to be compliant?
Yes. The government portal covers the full legal requirement at any volume - notifications, status updates and receipt confirmations. The question is operational, not legal: above roughly 20 shipments a month, manual entry starts costing more staff time than the integration would.
What kind of API does DIWASS use?
A SOAP/XML API with message-level security, designed for direct system-to-system integration from an ERP or TMS. It is not a REST/JSON API, so plan the work against SOAP tooling.
How much time does API integration actually save?
A manual cycle runs 33 minutes or more per shipment; an integrated one runs three to five - about an 88% reduction. At 40 shipments a month that removes 22-plus hours of administrative work.
At what volume should we integrate?
Below 20 cross-border shipments a month, stay on the portal. Between 21 and 100, evaluate seriously. Above 100, integration is close to essential.
What blocks a DIWASS integration most often?
Not the API - the data. If material, route, vehicle and confirmation data is scattered across spreadsheets and email, that has to be consolidated first. Structured operational data makes the integration itself a short step.
Related DIWASS resources
DIWASS requirements →
The data fields, documents and timing rules a notification has to satisfy - whichever channel you file through.
The chain dependency risk →
Why one unregistered carrier or processor blocks a notification you have already filed correctly.
DIWASS for IT teams →
What an integration involves technically: the API, the data model, and the ERP side of the work.
DIWASS Guide - dates & full FAQ →
The complete reference: key dates, the full FAQ, and a glossary of DIWASS terms.
Not sure which side of the line you're on?
Walk through your monthly shipment volume and current systems with us, and get a clear recommendation on portal, API or full ERP - before you commit to an integration project.