Skip to content

AI translation

This page was translated from German with AI. If in doubt, the German original applies.

Changelog

This page lists the published versions of the two public packages and the status of deprecations.

Package Content Current
Zedal.Sdk The .NET SDK 1.2.0
Zedal.GrpcApis The generated gRPC/Protobuf types. Comes transitively with the SDK; can also be referenced directly for your own gRPC clients 1.2.0

Both follow Semantic Versioning (MAJOR.MINOR.PATCH) and are published as a pair: the SDK package references a fixed Zedal.GrpcApis version. Pre-releases carry a suffix (1.1.0-diwass-preview-9); without --prerelease, NuGet does not resolve them.

Deprecations are not marked as deprecated in the REST reference

In the live OpenAPI reference, none of the 131 operations carries the deprecated flag — although the proto contract contains deprecated elements, including an entire operation. Only CompanyDocumentApi/GetDocument can be recognized by the suffix “(deprecated)” in its title and by its description. If you try to read the deprecation status from the reference UI, you find nothing else.

The authoritative source is therefore the section Deprecated on this page.

Published versions

Stable versions, with the date of the respective release:

Version Date Zedal.Sdk Zedal.GrpcApis
1.2.0 2026-07-21 yes yes
1.1.4 2026-05-14 / 2026-05-15 yes yes
1.1.3 2026-05-11 — yes
1.1.2 2026-05-11 yes yes
1.1.1 2026-05-08 / 2026-05-10 yes yes
1.1.0 2026-05-07 yes yes

Before 1.1.0, there were only pre-releases: the series 1.0.0-rc1 to 1.0.0-rc6 (June 2025 to March 2026) and 1.1.0-diwass-preview-1 to -9 (March to May 2026). A stable 1.0.0 does not exist — the first stable version is 1.1.0. The version numbers of the two packages do not run exactly in parallel: 1.1.3 exists only for Zedal.GrpcApis, 1.1.0-diwass-preview-9 only for Zedal.Sdk.

BMU API

The BmuDocumentApi (infotech.zedal.bxa.bmu.v1.api) is public: six operations for BMU consignment notes and acceptance notes, available via REST, gRPC and gRPC-Web.

  • SDK: client.DocumentHandler.CreateBmuHandler() returns the BmuDocumentHandler. Create, UpdateDocument and AddLayer accept XmlOptions (validation level, check digits, ATB role).
  • REST: Transport documents can be stored via REST (DocumentApi/ImportTransportDocument); inventory, inbox and templates can be listed (QueryApi). The calls are described under Via REST.
  • Signing: Signatures that complete a layer are not yet possible via the SignerApi (Signing).

Guides: eANV (BMU), with examples per role.

WebSigner

Signing processes via the service infotech.signer.sign.v1.api.SignerApi, in the SDK client.SignerApi.SigningProcesses: create and present a process, let the person sign via the signing_url, retrieve the signed documents. SignAsync does this in a single call. The WebSigner is a preview and not yet available in production.

Guide: Signing with the WebSigner.

OpenAPI spec: schema names

The schema names in the public OpenAPI spec are fully qualified, for example infotech.zedal.documents.v1.bmu.BGSDokument. This applies to all APIs, including DiWaSS. The JSON on the wire stays the same; only the type names in clients generated from the spec change.

1.2.0 — 2026-07-21

Contains breaking changes, even though it is a minor bump

Some of the changes to the proto contract between 1.1.4 and 1.2.0 are not backward compatible. If you are coming from 1.1.x, expect to make adjustments — do not plan the update as a mere package upgrade; read the list below and compile against the new version before you take it into a release branch.

Zedal.GrpcApis 1.2.0 — Breaking changes

Change Affected
Customs codes: a new type introduced by the EU replaces the previous string/token definition Annex 7 and notification
Field group renamed to group_nr AccountMgt / DocRestrict
AccountDocRestrict removed from accountmgt/v1; separate service AccountDocRestrictApi in v2 AccountMgt
core/v1/common_types.proto and common_api.proto restructured (field and type adjustments) everyone who references generated types directly

Zedal.GrpcApis 1.2.0 — Enhancements

  • DIWASS Waste extended significantly: new fields and messages in movements, retrieval, notification, submission, basetypes.
  • DIWASS Directory: new protos and fields for the authority and operator directory, including an operator/v2 version.
  • ZEWASS: CommPartner structures and an address oneof (ZEDAL / DIWASS); the local attachment information has been adapted to the DIWASS requirements — including a field for the DIWASS attachment type and a flag for attachments containing personal data.
  • FetchDocumentNumbers: new number type DIWASS_NOTIFICATION.
  • GetAccountNumbersResponse returns the account’s own authority IDs (only for authorities themselves).
  • Print output: PrintOptions on the TransformToGraphicalRepresentation request, including the output language.
  • Auth: core/v1/auth_api extended with documentation of the token flow.
  • OpenAPI descriptions added across large parts of the DIWASS and ZEWASS areas; proto comments translated into English.

Zedal.Sdk 1.2.0 — Enhancements

  • New transport stack: selectable transport via ZedalTransport (Grpc, GrpcWeb, Auto) on ZedalClientFactory and ZedalConnectionFactory; connection setup has been reworked. See .NET SDK → Transport.
  • Auto probe: the fallback to gRPC-Web happens only on positive evidence that the host does not speak HTTP/2.
  • Proxy support: detection of the system proxy, SDK-specific proxy URL, bypass sentinel bypass; INFOTECH_GRPC_NO_PROXY remains supported as a deprecated path.
  • CheckConnection() with status and proxy information (ZedalConnectionStatus).
  • Message size of the channels raised to 50 MB.
  • GetAttachment: its own timeout option.
  • MovementDocumentHandler.GetNextSequenceNumber(notificationId) — determines the next free sequence number on the client side via the transport paper index. Interim solution: there is no server-side reservation path for DIWASS movements.
  • Whitespace normalization of the operator data read from DIWASS, extended and configurable (WhitespaceNormalizer, WhitespaceHandling).

Zedal.Sdk 1.2.0 — Notes for implementers

The signatures of ICommonApi, IOperatorApi and IAttachmentApi have been adjusted — mostly additively. If you implement these interfaces yourself (test doubles, your own adapters), you need to follow suit; pure callers are usually not affected.

Before 1.2.0

For versions 1.1.0 to 1.1.4, there are no published release notes. What one of these versions contains can only be read from the package itself — via the API reference of the respective version. If you need a reliable list for a migration from 1.1.x, request it through support instead of guessing it from gaps in the version numbers.

Deprecated

Deprecated elements remain in the contract and continue to work until they are removed with a major version cut. They are marked as deprecated in the proto; in a generated client, they therefore appear as compiler warnings, depending on the language.

Element Replacement
CompanyDocumentApi.GetDocument (operation) the family-specific getters GetNotification, GetMovement, GetAnnex7. The endpoint remains available for existing callers until the next v1 cut.
Field document (generic Document container) in the responses of the Set… and Submit… operations of CompanyDocumentApi (15 messages) and AuthorityDocumentApi (7 messages) the typed field notification or movement of the same response
Field matching_id in FindOperatorRequest (diwass.v1.api) the embedded request field of the operator directory version v2
Environment variable INFOTECH_GRPC_NO_PROXY (SDK) INFOTECH_GRPC_PROXY_URL=bypass or the parameter proxyUrl — see Proxy in corporate networks

What is not listed here is not deprecated

The converse applies deliberately: elements missing from this table are part of the supported contract — even if a newer, typed variant exists alongside them. A deprecation is announced in this section before it takes effect.

Open issues

  • Being notified of new DIWASS responses. There is currently no push channel, and the mechanism has not been defined. What this means for the design of an integration is described under Webhooks and event notification.

Next

  • .NET SDK — Installation, architecture, transport, handlers
  • REST / JSON — the reference always reflects the live state, not a package version
  • Getting started — Access and first call