Skip to content

AI translation

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

SDKs

An official SDK is available for .NET. For all other languages, the way in is via the generated contracts — either REST/JSON or gRPC.

Language Path Status
C# / .NET NuGet package Zedal.Sdk → .NET SDK available
any language with an HTTP client codegen from the OpenAPI document → REST / JSON available, with limitations
any language with a gRPC toolchain codegen from the protos → gRPC available

No SDK is currently announced for other languages.

Which path to take?

  • .NET application → the SDK. It takes token rotation, deadlines, transport selection and the multi-stage DIWASS document lifecycles off your hands. If you build these parts yourself, you will build them wrong twice.
  • Other language, full feature set → gRPC. The proto contract is the source from which the REST surface is also created.
  • Other language, quick start → REST/JSON. No codegen required, but not the full feature set.

REST alone is not enough for a complete integration

Some of the operations have no REST route — including the import from the inbox, i.e. the delivery path for everything that comes from outside: requests for additional information from authorities, decisions, responses. A purely REST-based integration can submit, but cannot retrieve the responses.

What exactly is missing is described under Limits of the REST path. Check this early — it is an architectural decision.

For .NET applications without the SDK

If you deliberately work in .NET without the SDK facade, you can reference the generated gRPC and Protobuf types separately:

dotnet add package Zedal.GrpcApis

The package contains only the contracts — you then have to build authentication, token rotation, deadlines and the document lifecycles yourself. Both packages follow Semantic Versioning and are published as a pair; which versions exist is listed in the Changelog.

Next