Skip to main content

DIWASS Developer Quickstart

DIWASS (Digital Information System for Waste Shipments) enables digital exchange of documentation required for transboundary waste shipments under EU Waste Shipment Regulation.

Commercial software systems can integrate with DIWASS using SOAP web services to submit shipment documentation and retrieve updates from competent authorities.

This guide explains the basic steps required to integrate with the DIWASS platform.

DIWASS Integration Overview​

DIWASS integration consists of two communication directions:

Outbound communication (software → DIWASS)

Used to submit documents:

  • notifications
  • movement documents
  • Annex VII documents
  • attachments

Inbound communication (DIWASS → software)

Used to retrieve updates:

  • authority decisions
  • requests for information
  • status changes
  • signals

DIWASS uses cursor-based polling to deliver updates.

Authentication​

DIWASS APIs are secured using OAuth 2.0 Client Credentials flow.

Each commercial software provider receives credentials from the DIWASS system administrator.

Typical authentication process:

  1. Request OAuth token
  2. Include token in SOAP request headers
  3. Refresh token when it expires

Notification Workflow​

For notified waste shipments (typically orange-listed waste), the typical sequence is:

  1. Upload required attachments
  2. Submit notification
  3. Submit notification authentication (signatures)
  4. Wait for competent authority acknowledgement
  5. Receive authority decisions
  6. Submit movement documents for shipments
  7. Submit reception and completion certificates

Annex VII Workflow​

Annex VII documents are used for green-listed waste shipments and follow a simplified procedure.

Typical workflow:

  1. Submit Annex VII document
  2. Submit arranger authentication
  3. Shipment begins
  4. Submit reception certificate
  5. Submit completion certificate

Receiving Updates from DIWASS​

DIWASS does not push updates directly to client systems.

Instead, software must periodically call synchronization endpoints to receive:

  • authority decisions
  • requests for information
  • status changes
  • signals

Main endpoints used:

  • GetActions — pending actions requiring a response (e.g. decisions, RFIs, signals)
  • GetNotifications — new or updated notifications
  • GetAnnexVIIList — new or updated Annex VII documents

Each response returns a timestamp that must be used as the cursor for the next request. Client software should poll these endpoints and store the returned cursor to retrieve only new or updated records on subsequent calls.

Error Handling​

DIWASS returns SOAP faults when an operation fails.

Typical errors include:

  • Validation errors — invalid field values or missing required data; fix the payload and resubmit
  • Authentication errors — token invalid or expired; request a new token
  • Status conflicts — operation not allowed in the current document status; check status before retrying
  • System errors — temporary DIWASS-side failures

Client software should implement retry logic for temporary failures (e.g. authentication and system errors) and avoid retrying validation or status conflicts until the request or document state is corrected.

Next Steps​

Continue with the API documentation:

  • DIWASS API Overview — architecture, service groups, status transitions, error codes
  • Reference Data API — countries, waste codes, competent authorities, transport modes
  • Notifications API — submit notification, withdraw, authentication, RFI reply
  • Movement Documents API — movement document, carrier transfer, reception and completion certificates
  • Annex VII API — submit Annex VII, authentication, carrier transfer, reception, completion, take-back, signal
  • Synchronization API — GetActions, GetNotifications, GetAnnexVIIList (cursor-based polling)

For key terminology, see the DIWASS Glossary.