API-Aufrufe
Endpunkte und Beispiele.
Übersicht
Diese Seite beschreibt die verfügbaren API-Endpunkte für das Signatursystem. Zu jedem Endpunkt gibt es eine kurze Erklärung, die erforderlichen Eingaben, das erwartete Ergebnis sowie Beispiel-Requests und -Responses im JSON-Format.
Hinweis zu Datentypen:
- Datumsangaben als ISO-8601, z. B.
2025-12-31T23:59:59Z. - IDs und Tokens sind Strings.
Hinweis:
Die Tabellen auf der linken Seite bieten eine schnelle Feldübersicht; rechts stehen die korrespondierenden JSON‑Beispiele.
Anfragestruktur
Die anolink API ist eine REST‑Schnittstelle. Anfragen erfolgen immer über HTTPS und werden mit einem Bearer‑Token autorisiert. Nutzdaten werden als JSON übertragen.
HTTP‑Basis
- Methode:
GET,POST,PUT,PATCH,DELETE - URL:
<BASE_URL>/… - Header:
Authorization: Bearer <TOKEN>Content-Type: application/jsonAccept: application/json
Beispiel (Schema)
POST /resource HTTP/1.1
Host: <BASE_URL>
Authorization: Bearer <TOKEN>
Content-Type: application/json
Accept: application/json
{ /* JSON‑Body entsprechend der Endpunktbeschreibung */ }
Antworten
- Erfolg: Status
2xxmit JSON‑Body laut Endpunktbeschreibung - Fehler: Status
4xx/5xxmit einheitlicher Struktur
{
"error": {
"code": "invalid_request",
"message": "Feld 'patient_id' fehlt",
"details": { "field": "patient_id" }
}
}
Hinweise:
- HTTPS ist verpflichtend.
- Zeitangaben im ISO‑8601‑Format.
GETist idempotent; schreibende Aufrufe ändern Ressourcen gemäß Payload.
Signaturauftrag erstellen
POST /signature-requests – Erstellt einen neuen Signaturauftrag.
Eingabe (Body)
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
| patient_id | string | ✓ | Patienten-ID |
| document_id | string | ✓ | documents.id |
| institution_id | string | ✓ | organizations.id |
| expiration_date | string | ✓ | |
| order_by | string |
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| signing_link | string | URL zum Signaturportal |
| signature_id | string | Eindeutige Vorgangs-ID |
| expiration_date | string | Ablaufdatum (ISO-8601) |
Beispiel – Request
{
"patient_id": "pat_123",
"document_id": "doc_456",
"institution_id": "inst_789",
"expiration_date": "2025-12-31T23:59:59Z",
"order_by": "operator@example.com"
}
Beispiel – Response
{
"signing_link": "https://example.com/signatures/start?token=abc123",
"signature_id": "sig_00112233",
"expiration_date": "2025-12-31T23:59:59Z"
}
Offene Signaturlinks abrufen
GET /signature-requests?patient_id=... – Liefert offene Signaturlinks eines Patienten.
Eingabe (Query)
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
| patient_id | string | ✓ | Patienten-ID |
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| document_id | string | Dokument-ID |
| document_title | string | Titel des Dokuments |
| signing_link | string | Link zum Signieren |
| status | string | z. B. pending |
| expiration_date | string | Ablaufdatum (ISO-8601) |
Beispiel – Request
GET /signature-requests?patient_id=pat_123
Beispiel – Response
[
{
"document_id": "doc_456",
"document_title": "Einwilligungserklärung",
"signing_link": "https://example.com/signatures/start?token=def456",
"status": "pending",
"expiration_date": "2025-12-15T23:59:59Z"
}
]
Abgeschlossene Vorgänge abrufen
GET /signature-requests/completed?patient_id=... – Liefert abgeschlossene Signaturvorgänge.
Eingabe (Query)
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
| patient_id | string | ✓ | Patienten-ID |
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| signature_id | string | Vorgangs‑ID |
| signed_pdf_url | string | Download-Link zum signierten PDF |
| metadata_json_url | string | Link zu Metadaten (JSON) |
| timestamp | string | Zeitpunkt der Fertigstellung (ISO-8601) |
Beispiel – Request
GET /signature-requests/completed?patient_id=pat_123
Beispiel – Response
[
{
"signature_id": "sig_00112233",
"signed_pdf_url": "https://example.com/files/signed/sig_00112233.pdf",
"metadata_json_url": "https://example.com/files/metadata/sig_00112233.json",
"timestamp": "2025-10-01T10:30:00Z"
}
]
Zugriff auf Signaturportal prüfen
POST /signature-requests/verify-session – Prüft, ob ein Besucher über das Patientenportal zum Signaturportal weitergeleitet werden darf. Es werden ausschließlich HTTPS‑Anfragen akzeptiert. Details zum Zugriff: /docs/api/signaturportal/aufruf
Die Identifikation erfolgt über patient_id und signature_id. Zusätzlich muss ein kurzlebiges session_token übergeben werden, das serverseitig bestätigt wird.
Eingabe (Body)
| Feld | Typ | Pflicht | Hinweise |
|---|---|---|---|
| patient_id | string | ✓ | Patienten-ID |
| signature_id | string | ✓ | Vorgangs‑ID |
| session_token | string | ✓ | Kurzlebiges Session‑Token aus Ihrer Anwendung |
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| valid | boolean | Zugriff gültig? |
| redirect_url | string | Ziel‑URL (Signaturportal) bei Erfolg |
| session_token | string | Echo des gesendeten Session‑Tokens |
Beispiel – Request
{
"patient_id": "pat_123",
"signature_id": "sig_00112233",
"session_token": "sess_7f9c2e"
}
Beispiel – Response
{
"valid": true,
"redirect_url": "https://example.com/signature-portal/sig_00112233",
"session_token": "sess_7f9c2e"
}
Design für das Signaturportal festlegen
POST /design (erstellen), PUT /design (ändern) – Speichert Branding/Design-Einstellungen.
Eingabe (Body)
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
| institution_id | string | ✓ | Institutions-ID |
| logo_url | string | Logo-URL | |
| design_parameters | object | Farben, Schriften, Layout |
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| message | string | saved succesfully! |
Beispiel – Request (POST)
{
"institution_id": "inst_789",
"logo_url": "https://example.com/assets/logo.png",
"design_parameters": {
"primaryColor": "#0ea5e9",
"accentColor": "#111827",
"font": "League Spartan"
}
}
Beispiel – Response
{
"message": "saved succesfully!"
}
Dokument mit Signaturfeld anlegen
POST /documents – Legt ein Dokument an (inkl. Signaturfelddefinition).
Eingabe (Body)
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
| document_name | string | ✓ | Name des Dokuments |
| document_description | string | Beschreibung | |
| account_name | string | Account-/Mandantenname | |
| signingfield_koordinates | object/array | ✓ | Position/Größe Signaturfeld |
| document_bloburl | string | ✓ | Blob-/Speicher-URL |
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| document_name | string | Dokumentname |
| document_id | string | Generierte Dokument-ID |
| document_bloburl | string | Blob-/Speicher-URL |
Beispiel – Request
{
"document_name": "Einwilligungserklärung",
"document_description": "Standardformular zur Einwilligung",
"account_name": "praxis-dr-schmidt",
"signingfield_koordinates": { "page": 1, "x": 100, "y": 200, "width": 180, "height": 50 },
"document_bloburl": "https://storage.example.com/docs/template-123.pdf"
}
Beispiel – Response
{
"document_name": "Einwilligungserklärung",
"document_id": "doc_456",
"document_bloburl": "https://storage.example.com/docs/template-123.pdf"
}
Assignment aktualisieren (Entwurf/Aktiv)
PUT /assignments/{id} – Aktualisiert eine Zuteilung. Mit dem Status draft wird die Zuteilung beim Abfragen offener Links nicht gezeigt; mit active wieder sichtbar.
Eingabe (Body)
| Feld | Typ | Pflicht | Hinweis |
|---|---|---|---|
| id | string | ✓ | Assignment‑ID |
| status | string | ✓ | draft oder active |
| expiration_timestamp | timestamptz | optional neues Ablaufdatum | |
| assigment_url | text | optional neue Link‑URL |
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| id | string | Assignment‑ID |
| status | string | neuer Status |
| expiration_timestamp | timestamptz | aktuelles Ablaufdatum |
Beispiel – Request
{
"id": "asg_123",
"status": "draft",
"expiration_timestamp": "2026-01-31T23:59:59Z"
}
Beispiel – Response
{
"id": "asg_123",
"status": "draft",
"expiration_timestamp": "2026-01-31T23:59:59Z"
}
Dokument aktualisieren (Felddefinitionen)
PUT /documents/{id} – Ändert Felder/Metadaten eines Dokuments. Änderungen gelten für alle Zuteilungen, die noch nicht gestartet wurden; laufende/abgeschlossene Vorgänge bleiben unverändert.
Eingabe (Body)
| Feld | Typ | Pflicht | Hinweis |
|---|---|---|---|
| document_id | string | ✓ | Dokument‑ID |
| title | string | Titel des Dokuments | |
| description | string | Beschreibung | |
| fields | object | neue Felddefinitionen/Koordinaten |
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| id | string | Dokument‑ID |
| modified | boolean | true bei Erfolg |
Beispiel – Request
{
"document_id": "doc_456",
"title": "Einwilligungserklärung v2",
"fields": {
"signature": { "page": 1, "x": 120, "y": 220, "width": 180, "height": 48 }
}
}
Beispiel – Response
{
"id": "doc_456",
"modified": true
}
Dokument löschen
DELETE /documents/{id} – Löscht ein Dokument. Nur möglich, wenn keine Zuteilungen zugeordnet sind.
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| deleted | boolean | true bei Erfolg |
| reason | string | Hinweis, falls nicht löschbar |
Beispiel – Response
{
"deleted": false,
"reason": "document has assignments"
}
Verfügbarkeit eines Dokuments setzen
PATCH /documents/{id}/availability – Steuert, ob ein Dokument für neue Zuteilungen nutzbar ist: draft, active oder inactive.
Eingabe (Body)
| Feld | Typ | Pflicht | Hinweis |
|---|---|---|---|
| availability | string | ✓ | draft |
Ausgabe
| Feld | Typ | Beschreibung |
|---|---|---|
| id | string | Dokument‑ID |
| availability | string | aktueller Zustand |
Beispiel – Request
{
"availability": "inactive"
}
Beispiel – Response
{
"id": "doc_456",
"availability": "inactive"
}