AI translation
This page was translated from German with AI. If in doubt, the German original applies.
Glossary
Compact list of terms for the developer portal. Each entry gives the short definition; the detailed explanation is in the relevant guide and is linked.
Terms related to the three ZEDAL storage areas — inbox, file area (Nachweis-Bereich) and transport paper area (Versandpapier-Bereich) — are collected in their own chapter Storage areas.
| Term |
Meaning |
| Provider |
A ZEDAL instance, identified by a numeric ProviderId. On the REST path it is mandatory as the provider_id header on every call. The IDs are environment-specific — an ID from production is not valid on test. Directory: DiscoveryApi/ListProvider. |
| Subscriber |
Contractual tenant within a provider. Bundles the accounts and permissions of an organization; passed as subscriberId at login. Permission scopes are tied to the subscriber assignment. |
| Account |
User account within a subscriber, login identity for CreateSession. Together, the three levels form the user ID pattern account-subscriber@provider. |
| App token |
JWT that identifies the integrating application — not the user. Issued by the API operators per client application and carries its permission profile. Required at login in addition to the credentials. |
| Refresh token |
Long-lived token from AuthApi/IssueRefreshToken; only entitles you to obtain access tokens. Rotates: every RequestAccess returns a new one and invalidates the previous one — the new one must be persisted before the next business call runs. |
| Access token |
Short-lived JWT from AuthApi/RequestAccess; authorizes business calls as Authorization: Bearer. The validity period is stated in the token (exp claim, in the SDK Jwt.ValidTo) — read it there instead of assuming a duration in the client. Scopes such as usermgt are contained in it as a claim. |
| Client ID |
Credential pair for automated processes without a user binding (ClientIdCredentials at login; managed via AuthApi/IssueClientId, ListClientIds, RevokeClientId). Not the Client ID of the DIWASS API client — see below. |
| Discovery |
Procedure for finding the responsible ZEDAL instance. DiscoveryApi/ListProvider is the only operation without a token and without provider_id and therefore step 0 of every integration. |
| ZeWaSS |
XML format in which ZEDAL persists DIWASS documents. The term appears in the SDK in a few places — you work on the derived typed objects. |
Storage areas
| Term |
Meaning |
| Inbox |
An account’s inbox; flat list of incoming document entries with a read and a removed flag. The import from the inbox is the delivery path for incoming document versions, not a cleanup step. See Storage areas → Inbox and Calls and synchronization. |
| File area |
File-based area (File Area): files (File), each with several documents and their own submission lifecycle. See File area. |
| Transport paper area |
Distribution and acknowledgment channel (Transport Paper Area) for individual documents along a transport chain; flat list with a peek-and-acknowledge model. See Transport paper area. |
| File |
File in the file area. Logical folder with a unique FileId, contains one or more documents. |
| Distribution |
Automatic delivery of a transport paper document to the parties identified in the document. Triggered on import via the distribute field. |
DIWASS documents
| Term |
Meaning |
| Submission |
Initial DIWASS document of a shipment — the filing submitted by the notifier with all parties, waste type, quantities and routes. |
| Notification |
Lifecycle envelope around the submission. Goes through acknowledgment, requests for additional information and decisions by the authorities, and ends with consent or withdrawal. See Lifecycle. |
| Movement |
Operational DIWASS document of a single transport under a consented notification. Via the API it is immediately in the Announced state — there is no draft status. |
| Annex VII |
Document format for shipments of green-listed waste under Annex VII of Regulation (EU) 2024/1157; not a full notification procedure. In the SDK Annex7DocumentHandler; recognizable in the event code list by the GLW_ prefix. |
| Notification number |
NotificationId in the format <CA code><YY><serial number>i, example DE0126013237i. The prefix is the authority code; a different prefix is rejected with INVALID-NOTIFICATION-CA-CODE-PREFIX. |
| MovementId |
DIWASS business identifier of a movement: <NotificationId>.<sequence>MOV, example DE0126005197i.000001MOV. Assigned by DIWASS when the movement template is created. |
| Transport paper number |
ZEDAL-side number of the same movement: <NotificationId>.<sequence> with a five-digit sequence and without MOV, example DE0126013235i.00002. Do not confuse the two formats — a retrieval with the wrong one finds nothing. Comparison: Field rules. |
| SequenceNumber |
Sequential number of a movement within a notification, starts again at 1 for each notification. It is not reserved server-side; GetNextSequenceNumber(notificationId) returns the next free one. With truly parallel creation on the same notification, race conditions cannot be ruled out. |
| Stage |
Completed step in the lifecycle of a DIWASS document; in the SDK a method on the document handler (SetCarrierTransport, SetFacilityReception, …). |
| DiwassIntents |
Protobuf enum that lists the follow-up actions permitted on the wire for each DIWASS document (CREATE_SUBMISSION, SUBMIT_DECISION, …). |
| Follow-up intent |
An entry from DiwassIntents that the server reports back after a stage call as the next permitted action. In the SDK the property handler.FollowupIntents — not a method. The intended way to determine the state; in the mutation data model, the document itself carries no status. See Determining the state. |
| Event list |
List of changes in DIWASS over a time window (RetrievalApi.LookupEventList). First step of every synchronization: fetch the events first, then specifically the affected documents — never a full export. See Fetching changes. |
Shipment terminology
| Term |
Meaning |
| Facility chain |
The sequence of facilities that a notification lists: the first facility plus all downstream ones in the case of an interim recovery or disposal operation (Article 15(1) of Regulation (EU) 2024/1157), i.e. 1 + n. This results in several confirmations of receipt and certificates of completed recovery or disposal per movement, and in a movement status that is an aggregation over the chain. See Facility chain. |
| Interim recovery or disposal operation |
Recovery or disposal after which the waste goes on to a further facility (InterimFacility in FacilityType.OperationalIndicators). Two continuations with very different consequences: in the country of destination (Article 15(5)), an Article 15 certificate is sufficient; abroad (Article 15(7)/(8)), a new notification with its own movements is required. |
| Article 15 certificate |
Proof from the subsequent facility of completion after an interim operation. It is attached to the notification, not to the movement, and names several shipments via movementIdentifier. In the SDK SetFacilityCompletionUnderArticle15 on the NotificationDocumentHandler. |
| Intended number of shipments |
The total number of intended shipments stated in field 4 of the notification. The number of movement documents must not exceed it; a properly canceled document does not count, an abandoned one does. Once exhausted, it surfaces as MOVEMENT_TEMPLATE_INVALID_TOTAL_NUMBER. See Intended number of shipments. |
| API client (DIWASS) |
Technical configuration of the European Commission under which several users access DIWASS as a group; the identifier is neutral (examples WSR01, WSR85). The Commission can move users between API clients — that is why the Client ID attribute must be configurable in your integration. See API client and Client ID. |
DIWASS roles
| Role |
Wire name |
Meaning |
| Notifier |
Notifier |
Central actor: notifies the shipment, authenticates it and initiates the movement. |
| Waste producer |
WasteProducer |
Slot in the submission for the party where the waste is physically produced. |
| Carrier |
Carrier |
Transporter of the waste; records the transport data in the movement. |
| Consignee |
Consignee |
Party to which the waste is delivered; confirms receipt of the goods. If the consignee is also the facility, this stage is omitted. |
| Facility |
RecoveryDisposalFacility |
Recovery or disposal facility (FacilityTypeCode R or D); confirms acceptance and completes the treatment with an R or D code. Present several times in the notification, see facility chain. |
| Competent authority |
Authority (CA) |
Competent authority of dispatch, of destination or of transit; takes part in the lifecycle via acknowledgments, decisions and signals. Each authority involved decides individually; the notification is only consented once all of them have given their consent. |
| Operator |
— |
Economic operator that takes on one or more roles. Identified by OperatorInternalId, EORI number, W-ID or § 28 number. See Roles. |
| OperatorInternalId |
— |
Unique numeric (long) identifier of an operator in the DIWASS operator register; carried in all DIWASS calls. client.MyAccount.GetOwnDiwassOperatorIds() returns the logged-in user’s own IDs. |
eANV and signatures
| Term |
Meaning |
| Consignment note (Begleitschein, BGS) |
Document of the eANV that accompanies a transport of waste subject to record-keeping from the waste producer to the disposer; number “1” followed by 13 digits. See Procedure and roles. |
| Acceptance note (Übernahmeschein, UNS) |
Document for the acceptance at the individual waste producer in collective disposal and for small quantities; number “2” followed by 13 digits. |
| Disposal certificate (Entsorgungsnachweis, EN), collective disposal certificate (Sammelentsorgungsnachweis, SN) |
Admissibility of the disposal confirmed in advance; the consignment note refers to it via nachweis_nr. |
| Layer |
Section of an electronic consignment note that exactly one party creates and signs; each layer contains all previous ones. Types: template, waste producer, carrier, interim storage facility, disposer, supplement, authority. See Layers. |
| Waste transport party (Abfalltransportbeteiligter, ATB) |
Waste producer, carrier, interim storage facility and disposer of a consignment note. The Rolle (in the schema ATBRolle) states for whom a template or supplement layer is created. |
| Official number (behördliche Nummer) |
Waste producer, carrier or disposer number assigned by the competent authority (Section 28 NachwV). ZEDAL uses it to determine to whom a consignment note is delivered. |
| Collector (Einsammler) |
Carrier who picks up from many waste producers in collective disposal; enters itself as carrier in the consignment note of the tour. |
| Forwarding (Vermittlung) |
Delivery of a stored transport document to the other parties; triggered by distribute. See Distribution. |
| Ten-day report (Dekadenmeldung) |
Transmission of a completed consignment note to the authorities via the ZKS-Abfall, triggered by dekadenmeldung when storing the disposer layer. See Consignment note by role. |
| ZKS-Abfall |
Joint body of the German federal states for electronic record-keeping (Section 20 NachwV); documents to authorities and to parties at other eANV providers pass through it. |
| Signing process |
SigningProcess in the WebSigner: documents that a person signs with a qualified signature via a link. See Signing with the WebSigner. |
| signing_url |
Link to the signing process for the person who signs. Carries a time-limited token bound to the process and must be treated as confidential. |
Abbreviations
| Abbreviation |
Expansion |
| ATB |
Abfalltransportbeteiligter — waste transport party |
| AVV |
Abfallverzeichnis-Verordnung — German List of Waste ordinance; source of the six-digit waste codes in the eANV |
| BGS |
Begleitschein — consignment note |
| CA |
Competent Authority — competent authority within the meaning of Regulation (EU) 2024/1157 |
| DIWASS |
EU central system for handling the transboundary shipment of waste under Regulation (EU) 2024/1157 |
| DVO |
Durchführungsverordnung (implementing regulation) — here: Implementing Regulation (EU) 2025/1290 |
| eANV |
German electronic waste record procedure (elektronisches Abfallnachweisverfahren) under the NachwV |
| EN |
Entsorgungsnachweis — disposal certificate |
| EORI |
Economic Operators Registration and Identification — EU-wide customs identifier for economic operators |
| GLW |
Green Listed Waste — shipment under Annex VII |
| gRPC |
gRPC Remote Procedure Calls |
| JWT |
JSON Web Token |
| KrWG |
Kreislaufwirtschaftsgesetz — the German Circular Economy Act |
| LoW |
List of Waste — European list of waste; also the listID of the waste code |
| NachwV |
Nachweisverordnung — the German ordinance on waste records, the legal framework for domestic waste record-keeping |
| QES |
qualified electronic signature under the eIDAS Regulation (EU) 910/2014 |
| REST |
Representational State Transfer |
| SDK |
Software Development Kit |
| SN |
Sammelentsorgungsnachweis — collective disposal certificate |
| UNS |
Übernahmeschein — acceptance note |
| VO |
Verordnung (regulation) — here: Regulation (EU) 2024/1157 |
| W-ID |
Wirtschaftsidentifikationsnummer — German business identification number, a uniform nationwide identifier for economically active persons and entities in Germany |
| WSDL |
Web Services Description Language |
| XSD |
XML Schema Definition |
| ZKS |
ZKS-Abfall, joint body of the German federal states for electronic record-keeping |