SDKs¶
Ein offizielles SDK gibt es für .NET. Für alle anderen Sprachen führt der Weg über die generierten Verträge — entweder REST/JSON oder gRPC.
| Sprache | Weg | Stand |
|---|---|---|
| C# / .NET | NuGet-Paket Zedal.Sdk → .NET SDK |
verfügbar |
| jede Sprache mit HTTP-Client | Codegen aus dem OpenAPI-Dokument → REST / JSON | verfügbar, mit Einschränkungen |
| jede Sprache mit gRPC-Werkzeugkette | Codegen aus den Protos → gRPC | verfügbar |
Für weitere Sprachen ist derzeit kein SDK angekündigt.
Welchen Weg nehmen?¶
- .NET-Anwendung → das SDK. Es nimmt dir Token-Rotation, Deadlines, Transportwahl und die mehrstufigen DiWaSS-Dokument-Lebenszyklen ab. Wer diese Teile selbst baut, baut sie zweimal falsch.
- Andere Sprache, voller Funktionsumfang → gRPC. Der Proto-Vertrag ist die Quelle, aus der auch die REST-Oberfläche entsteht.
- Andere Sprache, schneller Einstieg → REST/JSON. Kein Codegen nötig, aber nicht der volle Funktionsumfang.
REST allein reicht für eine vollständige Integration nicht
Ein Teil der Operationen hat keine REST-Route — darunter der Import aus der Inbox, also der Zustellweg für alles, was von außen kommt: Behörden-Nachforderungen, Entscheidungen, Antworten. Eine rein REST-basierte Integration kann einreichen, aber die Antworten darauf nicht abholen.
Was genau fehlt, steht unter Grenzen des REST-Wegs. Prüf das früh — es ist eine Architekturentscheidung.
Für .NET-Anwendungen ohne SDK¶
Wer in .NET bewusst ohne die SDK-Fassade arbeitet, kann die generierten gRPC- und Protobuf-Typen einzeln referenzieren:
Das Paket enthält nur die Verträge — Authentifizierung, Token-Rotation, Deadlines und die Dokument-Lebenszyklen musst du dann selbst bauen. Beide Pakete folgen Semantic Versioning und werden als Paar veröffentlicht; welche Versionen es gibt, steht im Changelog.
Weiter¶
- .NET SDK — Architektur, Sessions, Transport,
DocumentHandler - Erste Schritte — Zugang und erster Aufruf, für REST und SDK
- API-Referenz — REST und gRPC im Vergleich