AI translation
This page was translated from German with AI. If in doubt, the German original applies.
DIWASS integration¶
DIWASS is the EU’s central system for the transboundary shipment of waste. ZEDAL encapsulates communication with DIWASS: you work against the ZEDAL API or the .NET SDK, not against the EU SOAP interface.
Two legal acts are decisive, and the second is often overlooked:
| Legal act | Governs |
|---|---|
| Regulation (EU) 2024/1157 (Waste Shipment Regulation) | the procedure: who notifies, who consents, which documentation is due |
| Implementing Regulation (EU) 2025/1290 (implementing act) | the technical implementation: data model, operation types and the authentication obligations in Article 14 |
For an integration, the Implementing Regulation is the more concrete source.
This section¶
| Page | Content |
|---|---|
| Roles | The six roles, their slots in the data model, their cardinalities (schema versus server rule), operator IDs, the SDK’s permission building blocks, distinction from the Nachweisverordnung (NachwV), the German ordinance on waste records |
| Lifecycle | States per document type, stage order, the two-step sending procedure (SaveToZedal → SendToDiwass plus asynchronous response), facility chain, time limit terms |
| Notification (Company) | Stage by stage with code: create a notification, correspond with authorities, change it after consent, cancel it |
| Movement (Company) | Stage by stage with code: create a movement, transport, receipt of the waste, acceptance, completion |
| Authority | The authority side — acknowledgment of receipt, request for additional information, precondition signals, decision, take-back. And above all: which of these reach you and when |
Then there is the reference layer, which is not structured specifically around DIWASS but mostly contains DIWASS rules:
| Page | Content |
|---|---|
| Field rules | Mandatory fields beyond the schema, number formats, context-dependent formats, fields you are better off omitting, cross-references the server checks |
| Code lists | Waste codes and listID values, R/D codes, packaging type, HP codes, event codes, spelling traps |
| Error codes | Transport errors and business errors kept apart, where a rejection really shows up, catalog of DIWASS codes |
| Calls and synchronization | Call frequency, error handling, fetching changes made by others, time budgets |
Calls and synchronization is required reading before going live
Three properties of the interface bring down any integration that is not aware of them:
- The EU requires sequential calls against DIWASS and reserves the right to block API access in case of continued violations. Parallelizing across multiple documents is risky.
- There is no draft status via the API. What would be a draft in the user interface is already submitted via the interface. A document submitted with errors is submitted.
- Time budgets are larger than expected. The SDK’s client default is 30 seconds; a push with an attachment takes over 90, multi-stage movement chains considerably more — per stage.
Recommended reading order¶
- Roles — the vocabulary. Who fills which slot, who may trigger which operation, and why the NachwV translation does not hold up.
- Lifecycle — the process model: stages, sending procedure, asynchronous response. Without these terms, the step-by-step guides are hard to follow.
- Calls and synchronization — the operating rules. Read them early, not only when debugging.
- Notification (Company), then Movement (Company) — the actual blueprint. A movement only exists for a consented notification, hence this order.
- Authority — even if you are not building the authority role: the state changes of your notification come from there.
- Field rules and Code lists — keep them open alongside while filling in data. Both are reference works, not meant to be read from start to finish.
On the first rejection: Error codes. The page first explains where the error shows up — transport errors, ValidationErrors, TransferHistory and transfer details are four different places — and then what the codes mean.
Annex VII (green list)¶
For shipments of green-listed waste under Annex VII, the SDK has a dedicated handler, CreateAnnex7Handler() (Handlers and lifecycle).
The stages are structurally similar to the movement but have their own methods: CreateAnnex7 / SetAnnex7, SetAnnex7CarrierTransfer, SetAnnex7ConsigneeCertificate, SetAnnex7FacilityCertificate, SetAnnex7CertificateOfCompletion, SetAnnex7TakeBack. The sending procedure, follow-up intents and error handling are the same as for notification and movement.
This documentation does not yet include a dedicated step-by-step guide for Annex VII. The role and lifecycle concepts apply unchanged; the Annex VII-specific intents are also listed in Roles and permissions in the SDK.
Code examples¶
The guides describe the stages in business terms. The C# code for them, with types, mandatory fields and call order, is in the SDK section: Notification with the SDK, Movement with the SDK and Authority side with the SDK.
DIWASS ↔ NachwV distinction¶
- DIWASS — transboundary shipment, EU-wide, Regulation (EU) 2024/1157 and Implementing Regulation (EU) 2025/1290. Subject of this section.
- NachwV — national waste record procedure, covered in ZEDAL by other modules. Not the subject of this section.
A mapping table “NachwV role ↔ DIWASS role” is not reliable without context knowledge. The structural differences — and why they trip you up when translating — are described under Roles → DIWASS ↔ NachwV.