--- version: "v1" language: "de" --- # eStamp Dokumentation ## eStamp Dokumentation ### Documentation * #### [eStamp Glossar: Begriffe und Konzepte der Dokumentensignierung](https://documentation.moxis.co/de/estamp-dokumentation/latest/estamp-glossar-begriffe-und-konzepte-der-dokumente.md) * #### [eStamp: Aufbau, Nutzung und Authentifizierung für PDF-Signaturen](https://documentation.moxis.co/de/estamp-dokumentation/latest/estamp-aufbau-nutzung-und-authentifizierung-fur-pd.md) * #### [eStamp: Workflow-Anleitungen für das Signieren und Validieren von PDF-Dokumenten](https://documentation.moxis.co/de/estamp-dokumentation/latest/estamp-workflow-anleitungen-fur-das-signieren-und-.md) * #### [eStamp: FAQ zu Authentifizierung, Workflows, Limits und Fehlercodes](https://documentation.moxis.co/de/estamp-dokumentation/latest/estamp-faq-zu-authentifizierung-workflows-limits-u.md) * #### [eStamp: API-Referenz und Endpunkt-Katalog](https://documentation.moxis.co/de/estamp-dokumentation/latest/estamp-api-referenz-und-endpunkt-katalog.md) --- version: "v1" language: "de" --- # eStamp: API-Referenz und Endpunkt-Katalog **Inhalt** Dieses Dokument ist die vollständige technische Referenz aller eStamp REST-API-Endpoints. Es beschreibt Parameter, Rückgabewerte und Besonderheiten jedes Endpoints. Voraussetzung für alle Aufrufe: eine gültige, kundenspezifische eStamp Base URL und ein gültiger Bearer Token. Alle Endpoints verwenden den Basispfad `/signApi/...` bzw. `/xmlSignApi/...`. Für eine Einführung in Workflows und Ablauflogik siehe „eStamp: Workflow-Anleitungen für das Signieren und Validieren von PDF-Dokumenten". Ergänzend steht eine maschinenlesbare OpenAPI 3.1 Spezfikation zur Verfügung. Sie kann für automatische Client-Gnerierung, Validierung oder den Import in Tools wie Swagger UI/Postman verwendet werden. *** ** * ** *** ## Konfiguration und Discovery Diese eStamp-Endpoints liefern Informationen über die Konfiguration der aktuellen eStamp-Instanz. Sie sind der empfohlene Startpunkt für jede neue Integration. ### GET /signApi/parameterInfos **Beschreibung** Gibt die Liste aller konfigurierten Signaturhandler der eStamp-Instanz zurück. Die `parameterId`-Werte aus dieser Antwort sind Pflichtparameter bei allen Seal-Endpoints. **Request** **Authentifizierung** Bearer Token erforderlich # eStamp: Verfügbare Signaturhandler abfragen # Endpoint: GET /signApi/parameterInfos # Rückgabe: JSON-Array aller konfigurierten Signaturhandler curl -X GET "https:///signApi/parameterInfos" \ -H "Authorization: Bearer " **Request-Parameter:** keine bash curl -X GET "https:///signApi/parameterInfos" \ -H "Authorization: Bearer " **Response** **Erfolgreiche Antwort (200 OK):** [ { "parameterId": "amtssignatur", "displayName": "Amtssignatur", "maxNumberOfDocuments": 100, "signatureHandlerType": "SOFTWARE_KEY" } ] **Antwortfelder:** | **Feld** | **Typ** | **Beschreibung** | |------------------------|---------|-------------------------------------------------------------------------------------| | `parameterId` | string | Pflichtparameter für alle Seal-Aufrufe; identifiziert den Signaturhandler eindeutig | | `displayName` | string | Lesbarer Name des Signaturhandlers | | `maxNumberOfDocuments` | integer | Maximale Dokumentenanzahl pro Session für diesen Handler | | `signatureHandlerType` | string | Technischer Typ des Signaturhandlers (z. B. `SOFTWARE_KEY`) | > \[!NOTE\] Die aufgelisteten `parameterId`-Werte sind instanzspezifisch. Es werden ausschließlich jene Parameter aufgelistet, die in der Konfiguration der eStamp-Instanz hinterlegt sind. Deprecated Parameter werden nicht gesondert markiert. ### GET /signApi/signatureAppearanceInfos **Beschreibung** Gibt das Mapping aller serverseitig hinterlegten Appearance-IDs auf ihre `signatureAppearance`-Konfiguration zurück. Dieser Endpoint wird verwendet, um verfügbare `appearanceId`-Werte für die Endpoints `sealSingleWithAppearanceParam` und `addDocumentWithAppearanceParam` abzufragen. **Request** **Authentifizierung:** Bearer Token erforderlich # eStamp: Verfügbare Appearance-Konfigurationen abfragen # Endpoint: GET /signApi/signatureAppearanceInfos # Rückgabe: JSON-Mapping von Appearance-IDs auf signatureAppearance-Konfigurationen curl -X GET "https:///signApi/signatureAppearanceInfos" \ -H "Authorization: Bearer " > \[!NOTE\] Serverseitige Appearance-Konfigurationen werden in der eStamp-Instanz als YAML hinterlegt und referenzieren JSON-Konfigurationsdateien. Die Verwaltung erfolgt durch das XiTrust Support Team beim Deployment. **Response** **Erfolgreiche Antwort (200 OK):** JSON-Mapping von Appearance IDs auf signatureAppearance Konfigurationen. { "appearance1": { "signatureImageId": "amtsSignatur", "signaturePageId": "default", "lastPage": -1, "onEveryPage": false, "x": 100, "y": 100, "width": 400, "height": 270 }, "appearance2": { "signatureImageId": "imageOnly", "signatureFieldId": "Signatur2" } } > \[!NOTE\] Serverseitige Appearance-Konfigurationen werden in der eStamp-Instanz als YAML hinterlegt und referenzieren JSON-Konfigurationsdateien. Die Verwaltung erfolgt durch das XiTrust Support Team beim Deployment. ### GET /signApi/paraphenInfos **Beschreibung** Gibt das Mapping aller serverseitig hinterlegten Paraphen-IDs auf ihre `ParaphenAppearance`-Konfiguration zurück. Dieser Endpoint wird verwendet, um verfügbare `paraphImageId`- und `paraphenAppearanceId`-Werte abzufragen. **Request** **Authentifizierung:** Bearer Token erforderlich # eStamp: Verfügbare Paraphen-Konfigurationen abfragen # Endpoint: GET /signApi/paraphenInfos # Rückgabe: JSON-Mapping von Paraphen-IDs auf ParaphenAppearance-Konfigurationen curl -X GET "https:///signApi/paraphenInfos" \ -H "Authorization: Bearer " **Erfolgreiche Antwort (200 OK):** JSON-Mapping von Paraphen IDs auf ParaphenAppearance-Konfigurationen { "paraphen1": { "paraphImageId": "picture1", "x": 10, "y": 800, "width": 50, "height": 22 }, "paraphen2": { "paraphImageId": "picture2", "x": 20, "y": 750, "width": 50, "height": 22 } } *** ** * ** *** ## Synchrone Seal-Endpoints (Single Document) Die synchronen eStamp-Seal-Endpoints versiegeln ein einzelnes PDF-Dokument pro Aufruf und geben das signierte Dokument direkt als Binary zurück. Es sind keine Sessions erforderlich. ### POST /signApi/sealSingle **Beschreibung** Versiegelt ein einzelnes PDF-Dokument ohne Signaturvisualisierung (siehe *Abbildung 1*). Der einfachste eStamp-Seal-Endpoint. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: PDF versiegeln ohne Visualisierung # Endpoint: POST /signApi/sealSingle # Rückgabe: signiertes PDF als Binary curl -X POST "https:///signApi/sealSingle" \ -H "Authorization: Bearer " \ -H "accept: application/pdf" \ -F "parameterId=amtssignatur" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf **Request-Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |------------------|--------------|-------------|----------------------------------------------------------------------------------------| | `parameterId` | string | Ja | ID des Signaturhandlers; verfügbare Werte via `GET /signApi/parameterInfos` | | `documentToSign` | binary (PDF) | Ja | Das zu versiegelnde PDF-Dokument | | `paraphenImage` | JSON | Nein | Paraphen-Konfiguration; wird auf definierten Seiten als kleines Signaturbild platziert | **Response** **Erfolgreiche Antwort (200 OK):** Signiertes PDF als Binary (`application/pdf`); Dateiname im Response-Header (Content-Disposition). [Sig_OhneVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_b285948128694970d92466b9288ff60541c51b68f5574ad0d53398b1989d6476/Sig_OhneVisualisierung.pdf.md?cb=d9b514367de89d9984a125969a7976d4) *Abbildung 1: Ergebnis ist ein PDF-Dokument ohne visuelle Signaturdarstellung* *(mit einem Klick auf die Datei können Sie sich das Ergebnis anzeigen lassen)* ### POST /signApi/sealSingleWithAppearance **Beschreibung** Versiegelt ein einzelnes PDF-Dokument und fügt eine visuelle Signaturdarstellung ein. Die `signatureAppearance`-Konfiguration wird als JSON-Datei im Request mitgesendet. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: PDF versiegeln mit Signaturvisualisierung (Appearance als JSON-Datei) # Endpoint: POST /signApi/sealSingleWithAppearance # Rückgabe: signiertes PDF mit Visualisierung als Binary curl -X POST "https:///signApi/sealSingleWithAppearance" \ -H "Authorization: Bearer " \ -H "accept: application/pdf" \ -F "parameterId=amtssignatur" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ -F "signatureAppearance=@./appearance.json;type=application/json" \ --output ./signiert.pdf **Request-Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |-----------------------|--------------|-------------|--------------------------------------------------------------------------| | `parameterId` | string | Ja | ID des Signaturhandlers | | `documentToSign` | binary (PDF) | Ja | Das zu versiegelnde PDF-Dokument | | `signatureAppearance` | JSON-Datei | Ja | Konfiguration der Signaturvisualisierung (Position, Größe, Signaturbild) | | `paraphenImage` | JSON | Nein | Paraphen-Konfiguration | **Response** **Erfolgreiche Antwort (200 OK):** Signiertes PDF mit Visualisierung als Binary (`application/pdf`); Dateiname im Response-Header. [Sig_MitVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_2e545a6f6c0b55a39045aaa1fa2138f2eb9b6f4facba1e40f0ee1f4fdcbfbb69/Sig_MitVisualisierung.pdf.md?cb=b35ae91c35846c67bd3f6af0f51b5ee3) *Abbildung 2: Ergebnis ist ein PDF-Dokument mit einer visuellen Signaturdarstellung* *(mit einem Klick auf die Datei können Sie sich das Ergebnis anzeigen lassen)* ### POST /signApi/sealSingleWithAppearanceParam **Beschreibung** Versiegelt ein einzelnes PDF-Dokument mit einer serverseitig hinterlegten Visualisierungskonfiguration (siehe *Abbildung 3* ). Statt einer JSON-Datei wird die `appearanceId` als Query-Parameter übergeben. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: PDF versiegeln mit serverseitiger Appearance-ID # Endpoint: POST /signApi/sealSingleWithAppearanceParam # appearanceId: Query-Parameter (serverseitig konfiguriert) # Rückgabe: signiertes PDF als Binary curl -X POST "https:///signApi/sealSingleWithAppearanceParam?appearanceId=" \ -H "Authorization: Bearer " \ -H "accept: application/pdf" \ -F "parameterId=amtssignatur" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf **Request-Parameter:** | **Parameter** | **Übergabe** | **Pflicht** | **Beschreibung** | |------------------------|-------------------|-------------|-----------------------------------------------------------| | `appearanceId` | Query-Parameter | Ja | ID der serverseitig hinterlegten Appearance-Konfiguration | | `parameterId` | Form-Feld | Ja | ID des Signaturhandlers | | `documentToSign` | Form-Feld, binary | Ja | Das zu versiegelnde PDF-Dokument | | `paraphenAppearanceId` | Query-Parameter | Nein | ID der serverseitig hinterlegten Paraphen-Konfiguration | **Response** **Erfolgreiche Antwort (200 OK):** Signiertes PDF mit Visualisierung als Binary (`application/pdf`) [Sig_MitVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_2e545a6f6c0b55a39045aaa1fa2138f2eb9b6f4facba1e40f0ee1f4fdcbfbb69/Sig_MitVisualisierung.pdf.md?cb=b35ae91c35846c67bd3f6af0f51b5ee3) [Sig_MitVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_2e545a6f6c0b55a39045aaa1fa2138f2eb9b6f4facba1e40f0ee1f4fdcbfbb69/Sig_MitVisualisierung.pdf.md?cb=b35ae91c35846c67bd3f6af0f51b5ee3) *Abbildung 3: Ergebnis ist ein PDF-Dokument mit einer visuellen Signaturdarstellung* *(mit einem Klick auf die Datei können Sie sich das Ergebnis anzeigen lassen)* *** ** * ** *** ## Session-basierte Seal-Endpoints (Batch) Die session-basierten eStamp-Endpoints verarbeiten mehrere Dokumente in einer mehrstufigen Session. Die Reihenfolge der Aufrufe ist zwingend einzuhalten: `startSession` → `addDocument` → `seal` → `getDocument` → `closeSession`. ### POST /signApi/startSession Startet eine neue eStamp-Batch-Signing-Session und gibt die `sessionId` zurück, die bei allen Folgeaufrufen als Pfadparameter verwendet wird. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: Batch-Signing-Session starten # Endpoint: POST /signApi/startSession # Rückgabe: sessionId als JSON-String curl -X POST "https:///signApi/startSession" \ -H "Authorization: Bearer " \ -F "parameterId=amtssignatur" **Response** **Erfolgreiche Antwort (200 OK):** JSON-String mit der `sessionId` "a1b2c3d4-e5f6-7890-abcd-ef1234567890" **Request-Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |---------------|---------|-------------|-----------------------------------------------------------| | `parameterId` | string | Ja | ID des Signaturhandlers für alle Dokumente dieser Session | **Fehlercodes:** | **Code** | **Fehlermeldung** | **Ursache** | |----------|--------------------------|---------------------------------------------------------------------------| | 404 | `Parameter id not found` | Angegebene `parameterId` existiert nicht in der eStamp-Instanz | | 404 | `No trust center found` | Kein passender Trust-Center-Dienst konfiguriert (z. B. Swisscom, A-Trust) | > \[!NOTE\] Fehlerantworten werden derzeit als reiner Text im Response-Body zurückgegeben, nicht als strukturiertes JSON. ### POST /signApi/{sessionId}/addDocument **Beschreibung** Fügt ein Dokument zur bestehenden eStamp-Session hinzu. Gibt eine `documentId` zurück, die für `getDocument` benötigt wird. Kann bis zu 100 Mal pro Session aufgerufen werden. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: Dokument zur Session hinzufügen # Endpoint: POST /signApi/{sessionId}/addDocument # Rückgabe: documentId als Integer curl -X POST "https:///signApi//addDocument" \ -H "Authorization: Bearer " \ -F "documentToSign=@./dokument.pdf;type=application/pdf" **Pfadparameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |---------------|---------------|-------------|--------------------------------------------------| | `sessionId` | string (UUID) | Ja | Gültige Session-ID aus POST/signApi/startSession | **Request-Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |------------------|--------------|-------------|--------------------------------------------| | `documentToSign` | binary (PDF) | Ja | Das hinzuzufügende PDF-Dokument | | `paraphenImage` | JSON | Nein | Paraphen-Konfiguration für dieses Dokument | **Response** **Erfolgreiche Antwort (200 OK):** `documentId` als Integer (JSON) 1 **Antwortfelder:** | **Feld** | **Typ** | **Beschreibung** | |----------|---------|----------------------------------------------------------------------| | (Body) | integer | Die documentId des hinzugefügten Dokuments. | | | (JSON) | Abruf via GET/signApi/{sessionId}/getDocument/{documentId} benötigt. | **Fehlercodes:** | **Code** | **Fehlermeldung** | **Ursache** | |----------|--------------------------------------|------------------------------------------------------------| | 412 | `Illegal session id` | Ungültige oder abgelaufene `sessionId` | | 400 | `Illegal operation in current state` | Falscher Session-Zustand (z. B. `addDocument` nach `seal`) | | 400 | `Cannot load PDF Document` | Dokument ist kein gültiges PDF | | 429 | `Document limit reached` | 100-Dokumente-Limit der Session erreicht | | 400 | `Error adding signature page` | Fehler beim Hinzufügen einer Signaturseite | | 406 | `Failed to render image` | Signaturbild konnte nicht gerendert werden | > \[!NOTE\] Einmal zur Session hinzugefügte Dokumente können nicht entfernt oder ersetzt werden. Bei einem fehlerhaft hinzugefügten Dokument muss eine neue Session über `POST /signApi/startSession` gestartet werden. > > Verhalten bei fehlgeschlagenem addDocument (HTTP ist nicht 200): > > > Bei einem Fehlerfall bleibt die Session grundsätzlich offen und weiterhin verwendbar. Das fehlgeschlagene Dokument wird nicht zur Session hinzugefügt. Der Client kann entweder: > > * die Session mit anderen Dokumenten fortsetzen oder > > * die Session explizit über POST/signApi/{sessionId}/closeSession schließen, um Ressourcen sofort freizugeben. > > Eine Ausnahme bildet HTTP 412 (Illegal session id): In diesem Fall existiert die Session serverseitig bereits nicht mehr (z. B. wegen Ablauf nach 40 Minuten). Ein closeSession-Aufruf ist dann nicht mehr nötig; der Client muss eine neue Session über startSession starten. ### POST /signApi/{sessionId}/addDocumentWithAppearance **Beschreibung** Fügt ein Dokument mit einer `signatureAppearance`-Konfiguration zur eStamp-Session hinzu. Die Visualisierungskonfiguration wird als JSON-Datei übergeben. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: Dokument mit Appearance-Konfiguration zur Session hinzufügen # Endpoint: POST /signApi/{sessionId}/addDocumentWithAppearance curl -X POST "https:///signApi//addDocumentWithAppearance" \ -H "Authorization: Bearer " \ -F "documentToSign=@./dokument.pdf;type=application/pdf" \ -F "signatureAppearance=@./appearance.json;type=application/json" **Request-Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |-----------------------|--------------|-------------|--------------------------------------------| | `documentToSign` | binary (PDF) | Ja | Das hinzuzufügende PDF-Dokument | | `signatureAppearance` | JSON-Datei | Ja | Konfiguration der Signaturvisualisierung | | `paraphenImage` | JSON | Nein | Paraphen-Konfiguration für dieses Dokument | **Response** **Erfolgreiche Antwort (200 OK):** JSON-Antwort mit einem Integer-Wert (`documentId`) 2 ### POST /signApi/{sessionId}/addDocumentWithAppearanceParam **Beschreibung** Fügt ein Dokument mit einer serverseitig hinterlegten Appearance-ID zur eStamp-Session hinzu. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: Dokument mit serverseitiger Appearance-ID zur Session hinzufügen # Endpoint: POST /signApi/{sessionId}/addDocumentWithAppearanceParam curl -X POST "https:///signApi//addDocumentWithAppearanceParam?appearanceId=" \ -H "Authorization: Bearer " \ -F "documentToSign=@./dokument.pdf;type=application/pdf" **Request-Parameter:** | **Parameter** | **Übergabe** | **Pflicht** | **Beschreibung** | |------------------------|-------------------|-------------|-----------------------------------------------------------| | `appearanceId` | Query-Parameter | Ja | ID der serverseitig hinterlegten Appearance-Konfiguration | | `documentToSign` | Form-Feld, binary | Ja | Das hinzuzufügende PDF-Dokument | | `paraphenAppearanceId` | Query-Parameter | Nein | ID der serverseitig hinterlegten Paraphen-Konfiguration | **Response** **Erfolgreiche Antwort (200 OK):** JSON-Antwort mit einem Integer-Wert (`documentId`) **Fehlercodes:** | **Code** | **Fehlermeldung** | **Ursache** | |----------|-----------------------------------------|---------------------------------------------------| | 404 | `Cannot find paraphen appearance by id` | Angegebene `paraphenAppearanceId` existiert nicht | ### POST /signApi/{sessionId}/seal **Beschreibung** Löst die Signierung aller zur eStamp-Session hinzugefügten Dokumente aus. Der Aufruf blockiert, bis alle Dokumente signiert sind (maximal 60--120 Sekunden bei größeren Batches). Eine asynchrone Variante existiert nicht; die eStamp-Architektur ist bereits synchron ausgelegt. Für Integrationen, deren Infrastruktur (Proxy, API-Gateway, Firewall) Timeouts unter 60 Sekunden erzwingt, empfiehlt sich die Aufteilung in kleinere Batches (z. B. mehrere parallele Sessions mit wenigen Dokumenten pro Session) statt einer einzigen großen Session. Die Batch-Größe pro Session kann bis auf ein Dokument reduziert werden; in diesem Fall verhält sich die Session-Variante vergleichbar zu sealSingle und bleibt innerhalb üblicher Proxy-Timeouts. Gibt keinen Body zurück. **Request** **Authentifizierung:** Bearer Token erforderlich # eStamp: Alle Dokumente der Session versiegeln # Endpoint: POST /signApi/{sessionId}/seal # Rückgabe: kein Body (leere 200-Antwort bei Erfolg) curl -X POST "https:///signApi//seal" \ -H "Authorization: Bearer " **Response** **Erfolgreiche Antwort (200 OK):** Kein Body (leere 200-Antwort) > \[!NOTE\] Aus der Sicht der HTTP-Semantik wäre ein `204 No Content`bei leerem Body üblich. Aktuell gibt eStamp `200 OK` mit leerem Body zurück. Der STatuscode ist zur Zeit geplant als 200 dokumentiert. **Fehlercodes:** | **Code** | **Fehlermeldung** | **Ursache** | |----------|-----------------------------------|------------------------------------------------------| | 406 | `An error occurred while sealing` | Allgemeiner Signierfehler (z. B. Zertifikatsproblem) | | 500 | `Could not write data to CSV` | Interner Systemfehler beim Logging | > \[!WARNING\] `getDocument` darf erst nach erfolgreichem `seal`-Aufruf aufgerufen werden. Ein `getDocument`-Aufruf vor `seal` gibt `404 Not Found` zurück. ### GET /signApi/{sessionId}/getDocument/{documentId} **Beschreibung** Ruft ein einzelnes signiertes Dokument aus der eStamp-Session ab. Muss für jede `documentId` separat aufgerufen werden (siehe *Abbildung 4*). **Authentifizierung:** Bearer Token erforderlich # eStamp: Signiertes Dokument aus Session abrufen # Endpoint: GET /signApi/{sessionId}/getDocument/{documentId} # Rückgabe: signiertes PDF als Binary curl -X GET "https:///signApi//getDocument/" \ -H "Authorization: Bearer " \ --output ./signiert-dokument.pdf **Pfadparameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |---------------|---------------|-------------|-----------------------------------------------------------------------| | `sessionId` | string (UUID) | Ja | Gültige `sessionId` aus `Post/signApi/startSession` | | `documentId` | integer | Ja | ID des signierten Dokuments aus `POST/signApi/{sessionId}addDocument` | **Response** **Erfolgreiche Antwort (200 OK):** Signiertes PDF als Binary (`application/pdf`); Dateiname im Response-Header (Content-Disposition). Der Response-Body enthält ausschließlich die PDF-Binärdaten. Es wird kein JSON und kein Multipart-Reponse zurückgegeben. json ``` ``` [Sig_OhneVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_b285948128694970d92466b9288ff60541c51b68f5574ad0d53398b1989d6476/Sig_OhneVisualisierung.pdf.md?cb=d9b514367de89d9984a125969a7976d4) [Sig_MitVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_2e545a6f6c0b55a39045aaa1fa2138f2eb9b6f4facba1e40f0ee1f4fdcbfbb69/Sig_MitVisualisierung.pdf.md?cb=b35ae91c35846c67bd3f6af0f51b5ee3) *Abbildung 4: Ergebnis ist je nachdem, was abgerufen wird, entweder ein PDF-Dokument mit einer visuellen Signaturdarstellung oder ohne. (mit einem Klick auf die Dateien können Sie sich das Ergebnis anzeigen lassen)* **Fehlercodes:** | **Code** | **Fehlermeldung** | **Ursache** | |----------|-----------------------------|-----------------------------------------------------------------| | 404 | `Document for id not found` | Ungültige `documentId` oder `getDocument` vor `seal` aufgerufen | ### POST /signApi/{sessionId}/closeSession **Beschreibung** Beendet eine eStamp-Batch-Signing-Session und gibt alle zugehörigen Ressourcen frei. Gibt keinen Body zurück. **Request** **Authentifizierung:** Bearer Token erforderlich # eStamp: Batch-Signing-Session schließen # Endpoint: POST /signApi/{sessionId}/closeSession # Rückgabe: kein Body curl -X POST "https:///signApi//closeSession" \ -H "Authorization: Bearer " Der Endpoint erwartet keine Request-Parameter über den Pfadparameter sessionId hinaus. **Response** **Erfolgreiche Antwort (200 OK):**Kein Body > \[!NOTE\] Nicht manuell geschlossene eStamp-Sessions werden nach **40 Minuten** automatisch bereinigt. Das manuelle Schließen über `closeSession` ist dennoch empfohlen, um Ressourcen sofort freizugeben *** ** * ** *** ## Signaturfeld-Endpoints ### POST /signApi/signatureFieldNames **Beschreibung** Gibt die IDs aller vorhandenen Signaturfelder eines PDF-Dokuments zurück. Wird verwendet, um `signatureFieldId`-Werte für die `signatureAppearance`-Konfiguration zu ermitteln. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: Signaturfeld-IDs eines PDFs abfragen # Endpoint: POST /signApi/signatureFieldNames # Rückgabe: JSON-Array der Signaturfeld-IDs im Dokument curl -X POST "https:///signApi/signatureFieldNames" \ -H "Authorization: Bearer " \ -F "document=@./eingabe.pdf;type=application/pdf" **Request-Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |---------------|--------------|-------------|-----------------------------------------------------------------| | `document` | binary (PDF) | Ja | Das PDF-Dokument, dessen Signaturfelder abgefragt werden sollen | **Response** **Erfolgreiche Antwort (200 OK):** JSON-Array der Signaturfeld-IDs im Dokument. ["Signatur1", "Signatur2", "Signatur3"] Die zurückgegebenen Werte können direkt als `signatureFieldId` in der `signatureAppearance`-Konfiguration verwendet werden. Wenn `signatureFieldId` gesetzt ist, werden `x`, `y`, `width`, `height`, `firstPage`, `lastPage` und `onEveryPage` nicht benötigt. *** ** * ** *** ## Validierungs-Endpoints ### POST /signApi/validatePdf **Beschreibung** Validiert die Signatur eines bestehenden PDF-Dokuments und gibt einen Validierungsreport zurück. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: PDF-Signatur validieren # Endpoint: POST /signApi/validatePdf # Rückgabe: Validierungsreport als XML oder PDF Binary curl -X POST "https:///signApi/validatePdf" \ -H "Authorization: Bearer " \ -F "reportType=xml" \ -F "documentToSign=@./signiert.pdf;type=application/pdf" \ --output ./validierungsreport.xml **Request-Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Standardwert** | **Beschreibung** | |------------------|--------------|-------------|------------------|--------------------------------------------------| | `documentToSign` | binary (PDF) | Ja | -- | Das zu validierende PDF-Dokument | | `reportType` | string | Nein | `xml` | Format des Validierungsreports: `xml` oder `pdf` | **Response** **Erfolgreiche Antwort (200 OK):** Validierungsreport als XML (application/xml) oder PDF (application/pdf) Binary; Dateiname im Response-Header. Beispiel bei reportType=pdf: [xmlReport.pdf](https://documentation.moxis.co/__attachments/a_00fda286703fd9bf7a511b4ec3c95ab04890307e48717d812ae75196993f5188/xmlReport.pdf.md?cb=3aa10df0a2c5e71a08d7de31ffe42b53) ### POST /xmlSignApi/validateXml **Beschreibung** Validiert die Signatur eines bestehenden XML-Dokuments und gibt einen Validierungsreport zurück. **Request** **Authentifizierung:** Bearer Token erforderlich **Content-Type:** `multipart/form-data` # eStamp: XML-Signatur validieren # Endpoint: POST /xmlSignApi/validateXml # reportType: "xml" (Standard) oder "pdf" # Rückgabe: Validierungsreport als XML oder PDF Binary curl -X POST "https:///xmlSignApi/validateXml" \ -H "Authorization: Bearer " \ -F "reportType=pdf" \ -F "documentToSign=@./signiert.xml" \ --output ./validierungsreport.pdf **Request-Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Standardwert** | **Beschreibung** | |------------------|--------------|-------------|------------------|--------------------------------------------------| | `documentToSign` | binary (XML) | Ja | -- | Das zu validierende XML-Dokument | | `reportType` | string | Nein | `xml` | Format des Validierungsreports: `xml` oder `pdf` | **Response** **Erfolgreiche Antwort (200 OK):**Validierungsreport als XML oder PDF Binary. Beispiel bei reportType=xml: [xmlReport.xml](https://documentation.moxis.co/__attachments/a_38158eedec3817257934718a54900ffe69b9bcc3f3fd3a8fc3969ff42d941570/xmlReport.xml.md?cb=12e13933e1f2e10663886564ac388c3a) *** ** * ** *** ## signatureAppearance: vollständige Feldreferenz Die `signatureAppearance`-Konfiguration steuert die visuelle Darstellung der Signatur im PDF. Sie wird immer im JSON-Format übergeben --- entweder als Datei oder als serverseitig hinterlegte Konfiguration (referenziert über `appearanceId`). ### Pflichtfelder | **Feld** | **Typ** | **Beschreibung** | |--------------------|---------|----------------------------------------------------------------| | `signatureImageId` | string | ID des serverseitig hinterlegten Signaturbilds | | `lastPage` | integer | Letzte Seite mit Signatur; `-1` = letzte Dokumentseite | | `onEveryPage` | boolean | `true`: Signatur auf jeder Seite im Bereich; `false`: einmalig | | `x` | integer | Horizontale Position in pt | | `y` | integer | Vertikale Position in pt | ### Optionale Felder | **Feld** | **Typ** | **Standardwert** | **Beschreibung** | |---------------------------|---------|------------------|-------------------------------------------------------------------------------------| | `firstPage` | integer | -- | Erste Seite mit Signatur; zusammen mit `lastPage` ergibt sich der Signaturbereich | | `width` | integer | 400 | Breite der Visualisierung in pt | | `height` | integer | 270 | Höhe der Visualisierung in pt | | `signaturePageId` | string | -- | ID einer zusätzlichen Signaturseite, die ans Dokument angehängt wird | | `signatureFieldId` | string | -- | ID eines vorhandenen PDF-Signaturfelds; ersetzt alle Koordinaten- und Seitenangaben | | `signatureAttributes` | object | -- | Zusätzliche X.509-Zertifikatsattribute für die Darstellung (nur bei Amtssignaturen) | | `visualizationAutomation` | object | -- | Automatische Positionierung am Ende des letzten Textzeichens | ### Unterstützte signatureAttributes (X.509) | **Schlüssel** | **Angezeigte Information** | |------------------------------------|-------------------------------------------------| | `subjectDn` | Zertifikatsinhaber (Subject Distinguished Name) | | `issuerDn` | Zertifikatsaussteller | | `notBefore` | Gültig ab (Erstellungsdatum) | | `notAfter` | Gültig bis (Ablaufdatum) | | `serialNumber` | Seriennummer des Zertifikats | | `sigAlgName` | Signaturalgorithmus | | `sigAlgOID` | OID des Signaturalgorithmus | | `version` | Zertifikatsversion | | `type` | Zertifikatstyp | | `signatureDate?datetime?iso_utc` | Signierdatum (UTC, ISO-Format) | | `signatureDate?datetime?iso_local` | Signierdatum (Lokalzeit, ISO-Format) | > \[!NOTE\] Der linke Wert (z. B. `subjectDn`) ist der technisch fixe Schlüssel. Der rechte Wert (z. B. `"Subject"`) ist der frei wählbare Anzeigetext in der Visualisierung. > \[!WARNING\] Folgende Feldkombinationen in der `signatureAppearance` sind **nicht unterstützt** und führen zu Fehlern: `signaturePageId` zusammen mit `onEveryPage: true` (`400 Bad Request`), und `visualizationAutomation` zusammen mit `signatureAttributes` (nicht unterstützte Kombination). ### visualizationAutomation: Pflichtfelder Wenn `visualizationAutomation` gesetzt ist, positioniert eStamp die Signaturvisualisierung automatisch am Ende des letzten Textzeichens der letzten Seite. Folgende drei Felder sind innerhalb des `visualizationAutomation`-Blocks Pflicht: | **Feld** | **Typ** | **Beschreibung** | |-----------------------|---------|---------------------------------------------------------------------| | `footerHeight` | integer | Höhe der Fußzeile in pt | | `margin` | integer | Abstand zwischen letztem Textzeichen und Signaturbild in pt | | `signaturePageMargin` | integer | Abstand zur Signaturseite, wenn eine neue Seite erzeugt wird, in pt | > \[!WARNING\] Bei Verwendung von `visualizationAutomation` muss `signaturePageId` auf einen gültigen Wert gesetzt sein. `signatureAttributes` darf nicht gleichzeitig gesetzt werden. ## paraphenImage: Feldreferenz Die Paraphen-Konfiguration steuert die Darstellung eines kleinen Signaturbilds (Paraphe) auf definierten Seiten des Dokuments. Sie wird als optionaler JSON-Parameter bei Seal-Endpoints übergeben. ### Pflichtfelder | **Feld** | **Typ** | **Beschreibung** | |-----------------|---------|------------------------------------------------| | `paraphImageId` | string | ID des serverseitig hinterlegten Paraphenbilds | | `width` | integer | Breite der Paraphe in pt | | `height` | integer | Höhe der Paraphe in pt | | `x` | integer | Horizontale Position der Paraphe in pt | | `y` | integer | Vertikale Position der Paraphe in pt | **Beispielkonfiguration:** { "paraphImageId": "picture1", "width": 50, "height": 22, "x": 10, "y": 800 } ## Endpunkt-Übersicht Alle eStamp REST-API-Endpoints auf einen Blick: | **Methode** | **Endpoint** | **Beschreibung** | |-------------|-------------------------------------------------------|---------------------------------------------------| | GET | `/signApi/parameterInfos` | Verfügbare Signaturhandler abfragen | | GET | `/signApi/signatureAppearanceInfos` | Serverseitige Appearance-Konfigurationen abfragen | | GET | `/signApi/paraphenInfos` | Serverseitige Paraphen-Konfigurationen abfragen | | POST | `/signApi/sealSingle` | Einzelnes PDF versiegeln (ohne Visualisierung) | | POST | `/signApi/sealSingleWithAppearance` | Einzelnes PDF versiegeln (Appearance als Datei) | | POST | `/signApi/sealSingleWithAppearanceParam` | Einzelnes PDF versiegeln (Appearance als ID) | | POST | `/signApi/startSession` | Batch-Session starten | | POST | `/signApi/{sessionId}/addDocument` | Dokument zur Session hinzufügen | | POST | `/signApi/{sessionId}/addDocumentWithAppearance` | Dokument mit Appearance-Datei hinzufügen | | POST | `/signApi/{sessionId}/addDocumentWithAppearanceParam` | Dokument mit Appearance-ID hinzufügen | | POST | `/signApi/{sessionId}/seal` | Alle Session-Dokumente versiegeln | | GET | `/signApi/{sessionId}/getDocument/{documentId}` | Signiertes Dokument abrufen | | POST | `/signApi/{sessionId}/closeSession` | Session schließen | | POST | `/signApi/signatureFieldNames` | Signaturfeld-IDs eines PDFs abfragen | | POST | `/signApi/validatePdf` | PDF-Signatur validieren | | POST | `/xmlSignApi/validateXml` | XML-Signatur validieren | --- version: "v1" language: "de" --- # eStamp: Aufbau, Nutzung und Authentifizierung für PDF-Signaturen **Inhalt** eStamp ist ein Service von XiTrust zum automatischen Signieren und Siegeln von Dokumenten über eine REST-API oder einen Webclient. Dieses Dokument beschreibt Grundkonzepte, Deployment-Varianten, Authentifizierungsmethoden und einen Quickstart für neue Integrations-Teams. *** ** * ** *** ## Was ist eStamp? eStamp ist ein Dienst, der PDF-Dokumente (und XML-Dateien) automatisiert signiert oder versiegelt. Der Ablauf ist dabei immer gleich: 1. Das aufrufende System sendet ein Dokument an die eStamp REST-API. 2. eStamp signiert oder versiegelt das Dokument mit dem konfigurierten Zertifikat. 3. Das signierte Dokument wird direkt als Antwort zurückgegeben. eStamp ist für Organisationen konzipiert, die viele Dokumente automatisiert und rechtskonform signieren müssen -- ohne manuelle Eingriffe. Typische Anwendungsbereiche sind Behörden (Bescheide, Amtssignaturen), Versicherungen (Polizzen, Bestätigungen) und Finanzdienstleister (automatisch generierte Vertragsdokumente). ## Deployment-Varianten von eStamp eStamp kann auf zwei Arten betrieben werden. Die Wahl der Variante beeinflusst, wer für Betrieb und Updates zuständig ist. **Cloud-Variante (empfohlen):** eStamp wird durch XiTrust als Teil der MOXIS-Plattform gehostet. Das Deployment wird durch das XiTrust Support Team durchgeführt. Es wird kein eigener Server benötigt. **On-Premises:** eStamp wird in der eigenen IT-Infrastruktur des Kunden installiert und betrieben. Installation und laufender Betrieb liegen beim Kunden-Team. In beiden Varianten gilt: Jede eStamp-Instanz erhält eine eigene, kundenspezifische **Base URL** (z. B. `https://pbss.kunde.xitrust.cloud/pbss`). Diese URL wird beim Deployment festgelegt und ist Voraussetzung für jeden API-Aufruf. > \[!NOTE\] eStamp kennt **kein Mandantenmodell** . Unterschiedliche Konfigurationen (z. B. verschiedene Zertifikate oder Signaturtypen) werden über **Signaturhandler** innerhalb einer Instanz abgebildet. Für eine vollständige technische Trennung zwischen Organisationseinheiten wird eine separate eStamp-Instanz empfohlen. ## eStamp Base URL Die eStamp Base URL ist die kundenspezifische Webadresse, über die eine eStamp-Instanz erreichbar ist. Alle API-Aufrufe verwenden diese URL als Basis. **Format:** https://pbss..xitrust.cloud/pbss **Beispiel:** https://pbss.acc.xitrust.cloud/pbss Die Base URL wird beim Deployment festgelegt und vom XiTrust Support Team kommuniziert. Ohne korrekte Base URL schlagen alle API-Aufrufe mit einem `404 Not Found`-Fehler fehl. > \[!WARNING\] Die eStamp Base URL ist **kundenspezifisch und individuell** . Eine falsche oder allgemeine URL führt zu `404`-Fehlern. Wenn ein eStamp-Service nicht erreichbar ist, ist die Base URL der erste zu prüfende Punkt. ## Authentifizierung und Zugriffsschutz Die eStamp REST-API ist an sich abgesichtert. **Bitte beachten Sie:**ab Version 4.54 wird der licenceInfos GET Call ohne Authentifizierung ausgeführt. Ohne gültige Authentifizierung werden jedoch keine API-Aufrufe akzeptiert -- weder Signieroperationen noch Session-Management. eStamp unterstützt zwei Authentifizierungsmethoden: **OAuth 2.0 (empfohlen):** Moderne, token-basierte Authentifizierung mit dem Grant Type „Client Credentials". Eine Maschine bzw. ein System authentifiziert sich -- kein menschlicher Benutzer. OAuth 2.0 ist die empfohlene Methode für alle neuen Integrationen. **Basic Authorization:** Klassische Authentifizierung mit Benutzername und Passwort als HTTP-Header. Weniger empfohlen als OAuth 2.0. > \[!NOTE\] eStamp verwendet **keine RBAC, keine User-Rollen und keine unterschiedlichen Berechtigungsstufen**. Jeder gültig authentifizierte Client kann alle geschützten Endpoints verwenden. Die einzige Ausnahme sind Lizenzinformations-Endpoints, die ungeschützt erreichbar sind. ## OAuth 2.0 in eStamp: Konfiguration und Ablauf eStamp verwendet OAuth 2.0 mit dem Grant Type „Client Credentials". Dieser Ablauf ist speziell für Maschine-zu-Maschine-Kommunikation ausgelegt. ### Benötigte OAuth-2.0-Konfigurationswerte Folgende fünf Werte sind für die OAuth-2.0-Authentifizierung gegen eStamp verpflichtend. Alle werden beim Deployment vom XiTrust Support Team festgelegt und kommuniziert: | **Wert** | **Beschreibung** | |-------------------|-------------------------------------------------------------------------------------------------| | `client_id` | Der „Benutzername" der Anwendung beim Authentifizierungsserver | | `client_secret` | Das „Passwort" der Anwendung -- nur Anwendung und Auth-Server kennen diesen Wert | | `issuer-uri` | Die „Heimatadresse" des Identity Providers (z. B. Keycloak), identifiziert den Token-Aussteller | | `auth-server-url` | Die konkrete URL des Authentifizierungsservers, an die Token-Anfragen gesendet werden | | `grant_type` | Immer `client_credentials` für eStamp-Integrationen | ### Schritt 1: Bearer Token anfordern bash # eStamp OAuth 2.0: Bearer Token anfordern # Endpoint: POST /token am konfigurierten Auth-Server # Grant Type: client_credentials (Maschine-zu-Maschine) curl -X POST "https:///token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials" \ -d "client_id=" \ -d "client_secret=" **Erfolgreiche Antwort (200 OK):** json { "access_token": "eyJhbGciOiJSUzI1NiIsInR5...", "token_type": "Bearer", "expires_in": 3600 } ### Schritt 2: Bearer Token bei jedem API-Aufruf verwenden Der Bearer Token wird bei jedem eStamp-API-Aufruf im `Authorization`-Header mitgesendet: Authorization: Bearer > \[!WARNING\] Der eStamp Bearer Token hat eine begrenzte Gültigkeitsdauer (`expires_in`). Nach Ablauf liefert die eStamp API den Fehler `451 Unavailable for Legal Reasons` (JWT token is expired). Implementieren Sie in Ihrer Integration eine automatische Token-Erneuerung vor Ablauf der Gültigkeitsdauer. > \[!IMPORTANT\] Bearer Tokens sind wie Passwörter zu behandeln. Zugangsdaten (`client_id`, `client_secret`, Bearer Token) dürfen **niemals** im Quellcode, in Klartext-Konfigurationsdateien oder in Versionskontrollsystemen gespeichert werden. Empfohlene Ablage: Secret Manager (z. B. HashiCorp Vault, Keycloak, AWS Secrets Manager). ## eStamp API testen mit Swagger Swagger ist die interaktive API-Dokumentationsplattform, die auf Basis der OpenAPI-Spezifikation von eStamp automatisch generiert wird. Swagger ermöglicht das direkte Testen aller eStamp-Endpunkte im Browser, ohne eigenen Code schreiben zu müssen. **Swagger-URL:** Swagger ist über die jeweilige eStamp-Instanz erreichbar. Die genaue URL wird beim Deployment vom XiTrust Support Team kommuniziert. ### Swagger mit OAuth 2.0 verwenden 1. Öffnen Sie die Swagger-UI der eStamp-Instanz im Browser. 2. Klicken Sie auf den **\[Authorize\]**-Button oben rechts. 3. Geben Sie `client_id` und `client_secret` ein. Swagger fordert automatisch einen Bearer Token an und setzt ihn für alle nachfolgenden Test-Requests. 4. Führen Sie beliebige eStamp-Endpunkte direkt im Browser aus. > \[!NOTE\] Swagger eignet sich für initiale Tests und Exploration der eStamp REST-API. Für Produktions-Integrationen wird die direkte API-Nutzung über HTTP-Clients (curl, Postman, programmatische Clients) empfohlen. ## Quickstart: Erstes PDF mit eStamp versiegeln Dieser Quickstart zeigt den minimalen Ablauf, um ein PDF über die eStamp REST-API zu versiegeln. Voraussetzungen: gültige eStamp Base URL und gültige OAuth-2.0-Zugangsdaten. ### Schritt 1: Verfügbare Signaturhandler abfragen Vor dem ersten Versiegelungsaufruf müssen die verfügbaren `parameterId`-Werte der eStamp-Instanz abgefragt werden. Die `parameterId` ist ein Pflichtfeld bei jedem Seal-Aufruf und steuert, welcher Signaturhandler und welches Zertifikat verwendet wird. bash # eStamp: Verfügbare Signaturhandler abfragen # Endpoint: GET /signApi/parameterInfos # Authentifizierung: Bearer Token erforderlich curl -X GET "https://pbss.acc.xitrust.cloud/pbss/signApi/parameterInfos" \ -H "Authorization: Bearer " **Erfolgreiche Antwort (200 OK):** json [ { "parameterId": "amtssignatur", "displayName": "Amtssignatur", "maxNumberOfDocuments": 100, "signatureHandlerType": "SOFTWARE_KEY" } ] Wenn dieser Aufruf erfolgreich ist, sind Base URL, Authentifizierung und Erreichbarkeit des eStamp-Services korrekt. **Typischer Fehler bei diesem Schritt:** 404 Not Found -- "Cannot find handler for parameter" Ursachen: falsche Base URL, falscher Pfad, falsche Bezeichnung der Handler-ID. Prüfen Sie Base URL, Token und Endpoint-Pfad exakt auf Schreibweise und Groß-/Kleinschreibung. ### Schritt 2: PDF versiegeln (synchroner Workflow) bash # eStamp: PDF versiegeln (synchroner Workflow ohne Visualisierung) # Endpoint: POST /signApi/sealSingle # Authentifizierung: Bearer Token erforderlich # Rückgabe: signiertes PDF als Binary curl -X POST "https://pbss.acc.xitrust.cloud/pbss/signApi/sealSingle" \ -H "Authorization: Bearer " \ -H "accept: application/pdf" \ -H "Content-Type: multipart/form-data" \ -F "parameterId=amtssignatur" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf **Ergebnis:** Das signierte PDF wird als Binary zurückgegeben und unter `signiert.pdf` gespeichert. > \[!NOTE\] `documentToSign` und `file` sind synonyme Feldbezeichnungen und haben dieselbe Bedeutung. Beide Varianten werden von der eStamp REST-API akzeptiert. Die unterschiedlichen Namen entstanden durch historische Kundenanforderungen. ## FAQ: Authentifizierung und Grundkonzepte ### Welche Base URL bekommen Kunden konkret? Jeder Kunde erhält eine eigene, kundenspezifische Base URL für seine eStamp-Instanz, zum Beispiel `https://pbss.kunde.xitrust.cloud/pbss`. Die Base URL wird beim Deployment vom XiTrust Support Team festgelegt und kommuniziert. Ohne korrekte Base URL sind keine eStamp-API-Aufrufe möglich. ### Hat eStamp ein Mandantenmodell? Nein, eStamp kennt kein Mandantenmodell. Unterschiedliche Konfigurationen (z. B. verschiedene Zertifikate, Signaturtypen oder Signatur-Visualisierungen) werden über Signaturhandler innerhalb einer eStamp-Instanz abgebildet. Für eine vollständige technische Trennung zwischen Organisationseinheiten wird eine separate eStamp-Instanz empfohlen. ### Gibt es eine API-Versionierung? Nein, eStamp verwendet keine URL-basierte API-Versionierung (wie `/api/v1/`). Stattdessen garantiert XiTrust, dass keine Breaking Changes durchgeführt werden. Bestehende Integrationen bleiben nach Updates weiterhin funktionsfähig. Die letzten 3 eStamp-Versionen werden aktiv supportet. ### Gibt es Rollen oder Berechtigungsstufen? Nein, eStamp verwendet kein RBAC (Role-Based Access Control). Es gibt keine User-Rollen oder unterschiedliche Berechtigungsstufen. Jeder gültig authentifizierte Client kann alle geschützten eStamp-Endpunkte verwenden. ### Welche TLS-Version wird von eStamp erwartet? eStamp erfordert mindestens TLS 1.2. Standard ist TLS 1.3. Ältere TLS-Versionen werden nicht akzeptiert. ### Wie erreiche ich den eStamp Support? Bei Fragen oder Problemen wenden Sie sich an das XiTrust Support Team: * **Service Desk Ticket:** über das XiTrust Service Desk Portal * **E-Mail:** [servicedesk@xitrust.com](mailto:servicedesk@xitrust.com) Für Supportanfragen zu API-Fehlern sind folgende Informationen hilfreich: * Timestamp der Anfrage, * verwendeter Endpoint, * `sessionId` (falls vorhanden) und * vollständiger HTTP-Statuscode --- version: "v1" language: "de" --- # eStamp: FAQ zu Authentifizierung, Workflows, Limits und Fehlercodes **Inhalt** Dieses Dokument beantwortet häufig gestellte Fragen zur eStamp REST-API, gegliedert nach Themenbereich. Jede Frage ist als eigenständige Einheit formuliert und enthält den vollständigen Kontext für die Antwort. Voraussetzung für die Nutzung der eStamp REST-API: eine gültige, kundenspezifische eStamp Base URL und ein gültiger Bearer Token (OAuth 2.0 oder Basic Authorization). *** ** * ** *** ## 1. Architektur und Grundkonzepte ### Welche Base URL erhält eine eStamp-Instanz? Jede eStamp-Instanz erhält beim Deployment eine eigene, kundenspezifische Base URL. Das Format ist `https://pbss..xitrust.cloud/pbss`. Die Base URL wird vom XiTrust Support Team festgelegt und beim Deployment kommuniziert. Ohne korrekte eStamp Base URL schlagen alle API-Aufrufe mit `404 Not Found` fehl. Wenn ein eStamp-Service nicht erreichbar ist, ist die Base URL der erste zu prüfende Punkt. ### Hat eStamp ein Mandantenmodell? eStamp kennt kein Mandantenmodell. Es gibt innerhalb einer eStamp-Instanz keine getrennten Mandanten. Unterschiedliche Konfigurationen --- zum Beispiel verschiedene Zertifikate, Signaturtypen oder Signatur-Visualisierungen --- werden über **Signaturhandler** innerhalb einer Instanz abgebildet. Mehrere Organisationseinheiten können dadurch unterschiedlich konfiguriert arbeiten, ohne eine eigene Instanz zu benötigen. Für vollständige technische Trennung wird eine separate eStamp-Instanz empfohlen. ### Gibt es eine API-Versionierung in eStamp? eStamp verwendet keine URL-basierte API-Versionierung wie `/api/v1/` oder `/api/v2/`. Stattdessen garantiert XiTrust, dass keine Breaking Changes an der eStamp REST-API durchgeführt werden. Bestehende Integrationen bleiben nach Updates weiterhin funktionsfähig. Die letzten zwei eStamp-Versionen werden aktiv supportet. Ein spezielles Kompatibilitätsmanagement ist daher nicht erforderlich. ### Was ist die eStamp REST-API und welche Protokolle werden verwendet? Die eStamp REST-API ist die Schnittstelle, über die alle Signier-, Siegel- und Validierungsoperationen ausgeführt werden. Die Kommunikation erfolgt ausschließlich über HTTPS mit den Standard-HTTP-Methoden `GET` (Informationen abrufen) und `POST` (Dokument senden, Signatur auslösen). Es werden keine proprietären oder exotischen Protokolle verwendet. Der Basispfad aller eStamp-Signatur-Endpoints ist `/signApi/...`. *** ** * ** *** ## 2. Authentifizierung und Sicherheit ### Welche Authentifizierungsmethoden unterstützt eStamp? eStamp unterstützt zwei Authentifizierungsmethoden: **OAuth 2.0** und **Basic Authorization**. Beide Methoden schützen alle eStamp-Endpoints, die Dokumente verarbeiten. Ohne gültige Authentifizierung werden keine Signier- oder Seal-Vorgänge akzeptiert. OAuth 2.0 ist die empfohlene Methode für alle neuen eStamp-Integrationen. Basic Authorization wird primär für Legacy- oder einfache Integrationsszenarien unterstützt. ### Was ist der eStamp Bearer Token und wie wird er verwendet? Der eStamp Bearer Token ist ein Zugriffstoken, das über den OAuth-2.0-Flow (Grant Type: Client Credentials) vom konfigurierten Authentifizierungsserver bezogen wird. Der Bearer Token wird bei jedem eStamp-API-Aufruf im `Authorization`-Header mitgesendet: `Authorization: Bearer `. Der Token hat eine begrenzte Gültigkeitsdauer (`expires_in`). Nach Ablauf gibt die eStamp API `451 Unavailable for Legal Reasons` zurück. Integrationen sollten eine automatische Token-Erneuerung vor Ablauf der Gültigkeitsdauer implementieren. > \[!NOTE\] Warum HTTP 451 bei abgelaufenem Token? Der Statuscode `451 Unavailable for Legal Reasons` wird vom zugrundeliegenden PBSS-Framework für abgelaufene Tokens verendet. Clients sollten sowohl `401 Unauthorized` als auch `451` als Indikator für einen nicht mehr gültigen Token behandeln und eine Token-Erneuerung auslösen. > > \[!IMPORTANT\] Der eStamp Bearer Token ist wie ein Passwort zu behandeln. `client_id`, `client_secret` und Bearer Token dürfen niemals im Quellcode, in Klartext-Konfigurationsdateien oder in Versionskontrollsystemen gespeichert werden. Empfohlene Ablage: Secret Manager (z. B. HashiCorp Vault, Keycloak, AWS Secrets Manager). ### Wie wird Basic Authorization bei eStamp verwendet? Bei Basic Authorization werden Benutzername und Passwort im Authorization-Header mitgesendet. Authorization: Basic \ **Codierung der Credentials:** Der String benutzername:passwort muss gemäß RFC 7617 zunächst als UTF-8 codiert und anschließend mit Base 64 codiert werden. Diese Reihgenfolge ist verbindlich: 1. String benutzername:passwort bilden (durch : getrennt) 2. Bytes mit UTF-8 erzeugen 3. Bytes mit Base64 in ASCII-Repräsentation codieren 4. Das Ergebnis hinter Basic in den Authorization-Header einfügen **Beispiel (Passwort mit Sonderzeichen p@ßwörd!):** # UTF-8-Bytes: 75 73 65 72 3A 70 40 C3 9F 77 C3 B6 72 64 21 # Base64: dXNlcjpwQMOfd8O2cmQh curl -X POST "https:///signApi/sealSingle" \ -H "Authorization: Basic dXNlcjpwQMOfd8O2cmQh" \ -F "parameterId=amtssignatur" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf > \[!IMPORTANT\] **Nicht-ASCII-Zeichen im Passwort** (Umlaute, ß, Akzentzeichen, etc.) werden ausschließlich bei korrekter UTF-8-Codierung vor dem Base64-Schritt zuverlässig übertragen. Die historische Empfehlung, Basic-Auth-Credentials auf 7-Bit-ASCII zu beschränken, ist nicht mehr nötig, solange UTF-8 verwendet wird. Die meisten HTTP-Client-Bibliotheken (curl, Python requests, HttpClient, Axios, OkHttp, etc.) verwenden UTF-8 als Standard. > > \[!NOTE\] Dieselbe Codierung (UTF-8 → Base64) gilt für **alle** XiTrust-Schnittstellen mit Basic Authorization. ### Welche TLS-Version erfordert eStamp? eStamp erfordert mindestens TLS 1.2. Der Standard ist TLS 1.3. Verbindungsversuche mit älteren TLS-Versionen werden abgelehnt. Alle Verbindungen zur eStamp REST-API sind damit verschlüsselt und entsprechen aktuellen Sicherheitsstandards. ### Sind alle eStamp-Endpoints gleich geschützt? Nein, eStamp unterscheidet zwischen geschützten und ungeschützten Endpoints. Ungeschützt erreichbar sind ausschließlich Lizenzinformations-Endpoints, da diese Informationen nicht sicherheitsrelevant sind. Alle Endpoints, die Dokumente verarbeiten (also Signieren, Sealen und Session-Operationen) sind mit OAuth 2.0 oder Basic Authorization geschützt. Jeder gültig authentifizierte Client kann alle geschützten eStamp-Endpoints verwenden; es gibt keine RBAC, keine User-Rollen und keine unterschiedlichen Berechtigungsstufen. *** ** * ** *** ## 3. Workflows: Synchron und Session-basiert ### Was ist der Unterschied zwischen synchronem und session-basiertem Workflow in eStamp? Der synchrone eStamp-Workflow verarbeitet ein einzelnes Dokument pro API-Aufruf: Das Dokument wird gesendet und das signierte Ergebnis sofort zurückgegeben --- ohne Sessions, Zwischenspeicherung oder Statusabfragen. Der session-basierte Workflow ermöglicht die Batch-Verarbeitung mehrerer Dokumente in einem mehrstufigen Ablauf (`startSession` → `addDocument` → `seal` → `getDocument` → `closeSession`). Der synchrone Workflow ist für einzelne Dokumente einfacher; der session-basierte Workflow ist für Stapelverarbeitung bis zu 100 Dokumenten pro Session notwendig. ### Gibt es in eStamp Hintergrundprozesse oder einen Status-Endpoint? eStamp arbeitet nicht mit Hintergrundprozessen, Status-Endpoints, Polling oder Webhooks. Jeder eStamp-API-Aufruf blockiert, bis er vollständig abgeschlossen ist, und liefert das Ergebnis direkt zurück. Das gilt sowohl für synchrone Aufrufe als auch für den `seal`-Schritt im session-basierten Workflow. ### Wie viele Dokumente können pro eStamp-Session verarbeitet werden? Pro eStamp-Batch-Session können maximal **100 Dokumente** verarbeitet werden. Dasselbe Limit gilt pro einzelnem REST-Aufruf. Wenn mehr als 100 Dokumente signiert werden müssen, sind mehrere Sessions zu starten. Die Anzahl gleichzeitig laufender Sessions ist nicht limitiert. Pro REST-Aufruf kann nur eine Session gestartet werden. ### Ist der eStamp session-basierte Workflow ein echtes Async-Modell? Nein, der session-basierte eStamp-Workflow ist kein asynchrones Modell. Jeder Aufruf --- einschließlich `seal` --- blockiert, bis er abgeschlossen ist. Es gibt keinen Status-Endpoint, keine Job-ID und kein Webhook. Wenn `seal` abgeschlossen ist, kann `getDocument` aufgerufen werden. ### Wie lange ist eine eStamp-Session gültig und wie lange darf ein Aufruf dauern? Eine eStamp-Batch-Session ist ab dem `startSession`-Aufruf **40 Minuten** gültig. Wird die Session innerhalb dieser Zeit nicht mit `closeSession` beendet, läuft sie automatisch ab. Für die Laufzeit einzelner API-Aufrufe gilt: * Reine konfigurations- und Discovery-Aufrufe (`parameterInfos`, `signatureAppearanceInfos`, etc.) `startSession`, `addDocument`, `getDocument`, `closeSession`, sowie `validatePDF`/`validateXml` werden typischerweise innerhalb weniger Sekunden beantwortet. * Ein `seal`-Aufruf bildet hier eine Ausnahme: er blockiert, bis alle Dokumente der Session signiert sind, und kann bei größeren Batches **60-120 Sekunden** in Anspruch nehmen. Falls die Infrastruktur (Proxy, API-Gateway, Firewall) kürzere Timeouts erzwingt, kann der Batch in mehrere kleine Sessions aufgeteilt werden (siehe API-Referenz, `POST/signApi/{sessionId}/seal`). Ein Timeout bedeutet nicht zwingend, dass das Dokument beschädigt ist, sondern dass der Aufruf zu lange gedauert hat. ### Was passiert bei Timeout oder Abbruch eines eStamp-API-Aufrufs? Bei Timeout oder Abbruch eines eStamp-API-Aufrufs wird der Prozess beendet und eine Fehlermeldung zurückgegeben. Es erfolgt keine teilweise Verarbeitung. Abgelaufene oder nicht abgeschlossene eStamp-Sessions werden automatisch bereinigt. Es ist kein manueller Cleanup erforderlich. ### Können Dokumente nach dem Hinzufügen aus einer eStamp-Session entfernt oder ersetzt werden? Nein. Einmal zur eStamp-Session hinzugefügte Dokumente können weder entfernt noch ersetzt werden. Wurde ein falsches Dokument hinzugefügt, muss eine neue eStamp-Session über `startSession` gestartet werden. ### Gibt es Partial Failure bei der eStamp-Batch-Verarbeitung? eStamp unterstützt kein Partial Failure. Ein Batch-Vorgang ist entweder vollständig erfolgreich oder schlägt vollständig fehl. Es gibt keine teilweise Verarbeitung einzelner Dokumente innerhalb einer Session. *** ** * ** *** ## 4. Limits und Performance ### Welche technischen Limits gelten für die eStamp REST-API? Für die eStamp REST-API gelten folgende Limits: * maximal **100 Dokumente** pro Session und pro REST-Aufruf, * **Session-Gültigkeit von 40 Minuten** ab `startSession`, * Typische Aufruf-Antwortzeit: wenige Sekunden; **Ausnahme seal: 60 - 120 Sekunden** bei großen Batches * und eine **maximale Dateigröße** die instanzspezifisch in der Systemkonfiguration definiert ist. Die maximale Dateigröße ist nicht fest vorgegeben und kann je nach eStamp-Instanz unterschiedlich sein. ### Welche Rate Limits gibt es bei eStamp? eStamp definiert keine öffentlich festgelegte Rate-Limit-Grenze (z. B. „X Requests pro Sekunde"). Bei zu vielen gleichzeitigen Anfragen kann es zu verlängerten Antwortzeiten, Timeouts oder HTTP `429 Too Many Requests` kommen. eStamp ist für kontrollierte, sequenzielle API-Aufrufe konzipiert und kein Streaming-System. Aggressive Parallelisierung sollte vermieden werden. ### Was bedeutet HTTP 429 bei eStamp und wie reagiert man darauf? HTTP `429 Too Many Requests` signalisiert, dass zu viele Anfragen in kurzer Zeit gesendet wurden, oder dass das Dokumentlimit einer Session erreicht wurde. Die empfohlene Retry-Strategie: eine Wartezeit von 2 - 5 Sekunden einlegen und den Request erneut senden. Batch-Verarbeitungen sollten bei hohem Volumen gestaffelt werden. *** ** * ** *** ## 5. Datei-Upload und Dateiformate ### Welche Dateiformate akzeptiert eStamp für Uploads? eStamp akzeptiert für Dokument-Uploads ausschließlich `application/pdf`. Andere Formate wie `application/octet-stream`, XML oder sonstige Dokumenttypen werden für PDF-Signatur-Endpoints nicht akzeptiert und führen zu `415 Unsupported Media Type`. XML-Dokumente können über den separaten Endpoint `POST /xmlSignApi/validateXml` validiert werden. ### Gibt es eine maximale Dateigröße bei eStamp? Ja, aber die maximale Dateigröße ist nicht global fest vorgegeben. Sie ist in der Systemkonfiguration der jeweiligen eStamp-Instanz definiert und kann daher je nach Deployment unterschiedlich sein. Überschreitet ein hochgeladenes Dokument das konfigurierte Limit, gibt eStamp `413 Payload Too Large` zurück. ### Welche Einschränkungen gelten für hochzuladende PDF-Dokumente? eStamp schränkt weder die Seitenanzahl noch die PDF-Variante ein. Alle gängigen PDF-Varianten (darunter PDF und PDF/A) werden verarbeitet. Temporäre Dateien werden während der Verarbeitung verschlüsselt abgelegt. *** ** * ** *** ## 6. Signatursteuerung und Visualisierung ### Welcher Parameter steuert das Signaturverhalten in eStamp? Das Signaturverhalten in eStamp wird durch die `parameterId` gesteuert. Die `parameterId` ist bei jedem Seal-Aufruf ein Pflichtfeld und bestimmt, welcher Signaturhandler verwendet wird, welches Zertifikat zum Einsatz kommt und welches Sealing-Verhalten greift. Die verfügbaren `parameterId`-Werte einer eStamp-Instanz werden über `GET /signApi/parameterInfos` abgefragt. ### Wie wird die Signaturvisualisierung (`signatureAppearance`) an eStamp übergeben? Die `signatureAppearance`-Konfiguration kann auf zwei Arten übergeben werden: als **JSON-Datei** beim Aufruf von `sealSingleWithAppearance` oder `addDocumentWithAppearance`, oder als **serverseitig hinterlegte ID** (`appearanceId`) beim Aufruf von `sealSingleWithAppearanceParam` oder `addDocumentWithAppearanceParam`. Das Format der `signatureAppearance`-Konfiguration ist immer JSON. ### Sind Signaturattribute (`signatureAttributes`) in eStamp konfigurierbar? Ja, über das optionale Feld `signatureAttributes` können zusätzliche X.509-Zertifikatsattribute in der Signaturvisualisierung angezeigt werden, zum Beispiel `subjectDn`, `serialNumber` oder `notAfter`. Die `signatureAttributes` sind an die Amtssignatur gekoppelt und ergeben nur bei Amtssignaturen einen sinnvollen Einsatz. Bei anderen Signaturtypen sollte das Feld nicht gesetzt werden. ### Welche Einheit verwendet das Koordinatensystem der eStamp-Signaturvisualisierung? Die Positionsangaben `x` und `y` beschreiben die Koordinaten der Signaturvisualisierung auf der PDF-Seite. Die Größenangaben `width` und `height` werden in **pt (Punkten)** angegeben. Standardwerte: `width = 400`, `height = 270`. *** ** * ** *** ## 7. Fehlercodes und Debugging ### Welche HTTP-Statuscodes verwendet eStamp? eStamp verwendet Standard-HTTP-Statuscodes. Die folgende Tabelle zeigt die wichtigsten Codes, ihre Bedeutung und typische Ursachen: | **Code** | **Bedeutung** | **Typische Ursache** | |----------|-------------------------------|---------------------------------------------------------------------------| | 200 | OK | Anfrage erfolgreich; signiertes Dokument wird als Binary zurückgegeben | | 400 | Bad Request | Ungültige `parameterId`, falsches PDF-Format, ungültige Session-Operation | | 401 | Unauthorized | Kein oder ungültiger Bearer Token | | 403 | Forbidden | Falsche Authentifizierungsmethode | | 404 | Not Found | Falsche Base URL, unbekannte `sessionId`, Signaturhandler nicht gefunden | | 406 | Not Acceptable | Fehlerhafte `signatureAppearance`-Konfiguration, Zertifikatsproblem | | 412 | Precondition Failed | Ungültige oder abgelaufene `sessionId` | | 413 | Payload Too Large | Datei überschreitet das konfigurierte Größenlimit | | 415 | Unsupported Media Type | Falscher Content-Type (erwartet: `application/pdf`) | | 422 | Unprocessable Entity | Ungültiges oder beschädigtes PDF | | 429 | Too Many Requests | Dokumentlimit der Session erreicht oder zu viele parallele Requests | | 451 | Unavailable for Legal Reasons | Bearer Token abgelaufen | | 500 | Internal Server Error | Unerwarteter Systemfehler, Infrastrukturproblem | ### Wie sehen eStamp-Fehlerantworten aus? eStamp gibt Fehler mit einem HTTP-Statuscode und einer Fehlermeldung zurück. Es gibt kein zusätzliches einheitliches JSON-Fehler-Schema --- die Fehlerinformation ist im HTTP-Statuscode und der zugehörigen Nachricht enthalten. ### Wie debugge ich eStamp-Fehler über Response-Header? eStamp-Anfragen können über die Request-ID im Response-Header nachverfolgt werden. Die Request-ID ermöglicht die interne Zuordnung zu Log-Einträgen, enthält aber selbst keine inhaltliche Fehlerinformation. Für Supportanfragen sind folgende Angaben hilfreich: Timestamp der Anfrage, verwendeter Endpoint, `sessionId` (falls vorhanden) und vollständiger HTTP-Statuscode. ### Was sind die häufigsten Fehlerursachen bei eStamp? In der Mehrzahl der Fälle sind eStamp-Fehler auf vier Ursachen zurückzuführen: eine falsche oder ungültige `parameterId` (400), einen abgelaufenen oder fehlenden Bearer Token (401/451), ein zu großes Dokument (413) oder ein ungültiges bzw. beschädigtes PDF (422). Die Kurzdiagnose für Betrieb und Administration: 400er-Fehler deuten auf Konfigurationsprobleme hin, 401/403/451 auf Authentifizierungsprobleme, 413 auf Dateigröße und 500 auf Systemprobleme. ### Was tun bei HTTP 500 Internal Server Error von eStamp? HTTP `500 Internal Server Error` signalisiert einen unerwarteten Systemfehler in eStamp, zum Beispiel ein Infrastrukturproblem, ein Zertifikatsproblem oder eine fehlgeschlagene Signaturerstellung. Prüfen Sie die eStamp-Server-Logs anhand des Timestamps und der `sessionId`. Wenn das Problem nicht selbst lösbar ist, kontaktieren Sie das MOXIS Support Team unter [servicedesk@xitrust.com](mailto:servicedesk@xitrust.com) mit Timestamp, Endpoint, `sessionId` und HTTP-Statuscode. *** ** * ** *** ## Kurzreferenz: Schnelldiagnose bei eStamp-Fehlern Wenn ein eStamp-API-Aufruf fehlschlägt, empfiehlt sich folgende Reihenfolge für die Fehlerdiagnose: 1. **HTTP-Statuscode prüfen** --- gibt den Fehlertyp an (siehe Tabelle oben) 2. **Bearer Token prüfen** --- ist der Token gültig und nicht abgelaufen? 3. `parameterId`**prüfen** --- existiert der Wert in `GET /signApi/parameterInfos`? 4. **Base URL prüfen** --- ist die kundenspezifische eStamp Base URL korrekt? 5. **Dateigröße prüfen** --- überschreitet das Dokument das konfigurierte Limit? 6. **Logs prüfen** --- anhand Timestamp und `sessionId` in den eStamp-Server-Logs nachverfolgen --- version: "v1" language: "de" --- # eStamp Glossar: Begriffe und Konzepte der Dokumentensignierung **Inhalt** Dieses Glossar definiert alle Fachbegriffe, die in der eStamp-Dokumentation verwendet werden. Es dient als **verbindliche Terminologie-Referenz** für alle weiteren eStamp-Dokumente. Begriffe sind thematisch gruppiert und jeweils eigenständig verständlich -- jeder Eintrag enthält Produktkontext, Definition und Querverweise. > **Zielgruppe:** Entwickler:innen und Administrator:innen, die neu mit der eStamp REST-API arbeiten. **Supportanfragen** bitte an das XiTrust Support Team unter [++servicedesk@xitrust.com++](mailto:servicedesk@xitrust.com). *** ** * ** *** ## A: Architektur \& Betrieb Dieser Abschnitt erklärt die grundlegenden Architektur- und Betriebskonzepte von eStamp. ### eStamp (Produkt) eStamp ist ein XiTrust-Service zum **automatischen Signieren und Siegeln von Dokumenten** über eine REST-API oder einen Webclient. Dokumente werden als PDF an die eStamp-API gesendet, signiert oder versiegelt und als signiertes PDF zurückgegeben. Typische Einsatzbereiche sind Behörden (Bescheide), Versicherungen (Polizzen) und Unternehmen (automatisierte Dokumentenprozesse). **Synonyme im System:** eStamp wird intern auch als „Seal-Service" bezeichnet. In der API ist der Basispfad `/signApi/...`. → Siehe: \[ \] ### Base URL (eStamp-Instanz-Adresse) Die eStamp-Base-URL ist die **kundenspezifische Webadresse**, über die eine eStamp-Instanz erreichbar ist. Sie wird beim Deployment festgelegt und ist Voraussetzung für jeden API-Aufruf. **Format:** https://pbss..xitrust.cloud/pbss **Beispiel:** https://pbss.acc.xitrust.cloud/pbss > \[!WARNING\] Die Base URL ist individuell pro Kunde. Ohne korrekte Base URL schlagen alle API-Aufrufe fehl. Wenn der Service nicht erreichbar ist, ist die Base URL der erste Prüfpunkt. → Siehe: \[ \] ### eStamp-Instanz Eine eStamp-Instanz ist eine **eigenständige Bereitstellung von eStamp**, entweder als Cloud-Variante (durch XiTrust gehostet) oder als On-Premises-Installation (in der Kundeninfrastruktur betrieben). Jede Instanz hat eine eigene Base URL und eine eigene Konfiguration. **Deployment-Varianten:** | **Variante** | **Betrieb durch** | **Server erforderlich** | |--------------|----------------------|-------------------------| | Cloud | XiTrust Support Team | Nein | | On-Premises | Kunde selbst | Ja | > \[!NOTE\] Für vollständige technische Trennung zwischen Organisationseinheiten (z.B. Konzernstrukturen) wird eine separate eStamp-Instanz empfohlen. **Merksatz: Technische Trennung = eigene Instanz.** ### Mandantenmodell (eStamp) eStamp kennt **kein Mandantenmodell** . Es gibt innerhalb einer eStamp-Instanz keine getrennten Mandanten wie bei anderen Systemen. Unterschiedliche Konfigurationen (z.B. verschiedene Zertifikate, Signaturtypen, Visualisierungen) werden stattdessen über **Signaturhandler** innerhalb einer Instanz abgebildet. ### Signaturhandler (eStamp) Ein eStamp-Signaturhandler ist eine **Softwarekomponente, die den technischen Ablauf eines Signaturvorgangs steuert** . Er bestimmt, welches Zertifikat verwendet wird und welches Seal-Verhalten greift. Ein Signaturhandler wird über die `parameterId` in jedem Seal-Aufruf ausgewählt. **Verfügbare Handler abfragen:** # eStamp-API: Alle konfigurierten Signaturhandler abrufen GET /signApi/parameterInfos Authorization: Bearer **Beispiel-Response:** [ { "parameterId": "software", "displayName": "software", "maxNumberOfDocuments": 100, "signatureHandlerType": "SOFTWARE_KEY" } ] → Siehe: \[ \] *** ** * ** *** ## B: Authentifizierung \& Sicherheit Dieser Abschnitt erklärt alle Authentifizierungskonzepte der eStamp REST-API. Ohne gültige Authentifizierung gibt die eStamp-API HTTP 401 zurück und verweigert alle Signatur- und Seal-Operationen. ### Basic Authorization (eStamp) Basic Authorization ist eine einfache Authentifizierungsmethode für die eStamp-API, bei der klassische Zugangsdaten (Benutzername + Passwort) als Base64-kodierter HTTP-Header übergeben werden. > \[!NOTE\] Basic Authorization wird für eStamp unterstützt, ist aber **weniger empfohlen** als OAuth 2.0. Für Produktionsumgebungen sollte OAuth 2.0 mit Client Credentials verwendet werden. ### OAuth 2.0 (eStamp-Authentifizierung) OAuth 2.0 ist die **empfohlene Authentifizierungsmethode** für die eStamp REST-API. eStamp verwendet ausschließlich den Grant Type **Client Credentials** -- das bedeutet, eine Maschine oder ein System authentifiziert sich, kein menschlicher Benutzer. Es gibt keine Benutzerkonten, Passwörter oder Rollen. **Pflichtfelder für die OAuth-2.0-Konfiguration in eStamp:** | **Feld** | **Beschreibung** | **Festgelegt durch** | |-------------------|-----------------------------------------------|----------------------| | `client-id` | „Benutzername" der Anwendung beim Auth-Server | XiTrust | | `client-secret` | „Passwort" der Anwendung (geheimer Schlüssel) | XiTrust | | `auth-server-url` | Konkrete URL für Token-Anfragen | XiTrust | | `grant_type` | Immer `client_credentials` | XiTrust | **Token anfordern (cURL):** # eStamp OAuth 2.0: Bearer Token anfordern # Endpoint: POST /token am Auth-Server (auth-server-url) # Voraussetzung: client-id und client-secret vom Deployment erhalten curl -X POST "/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials" \ -d "client_id=" \ -d "client_secret=" # Erfolgreiche Response (200 OK): # { # "access_token": "eyJhbGciOiJSUzI1NiIsInR5...", # "token_type": "Bearer", # "expires_in": 3600 # } # # Fehler 401: client-id oder client-secret falsch # Fehler 404: auth-server-url falsch → Details: \[`https://documentation.xitrust.com/de/estamp-dokumentation/latest/estamp-aufbau-nutzung-und-authentifizierung-fur-pd#id-(v1)eStamp:Aufbau,NutzungundAuthentifizierungfürPDF-Signaturen-OAuth2.0ineStamp:KonfigurationundAblauf]` ### Bearer Token (eStamp-Zugriffstoken) Der eStamp-Bearer-Token ist ein **OAuth-2.0-Zugriffstoken** , das bei jedem eStamp-API-Aufruf im `Authorization`-Header mitgesendet werden muss. Es ist der einzige Authorization Header, der von der eStamp-API benötigt wird. **Verwendung:** Authorization: Bearer **Gültigkeitsdauer:** Im `expires_in`-Feld der Token-Response angegeben (typisch: 3600 Sekunden = 1 Stunde). Nach Ablauf gibt die eStamp-API HTTP 401 zurück. > \[!WARNING\] **Sicherheitsregel:** Den eStamp-Bearer-Token wie ein Passwort behandeln. Niemals im Quellcode speichern oder in Klartext ablegen. Empfohlene Speicherorte: Keycloak, HashiCorp Vault oder ein vergleichbarer Secret Store. **Best Practices:** * Token nur für autorisierte Systeme zugänglich machen * Ablaufzeit (`expires_in`) überwachen und Token proaktiv erneuern * Bei HTTP 401: Zuerst Token-Gültigkeit prüfen, dann OAuth-Konfiguration ### Client ID / Client Secret (eStamp OAuth) `client_id` und `client_secret` sind die Identifikationsdaten einer Anwendung gegenüber dem eStamp-Authentifizierungsserver. * `client_id`**:** Der „Benutzername" der Anwendung -- der Name, unter dem sie beim Auth-Server registriert ist. * `client_secret`**:** Das „Passwort" der Anwendung -- ein geheimer Schlüssel, den nur die Anwendung und der Auth-Server kennen. Zusammen mit der `client_id` beweist er die Identität der Anwendung. > \[!WARNING\] Das `client_secret` darf niemals im Quellcode oder in versionierten Konfigurationsdateien gespeichert werden. ### issuer-uri / auth-server-url (eStamp OAuth) * `issuer-uri`**:** Die Adresse des Identity Providers (z.B. Keycloak), der eStamp-Tokens ausstellt. Identifiziert eindeutig, wer die Tokens autorisiert. * `auth-server-url`**:** Die konkrete URL, an die Token-Anfragen gesendet werden. Oft ähnlich wie `issuer-uri`, kann aber leicht abweichen. Beide Werte werden von XiTrust beim Deployment festgelegt und kommuniziert. ### TLS (eStamp-Verbindungssicherheit) eStamp verwendet ausschließlich HTTPS-Verbindungen. Unterstützte TLS-Versionen: | **Version** | **Status** | |-------------------|--------------------| | TLS 1.3 | ✅ Standard | | TLS 1.2 | ✅ Unterstützt | | TLS 1.1 und älter | ❌ Nicht akzeptiert | *** ** * ** *** ## C: API-Konzepte \& Workflows Dieser Abschnitt erklärt die grundlegenden API-Konzepte und Workflow-Typen der eStamp REST-API. Nahezu alle Endpunkte (Ausnahme: XML Signatur) sind unter dem Basispfad `/signApi/...` erreichbar. ### eStamp REST-API Die eStamp REST-API ist die standardisierte HTTP-Schnittstelle zur Kommunikation mit dem eStamp-Signierservice. Alle Aufrufe erfolgen über HTTPS. Es gibt zwei HTTP-Methoden: * `GET` -- Konfigurationsinformationen abrufen (z.B. verfügbare `parameterId`-Werte) * `POST` -- Dokumente senden und Signiervorgänge auslösen Kein exotisches Protokoll: Wer bereits mit REST-Webservices gearbeitet hat, kennt das Prinzip. ### Synchroner Workflow (eStamp) Ein eStamp-synchroner Workflow ist ein **einzelner API-Aufruf**, der ein PDF-Dokument entgegennimmt, sofort signiert und das signierte Dokument direkt zurückgibt. Es gibt keine Session, kein Zwischenspeichern und keinen Status-Endpoint. **Ablauf:** 1. PDF + `parameterId` per `POST` senden 2. eStamp signiert synchron 3. Signiertes PDF als Binary-Response empfangen **Verfügbare Endpunkte:** | **Endpunkt** | **Wann verwenden** | |-----------------------------------------------|---------------------------------------------------------------| | `POST /signApi/sealSingle` | Signieren ohne Visualisierung | | `POST /signApi/sealSingleWithAppearance` | Signieren mit individueller Visualisierung (JSON-Datei) | | `POST /signApi/sealSingleWithAppearanceParam` | Signieren mit serverseitig vordefinierter Visualisierung (ID) | → Siehe: \[ \] ### Session-basierter Workflow / Batch-Workflow (eStamp) Ein eStamp-session-basierter Workflow (auch: Batch-Workflow) ist ein **mehrstufiger Prozess zur gleichzeitigen Verarbeitung mehrerer Dokumente** innerhalb einer Sitzung (Session). Er wird verwendet, wenn mehr als ein Dokument auf einmal signiert werden soll. **Reihenfolge der Aufrufe (bindend):** | **Schritt** | **Methode** | **Endpunkt** | **Beschreibung** | |-------------|-------------|-----------------------------------------|-------------------------------------------------| | 1 | POST | `/signApi/startSession` | Neue Session starten, `sessionId` erhalten | | 2 | POST | `/{sessionId}/addDocument` | Dokument(e) hinzufügen (wiederholbar, max. 100) | | 3 | POST | `/{sessionId}/seal` | Signiervorgang für alle Dokumente auslösen | | 4 | GET | `/{sessionId}/getDocument/{documentId}` | Signierte Dokumente abrufen | | 5 | POST | `/{sessionId}/closeSession` | Session beenden | > \[!WARNING\] Die Reihenfolge ist bindend. `getDocument` vor `seal` gibt HTTP 404 zurück. Alle Dokumente vor `closeSession` abrufen -- danach sind sie nicht mehr verfügbar. → Siehe: \[`https://documentation.xitrust.com/de/estamp-dokumentation/latest/estamp-workflow-anleitungen-fur-das-signieren-und-#id-(v1)eStamp:Workflow-AnleitungenfürdasSignierenundValidierenvonPDF-Dokumenten-Signaturvisualisierung(signatureAppearance):Konfigurationsreferenz`\] ### Session (eStamp) Eine eStamp-Session ist ein **temporärer Verarbeitungskontext für einen Batch-Signiervorgang** . Sie wird über eine `sessionId` referenziert, die bei `POST /signApi/startSession` zurückgegeben wird. **Wichtige Session-Eigenschaften:** | **Eigenschaft** | **Wert** | |----------------------------------|---------------------------------------------------------| | Gültigkeitsdauer | 40 Minuten | | Max. Dokumente pro Session | 100 | | Dokumente nachträglich entfernen | ❌ Nicht möglich | | Automatische Bereinigung | ✅ Ja (abgelaufene Sessions werden automatisch gelöscht) | > \[!NOTE\] Wenn ein falsches Dokument hinzugefügt wurde, muss eine neue Session gestartet werden -- Dokumente können nach dem Hinzufügen nicht mehr entfernt werden. ### parameterId (eStamp-Pflichtfeld) Die `parameterId` ist ein **Pflichtfeld bei jedem eStamp-Seal-Aufruf** . Sie steuert, welcher Signaturhandler verwendet wird, welches Zertifikat genutzt wird und welches Sealing-Verhalten greift. Ohne gültige `parameterId` gibt die eStamp-API HTTP 400 zurück. **Verfügbare** `parameterId`**-Werte abfragen:** # eStamp-API: Verfügbare parameterId-Werte abrufen # Dieser Aufruf sollte vor dem ersten Seal-Vorgang ausgeführt werden curl -X GET "https:///pbss/signApi/parameterInfos" \ -H "Authorization: Bearer " # Erfolgreiche Response (200 OK): # [{ "parameterId": "seal", "displayName": "...", ... }] # # Fehler 404: Bearer Token fehlt oder Base URL falsch ### multipart/form-data (eStamp Upload-Format) `multipart/form-data` ist das HTTP-Übertragungsformat, das von den meisten eStamp-Endpunkten für Datei-Uploads verwendet wird. Dabei werden PDF-Dokumente, JSON-Konfigurationen und String-Parameter in einem einzigen HTTP-Request gebündelt. **Wichtig:** Dokumente müssen mit `Content-Type: application/pdf` übergeben werden. Andere Formate (`application/octet-stream`, XML etc.) werden von der eStamp-API abgelehnt (HTTP 415). *** ** * ** *** ## D: Signaturvisualisierung Dieser Abschnitt erklärt alle Konzepte der eStamp-Signaturvisualisierung -- also wie eine Signatur optisch in einem PDF-Dokument dargestellt wird. Die Konfiguration erfolgt über das `signatureAppearance`-JSON-Objekt. > \[!WARNING\] Es gibt **zwei Sonderfälle** (`VisualizationAutomation` und `signatureFieldId`), die sich gegenseitig ausschließen und nicht kombiniert werden dürfen. ### signatureAppearance (eStamp) Die eStamp-`signatureAppearance` ist eine **JSON-Konfiguration, die festlegt, wie eine Signatur optisch im PDF dargestellt wird** -- Position, Größe, Signaturbild und Seitenbereich. Sie kann auf zwei Arten übergeben werden: 1. Als JSON-Datei direkt im Request (`sealSingleWithAppearance`, `addDocumentWithAppearance`) 2. Als serverseitig vordefinierte ID (`appearanceId`) als Query-Parameter (`sealSingleWithAppearanceParam`, `addDocumentWithAppearanceParam`) **Welchen Modus verwenden?** | **Situation** | **Empfohlener Modus** | |-------------------------------------------------------|---------------------------------------| | Position und Seite individuell pro Aufruf festlegen | JSON-Datei direkt übergeben | | Standardisierte Firmen-Visualisierung wiederverwenden | `appearanceId` als Query-Parameter | | PDF hat bereits definierte Signaturfelder | Sonderfall: `signatureFieldId` | | Signatur automatisch ans Dokumentende setzen | Sonderfall: `VisualizationAutomation` | **Pflichtfelder (Standardfall):** | **Feld** | **Typ** | **Beschreibung** | |--------------------|---------|---------------------------------------------------------------| | `signatureImageId` | string | ID des serverseitig hinterlegten Signaturbilds | | `lastPage` | int | Letzte Seite mit Signatur (`-1` = letzte Seite des Dokuments) | | `onEveryPage` | boolean | `true` = Signatur auf jeder Seite im Bereich | | `x` | int | Horizontale Position in pt | | `y` | int | Vertikale Position in pt | **Optionale Felder (Standardfall):** | **Feld** | **Typ** | **Standard** | **Beschreibung** | |-----------------------|---------|--------------|---------------------------------------------| | `signaturePageId` | string | -- | ID einer zusätzlichen Signaturseite | | `firstPage` | int | 1 | Erste Seite, auf der die Signatur erscheint | | `width` | int | 400 | Breite der Visualisierung in pt | | `height` | int | 270 | Höhe der Visualisierung in pt | | `signatureAttributes` | object | -- | Zertifikatsattribute (nur Amtssignatur) | > \[!NOTE\] **Koordinatensystem:** `x`/`y` sind Koordinaten, `width`/`height` werden in **pt** (Punkten) angegeben -- gleiche Logik wie in MOXIS. **Vollständiges Beispiel-JSON (Standardfall):** { "signatureImageId": "amtsSignatur", "signaturePageId": "default", "firstPage": 1, "lastPage": -1, "onEveryPage": "", "x": 100, "y": 100, "width": 400, "height": 250, "signatureAttributes": { "subjectDn": "Aussteller" } } > \[!WARNING\] Wenn `onEveryPage: true` gesetzt ist, darf `signaturePageId` **nicht** gesetzt werden. ### signatureImageId (eStamp-Pflichtfeld) `signatureImageId` ist ein **Pflichtfeld in jeder eStamp-** `signatureAppearance`**-Konfiguration**. Es referenziert das serverseitig hinterlegte Signaturbild, das im PDF angezeigt werden soll. Ohne dieses Feld funktioniert die Visualisierung nicht. Der Wert muss einer der serverseitig konfigurierten Bild-IDs entsprechen. ### signaturePageId (eStamp) `signaturePageId` ist ein **optionales Feld** in der eStamp-`signatureAppearance`. Es verweist auf eine zusätzliche Signaturseite, die ans Dokument angehängt wird. > \[!WARNING\] `signaturePageId` darf **nicht** zusammen mit `onEveryPage: true` verwendet werden. Bei `VisualizationAutomation` muss `signaturePageId` gesetzt und gültig sein. ### signatureFieldId (eStamp -- Sonderfall) `signatureFieldId` ist ein **optionales Feld** für den Sonderfall, dass ein PDF bereits vordefinierte Signaturfelder enthält. Wenn gesetzt, wird die Signaturvisualisierung direkt in das angegebene Signaturfeld platziert -- ohne manuelle Koordinatenangabe. **Wenn** `signatureFieldId`**gesetzt ist, entfallen diese Felder:** `firstPage`, `lastPage`, `onEveryPage`, `x`, `y`, `width`, `height` **Minimal-JSON mit signatureFieldId:** { "signatureImageId": "imageOnly", "signatureFieldId": "Signatur2" } **Signaturfeld-Namen eines PDFs abfragen:** # eStamp-API: Vorhandene Signaturfelder eines PDFs ermitteln POST /signApi/signatureFieldNames # Parameter: document (binary PDF) # Response: JSON-Array der signatureFieldId-Werte > \[!NOTE\] Wenn `signatureFieldId` nicht gesetzt ist, wird die Position automatisch aus dem ersten Signaturfeld des PDFs übernommen. ### VisualizationAutomation (eStamp -- Sonderfall) `VisualizationAutomation` ist ein **Sonderfall der eStamp-** `signatureAppearance`, bei dem die Signaturvisualisierung automatisch am Ende des letzten Textzeichens der letzten Seite platziert wird. Wenn kein Platz oberhalb der Fußzeile vorhanden ist, wird automatisch eine neue Signaturseite erzeugt. **Pflichtfelder im** `visualizationAutomation`**-Block:** | Feld | Typ | Beschreibung | |-----------------------|-----|--------------------------------------------------------------------------| | `footerHeight` | int | Höhe der Fußzeile in pt | | `margin` | int | Abstand zwischen letztem Textzeichen und Signaturbild in pt | | `signaturePageMargin` | int | Abstand oberhalb der Signaturseite bei automatischem Seitenumbruch in pt | **Beispiel-JSON:** { "signatureImageId": "amtsSignatur", "signaturePageId": "default", "x": 100, "width": 400, "height": 250, "visualizationAutomation": { "footerHeight": 6, "margin": 10, "signaturePageMargin": 60 } } > \[!WARNING\] Bei `VisualizationAutomation` müssen folgende Bedingungen erfüllt sein: > > * `signaturePageId` muss gesetzt und gültig sein > > * `signatureAttributes` darf **nicht** gesetzt sein > > * Darf **nicht** mit `signatureFieldId` kombiniert werden ### signatureAttributes (eStamp -- Amtssignatur) `signatureAttributes` ist ein **optionales Feld** in der eStamp-`signatureAppearance`, das zusätzliche X.509-Zertifikatsattribute in der Signaturvisualisierung anzeigt. > \[!NOTE\] `signatureAttributes` ist **nur sinnvoll bei Amtssignaturen**. Bei anderen Signaturtypen hat dieses Feld keine Wirkung. **Verfügbare Zertifikatsattribute:** | Schlüssel (technisch, fix) | Anzeigetext (frei wählbar) | |----------------------------------|--------------------------------| | `subjectDn` | z.B. `"Aussteller"` | | `issuerDn` | z.B. `"Zertifizierungsstelle"` | | `notBefore` | z.B. `"Erstellungsdatum"` | | `notAfter` | z.B. `"Ablaufdatum"` | | `serialNumber` | z.B. `"Seriennummer"` | | `sigAlgName` | z.B. `"Signaturalgorithmus"` | | `sigAlgOID` | z.B. `"Signatur OID"` | | `signatureDate?datetime?iso_utc` | z.B. `"Signierdatum (UTC)"` | | `type` | z.B. `"Typ"` | | `version` | z.B. `"Version"` | > \[!TIP\] Der linke Wert (Schlüssel) ist technisch vorgegeben und darf nicht geändert werden. Der rechte Wert (Anzeigetext) kann frei gewählt werden. *** ** * ** *** ## E -- Paraphen Dieser Abschnitt erklärt die Paraphen-Funktion der eStamp-API. Eine Paraphe ist ein kleines Signaturbild, das ergänzend zur Hauptsignatur auf Seiten eines Dokuments platziert wird. ### Paraphe (eStamp) Eine eStamp-Paraphe ist ein **kleines Signaturbild** , das auf Seiten eines Dokuments platziert wird -- typischerweise als seitliche Abzeichnung. Die Konfiguration erfolgt über eine eigene JSON-Konfiguration (`paraphenImage`-Parameter), die optional zu jedem Seal-Aufruf hinzugefügt werden kann. ### paraphImageId (eStamp-Pflichtfeld) `paraphImageId` ist ein **Pflichtfeld der eStamp-Paraphen-Konfiguration**. Es referenziert das serverseitig hinterlegte Paraphenbild. **Pflichtfelder der Paraphen-Konfiguration:** | **Feld** | **Pflicht** | **Beschreibung** | |-----------------|-------------|------------------------------------------------| | `paraphImageId` | ✅ Ja | ID des serverseitig hinterlegten Paraphenbilds | | `width` | ✅ Ja | Breite der Paraphe in pt | | `height` | ✅ Ja | Höhe der Paraphe in pt | | `x` | ✅ Ja | Horizontale Position in pt | | `y` | ✅ Ja | Vertikale Position in pt | **Beispiel-JSON:** { "paraphImageId": "picture1", "width": 50, "height": 22, "x": 10, "y": 800 } ### ParaphenAppearance (eStamp) Die eStamp-`ParaphenAppearance` ist die **serverseitige Konfiguration des Paraphen-Erscheinungsbilds** (YAML). Sie ist analog zur `signatureAppearance`, aber für Paraphen. Verfügbare Paraphen-IDs werden über `GET /signApi/paraphenInfos` abgefragt. **Serverseitige YAML-Konfiguration (Beispiel):** estamp: paraphen-image: picture1: classpath:/paraphenImages/picture1.jpg picture2: classpath:/paraphenImages/picture2.png paraphen-appearance: paraphen1: classpath:/paraphenAppearance/paraphenAppearance1.json paraphen2: classpath:/paraphenAppearance/paraphenAppearance2.json *** ** * ** *** ## F -- Fehlercodes \& Betrieb Dieser Abschnitt erklärt alle HTTP-Statuscodes, Timeouts und Betriebskonzepte der eStamp REST-API. Für jede Fehlersituation sind Ursachen und konkrete Lösungsschritte angegeben. ### HTTP-Statuscodes (eStamp -- Übersicht) | **Code** | **Bedeutung** | **Typische Ursache** | |----------|-------------------------------|--------------------------------------------------------------------------------| | 200 | OK -- Anfrage erfolgreich | -- | | 400 | Bad Request | Ungültige `parameterId`, fehlende Pflichtfelder, falsches PDF-Format | | 401 | Unauthorized | Bearer Token fehlt, ungültig oder abgelaufen | | 403 | Forbidden | Falsche Authentifizierungsmethode | | 404 | Not Found | Falsche Base URL, unbekannte `sessionId`, Handler nicht gefunden | | 406 | Not Acceptable | Fehlerhafte Appearance-Konfiguration, Zertifikatsproblem | | 412 | Precondition Failed | Ungültige `sessionId` | | 413 | Payload Too Large | Datei überschreitet konfiguriertes Limit | | 415 | Unsupported Media Type | Falscher Content-Type (erwartet: `application/pdf`) | | 422 | Unprocessable Entity | Ungültiges oder beschädigtes PDF, fehlerhafte JSON-Konfiguration | | 429 | Too Many Requests | Dokumentlimit der Session erreicht (max. 100) oder zu viele parallele Requests | | 451 | Unavailable for Legal Reasons | JWT-Token abgelaufen | | 500 | Internal Server Error | Unerwarteter Systemfehler, Zertifikatsproblem, Infrastrukturproblem | ### HTTP 400 -- Bad Request (eStamp) Die eStamp-API gibt HTTP 400 zurück, wenn der Request ungültig ist. **Häufige Ursachen:** * `parameterId` existiert nicht → `GET /signApi/parameterInfos` aufrufen * Pflichtfelder in `signatureAppearance` fehlen * Ungültige Session-Operation (z.B. `addDocument` nach `seal`) **Lösungsschritte:** `parameterId` prüfen, JSON-Konfiguration gegen Pflichtfelder validieren. ### HTTP 401 -- Unauthorized (eStamp) Die eStamp-API gibt HTTP 401 zurück, wenn die Authentifizierung fehlschlägt. **Häufige Ursachen:** * `Authorization: Bearer `-Header fehlt im Request * Bearer Token ist abgelaufen (`expires_in` überschritten) * Token wurde mit falschen `client_id`/`client_secret`-Werten generiert **Lösungsschritte:** 1. Prüfen, ob der `Authorization`-Header korrekt gesetzt ist 2. `expires_in` aus der Token-Response prüfen und ggf. neuen Token anfordern 3. OAuth-Konfiguration (`issuer-uri`, `client-id`) verifizieren ### HTTP 404 -- Not Found (eStamp) Die eStamp-API gibt HTTP 404 zurück, wenn ein Endpunkt oder eine Ressource nicht gefunden wird. **Häufige Ursachen:** * Falsche Base URL oder falscher Endpunkt-Pfad * Unbekannte oder abgelaufene `sessionId` * `getDocument` vor `seal` aufgerufen **Lösungsschritte:** Base URL prüfen, Groß-/Kleinschreibung im Pfad prüfen, Session-Status prüfen. ### HTTP 422 -- Unprocessable Entity (eStamp) Die eStamp-API gibt HTTP 422 zurück, wenn das PDF-Dokument oder die JSON-Konfiguration ungültig ist. **Häufige Ursachen:** * PDF ist beschädigt oder kein gültiges PDF/A * Pflichtfelder in `signatureAppearance` fehlen * Unerlaubte Kombination von Sonderfällen (z.B. `VisualizationAutomation` + `signatureAttributes`) **Lösungsschritte:** 1. PDF mit `POST /signApi/validatePdf` validieren 2. JSON-Konfiguration gegen Pflichtfelder prüfen 3. Sonderfall-Kombination prüfen: `signatureFieldId` und `VisualizationAutomation` schließen sich gegenseitig aus ### HTTP 500 -- Internal Server Error (eStamp) Die eStamp-API gibt HTTP 500 zurück, wenn ein unerwarteter Systemfehler aufgetreten ist. **Mögliche Ursachen:** Infrastrukturproblem, Zertifikatsproblem, Signaturerstellung schlägt intern fehl. **Lösungsschritte:** Logs prüfen, Support kontaktieren unter [++servicedesk@xitrust.com++](mailto:servicedesk@xitrust.com) mit: Timestamp der Anfrage, Endpunkt, `sessionId` (falls vorhanden) und vollständigem HTTP-Statuscode. ### Timeout (eStamp) Die eStamp-API kennt zwei Zeitgrenzen, die häufig verwechselt werden: | **Zeitgrenze** | **Wert** | **Beschreibung** | |--------------------|---------------|-------------------------------------------------------------------------------------------------| | API-Call-Timeout | \~30 Sekunden | Maximale Dauer eines einzelnen API-Aufrufs. Bei Überschreitung: Abbruch + Fehlermeldung. | | Session-Gültigkeit | 40 Minuten | Gesamtgültigkeitsdauer einer Batch-Session. Nach Ablauf: Session ungültig, Prozess neu starten. | > \[!NOTE\] Ein Timeout bedeutet nicht, dass das Dokument beschädigt ist -- nur, dass der Request zu lange gedauert hat. ### Retry-Strategie (eStamp) Bei HTTP 429 (Too Many Requests) oder Timeout empfiehlt sich folgende Retry-Strategie für die eStamp-API: 1. Kurze Wartezeit einlegen: 2--5 Sekunden 2. Request erneut senden 3. Aggressive Parallelisierung vermeiden 4. Bei Batch-Verarbeitung: Requests staffeln > \[!TIP\] eStamp ist kein Streaming-System, sondern für kontrollierte, sequenzielle API-Aufrufe ausgelegt. ### sessionId (eStamp) Die eStamp-`sessionId` ist die **eindeutige Kennung einer Batch-Signing-Session** . Sie wird bei `POST /signApi/startSession` als JSON-String zurückgegeben und bei allen Folgeaufrufen als Pfadparameter verwendet (`/{sessionId}/addDocument` etc.). **Wichtig für Support-Anfragen:** Bei Problemen mit dem Batch-Workflow immer `sessionId`, Timestamp und HTTP-Statuscode bereithalten. *** ** * ** *** ## G -- Tools \& Hilfskonzepte Dieser Abschnitt erklärt unterstützende Tools und übergreifende Konzepte rund um die eStamp-API. ### Swagger (eStamp API-Testoberfläche) Swagger ist eine **interaktive API-Dokumentationsplattform** auf Basis der OpenAPI-Spezifikation, die das direkte Testen von eStamp-Endpunkten im Browser ermöglicht. Sie unterstützt den gesamten API-Entwicklungslebenszyklus von Design bis Test. **Swagger mit OAuth 2.0 verwenden:** 1. Swagger-UI der eStamp-Instanz öffnen 2. Auf **\[Authorize\]**-Button klicken 3. `client_id` und `client_secret` eingeben -- Bearer Token wird automatisch gesetzt 4. API-Aufrufe direkt ausführen ### Partial Failure (eStamp) eStamp unterstützt **kein Partial Failure**. Bei einem Batch-Vorgang gilt: Entweder werden alle Dokumente erfolgreich signiert, oder der gesamte Prozess schlägt fehl. Es gibt keine teilweise Verarbeitung einzelner Dokumente innerhalb einer Session. ### Backward Compatibility (eStamp) eStamp führt **keine Breaking Changes** durch. Bestehende Integrationen bleiben nach Updates weiterhin funktionsfähig. Es gibt keine Versionsabhängigkeiten, keine versteckten Systemkopplungen und keine komplizierten Upgrade-Szenarien. Die letzten 3 Versionen werden aktiv supportet. *** ** * ** *** **Bei Fragen kontatkieren Sie bitte unseren Support:** XiTrust Support Team \| [++servicedesk@xitrust.com++](mailto:servicedesk@xitrust.com) \| Service Desk Ticket erstellen --- version: "v1" language: "de" --- # eStamp: Workflow-Anleitungen für das Signieren und Validieren von PDF-Dokumenten **Inhalt** Dieses Dokument beschreibt die verfügbaren Workflow-Typen der eStamp REST-API und erklärt Schritt für Schritt, wie PDF-Dokumente signiert, versiegelt und validiert werden. Voraussetzung für alle Workflows: eine gültige eStamp Base URL und ein gültiger Bearer Token (siehe „eStamp: Aufbau, Nutzung und Authentifizierung"). *** ** * ** *** ## Übersicht: Welche Workflow-Typen gibt es? Die eStamp REST-API bietet zwei Haupt-Workflow-Typen für das Signieren von Dokumenten sowie einen separaten Workflow für die Validierung: **Synchroner Workflow (Single Request):** Ein einzelner API-Aufruf liefert sofort das signierte Dokument zurück. Geeignet für einzelne Dokumente ohne Zwischenspeicherung. Drei Varianten verfügbar: `sealSingle`, `sealSingleWithAppearance`, `sealSingleWithAppearanceParam`. **Session-basierter Workflow (Batch):** Mehrere Dokumente werden innerhalb einer Session verarbeitet. Läuft in mehreren Schritten ab: `startSession` → `addDocument` → `seal` → `getDocument` → `closeSession`. Geeignet für Batch-Verarbeitung von bis zu 100 Dokumenten pro Session. **Validierungs-Workflow:** Prüft die Signatur eines bestehenden PDF- oder XML-Dokuments und liefert einen Validierungsreport zurück. > \[!NOTE\] eStamp ist **kein asynchrones System**. Es gibt keine Hintergrundjobs, keine Status-Endpoints, kein Polling und keine Webhooks. Jeder API-Aufruf blockiert, bis er abgeschlossen ist, und liefert das Ergebnis direkt zurück. ## Workflow 1: Synchrones Signieren (Single Request) Der synchrone Signier-Workflow der eStamp REST-API verarbeitet ein einzelnes Dokument pro API-Aufruf und gibt das signierte Dokument sofort als Binary zurück. Es gibt keine Sessions, kein Zwischenspeichern und keinen Status zu prüfen. ### Variante 1a: Signieren ohne Visualisierung (`sealSingle`) Versiegelt ein PDF-Dokument ohne visuelle Signaturdarstellung im Dokument. # eStamp: PDF versiegeln ohne Signaturvisualisierung # Endpoint: POST /signApi/sealSingle # Authentifizierung: Bearer Token erforderlich # Rückgabe: signiertes PDF als Binary curl -X POST "https:///signApi/sealSingle" \ -H "Authorization: Bearer " \ -H "Content-Type: multipart/form-data" \ -F "parameterId=" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf **Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |------------------|--------------|-------------|------------------------------------------------------------------------------| | `parameterId` | string | Ja | ID des Signaturhandlers (verfügbare Werte via `GET /signApi/parameterInfos`) | | `documentToSign` | binary (PDF) | Ja | Das zu signierende PDF-Dokument | > \[!NOTE\] `documentToSign` und `file` sind synonyme Feldbezeichnungen mit identischer Bedeutung. Beide Varianten werden von der eStamp REST-API akzeptiert. ### Variante 1b: Signieren mit Signaturvisualisierung als Datei (`sealSingleWithAppearance`) Versiegelt ein PDF-Dokument und fügt eine visuelle Signaturdarstellung an der konfigurierten Position ein. Die Visualisierungskonfiguration wird als JSON-Datei übergeben. # eStamp: PDF versiegeln mit Signaturvisualisierung (Appearance als JSON-Datei) # Endpoint: POST /signApi/sealSingleWithAppearance # Authentifizierung: Bearer Token erforderlich # Rückgabe: signiertes PDF mit Visualisierung als Binary curl -X POST "https:///signApi/sealSingleWithAppearance" \ -H "Authorization: Bearer " \ -H "Content-Type: multipart/form-data" \ -F "parameterId=" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ -F "signatureAppearance=@./appearance.json;type=application/json" \ --output ./signiert.pdf **Beispiel** `appearance.json`**(Pflicht- und optionale Felder):** { "signatureImageId": "amtsSignatur", "lastPage": -1, "onEveryPage": false, "x": 100, "y": 100, "width": 400, "height": 270, "signaturePageId": "default" } ### Variante 1c: Signieren mit Signaturvisualisierung als ID (`sealSingleWithAppearanceParam`) Versiegelt ein PDF-Dokument mit einer serverseitig hinterlegten Visualisierungskonfiguration. Statt einer JSON-Datei wird nur die `appearanceId` als Query-Parameter übergeben. Die Konfiguration liegt serverseitig und muss nicht bei jedem Aufruf mitgesendet werden. # eStamp: PDF versiegeln mit Signaturvisualisierung (Appearance als serverseitige ID) # Endpoint: POST /signApi/sealSingleWithAppearanceParam # Authentifizierung: Bearer Token erforderlich # Rückgabe: signiertes PDF mit Visualisierung als Binary curl -X POST "https:///signApi/sealSingleWithAppearanceParam?appearanceId=" \ -H "Authorization: Bearer " \ -H "Content-Type: multipart/form-data" \ -F "parameterId=" \ -F "file=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf ## Signaturvisualisierung (`signatureAppearance`): Konfigurationsreferenz Die `signatureAppearance`-Konfiguration steuert, wie die Signatur optisch im PDF dargestellt wird -- Position, Größe, verwendetes Signaturbild und Seitenbereich. Die Konfiguration wird immer im JSON-Format übergeben. > \[!NOTE\] Die `signatureAppearance`-Konfiguration ist nur relevant, wenn die Endpoints `sealSingleWithAppearance` oder `addDocumentWithAppearance` verwendet werden. Für `sealSingle` ohne Visualisierung wird keine `signatureAppearance` benötigt. ### Pflichtfelder der `signatureAppearance` | **Feld** | **Typ** | **Beschreibung** | |--------------------|---------|----------------------------------------------------------------------------------| | `signatureImageId` | string | ID des serverseitig hinterlegten Signaturbilds | | `lastPage` | integer | Letzte Seite, auf der die Signatur erscheint (`-1` = letzte Seite des Dokuments) | | `onEveryPage` | boolean | `true`: Signatur auf jeder Seite im definierten Bereich; `false`: einmalig | | `x` | integer | Horizontale Position der Signatur auf der Seite (in Punkten, pt) | | `y` | integer | Vertikale Position der Signatur auf der Seite (in Punkten, pt) | ### Optionale Felder der `signatureAppearance` | **Feld** | **Typ** | **Standardwert** | **Beschreibung** | |-----------------------|---------|------------------|----------------------------------------------------------------------------------------------| | `signaturePageId` | string | -- | ID einer zusätzlichen Signaturseite, die ans Dokument angehängt wird | | `firstPage` | integer | -- | Erste Seite, auf der die Signatur erscheint | | `width` | integer | 400 | Breite der Signaturvisualisierung in pt | | `height` | integer | 270 | Höhe der Signaturvisualisierung in pt | | `signatureAttributes` | object | -- | Zusätzliche X.509-Zertifikatsattribute für die Darstellung (nur bei Amtssignaturen sinnvoll) | | `signatureFieldId` | string | -- | ID eines vorhandenen PDF-Signaturfelds; ersetzt manuelle Koordinatenangabe | > \[!WARNING\] `signaturePageId` und `onEveryPage: true` dürfen **nicht gleichzeitig** gesetzt werden. Diese Kombination führt zu einem `400 Bad Request`-Fehler. ### Sonderfall: Automatische Positionierung (`visualizationAutomation`) `visualizationAutomation` positioniert die Signaturvisualisierung automatisch am Ende des letzten Textzeichens der letzten Seite. Eine manuelle Koordinatenangabe entfällt. { "signatureImageId": "amtsSignatur", "signaturePageId": "default", "x": 100, "width": 400, "height": 250, "visualizationAutomation": { "footerHeight": 6, "margin": 10, "signaturePageMargin": 60 } } **Pflichtfelder innerhalb von** `visualizationAutomation`**:** | **Feld** | **Beschreibung** | |-----------------------|---------------------------------------------------------------------| | `footerHeight` | Höhe der Fußzeile in pt | | `margin` | Abstand zwischen letztem Textzeichen und Signaturbild in pt | | `signaturePageMargin` | Abstand zur Signaturseite, wenn eine neue Seite erzeugt wird, in pt | > \[!WARNING\] Bei Verwendung von `visualizationAutomation` gelten zwei Pflichtbedingungen: `signaturePageId` muss auf einen gültigen Wert gesetzt sein, und `signatureAttributes` darf **nicht** gesetzt sein. Die Kombination beider Sonderfälle (`visualizationAutomation` und `signatureAttributes`) ist nicht unterstützt. ### Sonderfall: Signatur in vorhandenes PDF-Signaturfeld platzieren Wenn ein PDF bereits Signaturfelder enthält, kann die Visualisierung direkt in ein vorhandenes Feld platziert werden. Koordinaten, Seitenangaben und Größe werden dann nicht benötigt. { "signatureImageId": "imageOnly", "signatureFieldId": "Signatur2" } Die folgenden Felder der `signatureAppearance` werden bei Verwendung von `signatureFieldId` **nicht** benötigt: `firstPage`, `lastPage`, `onEveryPage`, `x`, `y`, `width`, `height`. Um die vorhandenen Signaturfeld-IDs eines PDF-Dokuments abzufragen, verwenden Sie folgenden Endpoint: # eStamp: Signaturfeld-IDs eines PDFs abfragen # Endpoint: POST /signApi/signatureFieldNames # Rückgabe: JSON-Liste der Signaturfeld-IDs im Dokument curl -X POST "https:///signApi/signatureFieldNames" \ -H "Authorization: Bearer " \ -F "document=@./eingabe.pdf;type=application/pdf" ## Workflow 2: Session-basiertes Signieren (Batch) Der session-basierte Signier-Workflow der eStamp REST-API verarbeitet mehrere Dokumente innerhalb einer Session. Der Ablauf ist mehrstufig und muss in der angegebenen Reihenfolge ausgeführt werden. **Vollständiger Ablauf:** POST /startSession → POST /{sessionId}/addDocument (1--100 Mal) → POST /{sessionId}/seal → GET /{sessionId}/getDocument/{documentId} (für jedes Dokument) → POST /{sessionId}/closeSession > \[!WARNING\] Die Reihenfolge der Session-Schritte ist **zwingend einzuhalten** . Ein `getDocument`-Aufruf vor `seal` gibt einen `404 Not Found`-Fehler zurück. Ein `addDocument`-Aufruf nach `seal` gibt einen `400 Bad Request`-Fehler zurück. ### Schritt 1: Session starten (`startSession`) # eStamp: Batch-Signing-Session starten # Endpoint: POST /signApi/startSession # Rückgabe: sessionId als JSON-String curl -X POST "https:///signApi/startSession" \ -H "Authorization: Bearer " \ -H "Content-Type: multipart/form-data" \ -F "parameterId=" **Erfolgreiche Antwort (200 OK):** "a1b2c3d4-e5f6-7890-abcd-ef1234567890" Die zurückgegebene `sessionId` ist bei allen Folgeaufrufen als Pfadparameter erforderlich. ### Schritt 2: Dokumente hinzufügen (`addDocument`) # eStamp: Dokument zur Session hinzufügen # Endpoint: POST /signApi/{sessionId}/addDocument # Rückgabe: documentId als Integer (JSON) # Dieser Schritt wird für jedes Dokument einzeln wiederholt (max. 100 pro Session) curl -X POST "https:///signApi//addDocument" \ -H "Authorization: Bearer " \ -F "documentToSign=@./dokument1.pdf;type=application/pdf" **Erfolgreiche Antwort (200 OK):** 1 Die zurückgegebene `documentId` wird in Schritt 4 (`getDocument`) benötigt. Für jedes hinzugefügte Dokument wird eine eigene `documentId` vergeben. > \[!NOTE\] Einmal hinzugefügte Dokumente können innerhalb einer Session **nicht ersetzt oder entfernt** werden. Wenn ein falsches Dokument hinzugefügt wurde, muss eine neue Session gestartet werden. Alternativ stehen folgende `addDocument`-Varianten zur Verfügung: | **Endpoint** | **Verwendung** | |-----------------------------------------------|------------------------------------------------------------------| | `/{sessionId}/addDocument` | Dokument ohne Visualisierung hinzufügen | | `/{sessionId}/addDocumentWithAppearance` | Dokument mit `signatureAppearance` als JSON-Datei hinzufügen | | `/{sessionId}/addDocumentWithAppearanceParam` | Dokument mit serverseitig hinterlegter `appearanceId` hinzufügen | ### Schritt 3: Alle Dokumente versiegeln (`seal`) # eStamp: Alle Dokumente der Session versiegeln # Endpoint: POST /signApi/{sessionId}/seal # Rückgabe: kein Body (leere 200-Antwort) # Timeout: 60--120 Sekunden für den gesamten Seal-Vorgang curl -X POST "https:///signApi//seal" \ -H "Authorization: Bearer " Der `seal`-Aufruf blockiert, bis alle Dokumente der Session signiert sind, und gibt keine Inhaltsdaten zurück. Die signierten Dokumente werden anschließend über `getDocument` abgerufen. ### Schritt 4: Signierte Dokumente abrufen (`getDocument`) # eStamp: Signiertes Dokument aus Session abrufen # Endpoint: GET /signApi/{sessionId}/getDocument/{documentId} # Rückgabe: signiertes PDF als Binary # Dieser Schritt wird für jede documentId einzeln ausgeführt curl -X GET "https:///signApi//getDocument/" \ -H "Authorization: Bearer " \ --output ./signiert-dokument1.pdf ### Schritt 5: Session schließen (`closeSession`) # eStamp: Batch-Signing-Session schließen # Endpoint: POST /signApi/{sessionId}/closeSession # Rückgabe: kein Body curl -X POST "https:///signApi//closeSession" \ -H "Authorization: Bearer " > \[!NOTE\] Nicht manuell geschlossene eStamp-Sessions werden nach **40 Minuten** automatisch bereinigt. Eine Session, die 40 Minuten überschreitet, gibt bei Folgeaufrufen den Fehler `412 Precondition Failed` (Illegal session id) zurück. ## Workflow 3: Signaturvalidierung Der Validierungs-Workflow der eStamp REST-API prüft die Signatur eines bestehenden PDF- oder XML-Dokuments und gibt einen Validierungsreport zurück. ### PDF-Signatur validieren # eStamp: PDF-Signatur validieren # Endpoint: POST /signApi/validatePdf # Parameter reportType: "xml" (Standard) oder "pdf" # Rückgabe: Validierungsreport als XML oder PDF Binary curl -X POST "https:///signApi/validatePdf" \ -H "Authorization: Bearer " \ -F "reportType=xml" \ -F "file=@./signiert.pdf;type=application/pdf" \ --output ./validierungsreport.xml ### XML-Signatur validieren # eStamp: XML-Signatur validieren # Endpoint: POST /xmlSignApi/validateXml # Parameter reportType: "xml" (Standard) oder "pdf" # Rückgabe: Validierungsreport als XML oder PDF Binary curl -X POST "https:///xmlSignApi/validateXml" \ -H "Authorization: Bearer " \ -F "reportType=pdf" \ -F "file=@./signiert.xml" \ --output ./validierungsreport.pdf **Verfügbare** `reportType`**-Werte:** | **Wert** | **Rückgabeformat** | |------------------|------------------------| | `xml` (Standard) | XML-Validierungsreport | | `pdf` | PDF-Validierungsreport | ## FAQ: Workflows und häufige Fragen ### Was ist der Unterschied zwischen synchronem und session-basiertem Workflow? Der synchrone Workflow der eStamp REST-API verarbeitet ein einzelnes Dokument pro API-Aufruf und gibt das Ergebnis sofort zurück --- keine Sessions, kein Zwischenspeichern. Der session-basierte Workflow ermöglicht die Batch-Verarbeitung von bis zu 100 Dokumenten pro Session in einem mehrstufigen Ablauf. Für einzelne Dokumente ist der synchrone Workflow einfacher; für Stapelverarbeitung ist der session-basierte Workflow notwendig. ### Wie viele Dokumente können pro Session verarbeitet werden? Pro eStamp-Batch-Session können maximal **100 Dokumente** verarbeitet werden. Wenn mehr als 100 Dokumente signiert werden müssen, sind mehrere Sessions zu starten. Die Anzahl der parallel laufenden Sessions ist nicht limitiert. ### Wie lange ist eine eStamp-Session gültig? Eine eStamp-Batch-Session ist **40 Minuten** ab dem `startSession`-Aufruf gültig. Nicht abgeschlossene Sessions werden nach 40 Minuten automatisch bereinigt. Ein einzelner API-Aufruf innerhalb einer Session darf maximal **30 Sekunden** dauern; bei Überschreitung wird der Call abgebrochen. ### Kann ich den Fortschritt eines laufenden `seal`-Aufrufs abfragen? Nein. eStamp bietet keine Status-Endpoints, kein Polling und keine Webhooks. Der `seal`-Aufruf blockiert, bis alle Dokumente der Session signiert sind (maximal 60--120 Sekunden), und gibt danach eine leere 200-Antwort zurück. ### Kann ich Dokumente nach dem Hinzufügen aus einer Session entfernen? Nein. Einmal zur Session hinzugefügte Dokumente können weder entfernt noch ersetzt werden. Wenn ein falsches Dokument hinzugefügt wurde, muss eine neue eStamp-Session über `startSession` gestartet werden. ### Gibt es Partial Failure bei der Session-Verarbeitung? Nein. eStamp unterstützt kein Partial Failure. Ein Batch-Vorgang ist entweder vollständig erfolgreich oder schlägt vollständig fehl. Es gibt keine teilweise Verarbeitung einzelner Dokumente innerhalb einer Session. ### Was passiert, wenn eine Session abläuft oder ein Timeout auftritt? Bei Ablauf der 40-Minuten-Session-Gültigkeit gibt eStamp bei Folgeaufrufen `412 Precondition Failed` zurück. Bei Timeout eines einzelnen API-Aufrufs (30 Sekunden) wird der Call abgebrochen und eine Fehlermeldung zurückgegeben. In beiden Fällen erfolgt keine teilweise Verarbeitung. Abgelaufene Sessions werden automatisch bereinigt. --- version: "v1" language: "en" --- # eStamp Dokumentation ## eStamp Dokumentation ### Documentation * #### [eStamp Glossary: Terms and concepts related to document signing](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-glossar-begriffe-und-konzepte-der-dokumente.md) * #### [eStamp: Structure, use, and authentication for PDF signatures](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-aufbau-nutzung-und-authentifizierung-fur-pd.md) * #### [eStamp: Workflow instructions for signing and validating PDF documents](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-workflow-anleitungen-fur-das-signieren-und-.md) * #### [eStamp: FAQs about authentication, workflows, limits, and error codes](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-faq-zu-authentifizierung-workflows-limits-u.md) * #### [eStamp: API-reference and endpoint-catalogue](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-api-referenz-und-endpunkt-katalog.md) --- version: "v1" language: "en" --- # eStamp: API-reference and endpoint-catalogue **Content** This document is the complete technical reference for all eStamp REST API endpoints. It describes the parameters, return values, and special features of each endpoint. Prerequisites for all calls: a valid, customer-specific eStamp base URL and a valid bearer token. All endpoints use the base path `/signApi/...` respectively `/xmlSignApi/...`. For an introduction to workflows and process logic, see "eStamp: Workflow instructions for signing and validating PDF documents." *** ** * ** *** ## Configuration and Discovery These eStamp endpoints provide information about the configuration of the current eStamp instance. They are the recommended starting point for any new integration. ### GET /signApi/parameterInfos Returns the list of all configured signature handlers for the eStamp instance. The `parameterId`values from this response are mandatory parameters for all Seal endpoints. **Authentication:** Bearer token required # eStamp: Query available signature handlers # Endpoint: GET /signApi/parameterInfos # Return: JSON array of all configured signature handlers curl -X GET "https:///signApi/parameterInfos" \ -H "Authorization: Bearer " **Erfolgreiche Antwort (200 OK):** [ { "parameterId": "amtssignatur", "displayName": "Amtssignatur", "maxNumberOfDocuments": 100, "signatureHandlerType": "SOFTWARE_KEY" } ] **Antwortfelder:** | **Field** | **Type** | **Description** | |------------------------|----------|-----------------------------------------------------------------------------------| | `parameterId` | string | Mandatory parameter for all Seal calls; uniquely identifies the signature handler | | `displayName` | string | Readable name of the signature handler | | `maxNumberOfDocuments` | integer | Maximum number of documents per session for this handler | | `signatureHandlerType` | string | Technical type of the signature handler (e.g. `SOFTWARE_KEY`) | > \[!NOTE\] The listed `parameterId` values are instance-specific. Only those parameters that are stored in the configuration of the eStamp instance are listed. Deprecated parameters are not marked separately. ### GET /signApi/signatureAppearanceInfos Returns the mapping of all server-side stored appearance IDs to their `signatureAppearance`configuration. This endpoint is used to query available `appearanceId` values for the endpoints `sealSingleWithAppearanceParam` and `addDocumentWithAppearanceParam` endpoints. **Authentication:** Bearer token required # eStamp: Query available appearance configurations # Endpoint: GET /signApi/signatureAppearanceInfos # Return: JSON mapping of appearance IDs to signatureAppearance configurations curl -X GET "https:///signApi/signatureAppearanceInfos" \ -H "Authorization: Bearer " > \[!NOTE\] Server-side appearance configurations are stored in the eStamp instance as YAML and reference JSON configuration files. They are managed by the XiTrust support team during deployment. **Successful Response (200 OK):** json { "appearance1": { "signatureImageId": "amtsSignatur", "signaturePageId": "default", "lastPage": -1, "onEveryPage": false, "x": 100, "y": 100, "width": 400, "height": 270 }, "appearance2": { "signatureImageId": "imageOnly", "signatureFieldId": "Signatur2" } } ### GET /signApi/paraphenInfos Returns the mapping of all server-side stored Paraphen IDs to their `ParaphenAppearance` configuration. This endpoint is used to query available `paraphImageId` and `paraphenAppearanceId` values. **Authentication:** Bearer token required # eStamp: Query available initials configurations # Endpoint: GET /signApi/paraphenInfos # Return: JSON mapping of initials IDs to ParaphenAppearance configurations curl -X GET "https:///signApi/paraphenInfos" \ -H "Authorization: Bearer " **Successful response (200 OK):** json { "paraphen1": { "paraphImageId": "picture1", "x": 10, "y": 800, "width": 50, "height": 22 }, "paraphen2": { "paraphImageId": "picture2", "x": 20, "y": 750, "width": 50, "height": 22 } } *** ** * ** *** ## Synchronous Seal Endpoints (Single Document) The synchronous eStamp Seal endpoints seal a single PDF document per call and return the signed document directly as a binary. No sessions are required. ### POST /signApi/sealSingle Seals a single PDF document without signature visualization (see *Figure 1*). The simplest eStamp seal endpoint. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** Signed PDF as binary (`application/pdf`); file name in response header # eStamp: Seal PDF without visualization # Endpoint: POST /signApi/sealSingle # Return: Signed PDF as binary curl -X POST "https:///signApi/sealSingle" \ -H "Authorization: Bearer " \ -H "accept: application/pdf" \ -F "parameterId=amtssignatur" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf **Request-Parameter:** | **Parameter** | **Type** | **Mandatory** | **Description** | |------------------|--------------|---------------|---------------------------------------------------------------------------------| | `parameterId` | string | Yes | ID of the signature handler; available values via `GET /signApi/parameterInfos` | | `documentToSign` | binary (PDF) | Yes | The PDF document to be sealed | | `paraphenImage` | JSON | No | Paraphen configuration; placed on defined pages as a small signature image | > \[!NOTE\] `documentToSign` and `file` are synonymous field names with identical meanings. Both variants are accepted by the eStamp REST API. **Successful Response (200 OK):** [Sig_OhneVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_3836c3b54719422e3174964f636f6cb3126b55d0874469d73d364c63dd269a9b/Sig_OhneVisualisierung.pdf.md?cb=d9b514367de89d9984a125969a7976d4) *Figure 1: The result is a PDF document without a visual signature display (click on the file to view the result)* ### POST /signApi/sealSingleWithAppearance Seals a single PDF document and inserts a visual signature representation. The `signatureAppearance` configuration is sent as a JSON file in the request. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** Signed PDF with visualization as binary (`application/pdf`) # eStamp: Seal PDF with signature visualization (appearance as JSON file) # Endpoint: POST /signApi/sealSingleWithAppearance # Return: Signed PDF with visualization as binary curl -X POST "https:///signApi/sealSingleWithAppearance" \ -H "Authorization: Bearer " \ -H "accept: application/pdf" \ -F "parameterId=amtssignatur" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ -F "signatureAppearance=@./appearance.json;type=application/json" \ --output ./signiert.pdf **Request-Parameter:** | **Parameter** | **Type** | **Mandatory** | **Description** | |-----------------------|--------------|---------------|--------------------------------------------------------------------------------| | `parameterId` | string | Yes | ID of the signature handler | | `documentToSign` | binary (PDF) | Yes | The PDF document to be sealed | | `signatureAppearance` | JSON-Datei | Yes | Configuration of the signature visualization (position, size, signature image) | | `paraphenImage` | JSON | No | Initials configuration | **Successful Response (200 OK):** [Sig_MitVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_de862cfd4e70576bead06704a41e952dd297faf3db470a5a1e4a6b8b6a30c1be/Sig_MitVisualisierung.pdf.md?cb=b35ae91c35846c67bd3f6af0f51b5ee3) *Figure 2: The result is a PDF document with a visual representation of the signature (click on the file to view the result).* ### POST /signApi/sealSingleWithAppearanceParam Seals a single PDF document with a visualization configuration stored on the server (see *figure 3* ). Instead of a JSON file, the `appearanceId` is passed as a query parameter. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** Signed PDF with visualization as binary (`application/pdf`) # eStamp: Seal PDF with server-side appearance ID # Endpoint: POST /signApi/sealSingleWithAppearanceParam # appearanceId: Query parameter (configured on the server side) # Return: Signed PDF as binary curl -X POST "https:///signApi/sealSingleWithAppearanceParam?appearanceId=" \ -H "Authorization: Bearer " \ -H "accept: application/pdf" \ -F "parameterId=amtssignatur" \ -F "file=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf **Request-Parameter:** | **Parameter** | **Handover** | **Mandatory** | **Description** | |------------------------|--------------------|---------------|--------------------------------------------------------------| | `appearanceId` | Query-Parameter | Yes | ID of the appearance configuration stored on the server side | | `parameterId` | Form-Field | Yes | Signature handler ID | | `file` | Form-Field, binary | Yes | The PDF document to be sealed | | `paraphenAppearanceId` | Query-Parameter | No | ID of the initials configuration stored on the server side | **Successful Response (200 OK):** [Sig_MitVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_de862cfd4e70576bead06704a41e952dd297faf3db470a5a1e4a6b8b6a30c1be/Sig_MitVisualisierung.pdf.md?cb=b35ae91c35846c67bd3f6af0f51b5ee3) [Sig_MitVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_de862cfd4e70576bead06704a41e952dd297faf3db470a5a1e4a6b8b6a30c1be/Sig_MitVisualisierung.pdf.md?cb=b35ae91c35846c67bd3f6af0f51b5ee3) *Figure 3: The result is a PDF document with a visual representation of the signature (click on the file to view the result).* *** ** * ** *** ## Session-based seal endpoints (batch) The session-based eStamp endpoints process multiple documents in a multi-step session. The order of the calls must be strictly adhered to: `startSession` → `addDocument` → `seal` → `getDocument` → `closeSession`. ### POST /signApi/startSession Starts a new eStamp batch signing session and returns the `sessionId` which is used as a path parameter in all subsequent calls. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** `sessionId` as JSON-String # eStamp: Start batch signing session # Endpoint: POST /signApi/startSession # Return: sessionId as JSON string curl -X POST "https:///signApi/startSession" \ -H "Authorization: Bearer " \ -F "parameterId=amtssignatur" **Successful Response (200 OK):** "a1b2c3d4-e5f6-7890-abcd-ef1234567890" **Request-Parameter:** | **Parameter** | **Type** | **Mandatory** | **Beschreibung** | |---------------|----------|---------------|---------------------------------------------------------------| | `parameterId` | string | Yes | ID of the signature handler for all documents in this session | **Fehlercodes:** | **Code** | **Error message** | **Cause** | |----------|--------------------------|-----------------------------------------------------------------------| | 404 | `Parameter id not found` | Specified`parameterId` does not exist in the eStamp instance | | 404 | `No trust center found` | No suitable trust center service configured (e.g., Swisscom, A-Trust) | ### POST /signApi/{sessionId}/addDocument FAdds a document to the existing eStamp session. Returns a `documentId` that is required for `getDocument`. Can be called up to 100 times per session. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** `documentId` as integer (JSON) # eStamp: Add document to session # Endpoint: POST /signApi/{sessionId}/addDocument # Return: documentId as integer curl -X POST "https:///signApi//addDocument" \ -H "Authorization: Bearer " \ -F "documentToSign=@./dokument.pdf;type=application/pdf" **Successful Response (200 OK):** 1 **Request-Parameter:** | **Parameter** | **Type** | **Mandatory** | **Description** | |------------------|--------------|---------------|------------------------------------------| | `documentToSign` | binary (PDF) | Yes | The PDF document to be added | | `paraphenImage` | JSON | No | Paraphen configuration for this document | **Error codes:** | **Code** | **Error message** | **Cause** | |----------|--------------------------------------|------------------------------------------------------------| | 412 | `Illegal session id` | Invalid or expired `sessionId` | | 400 | `Illegal operation in current state` | Incorrect session state (e. g. `addDocument` after `seal`) | | 400 | `Cannot load PDF Document` | Document is not a valid PDF | | 429 | `Document limit reached` | 100-document limit for the session reached | | 400 | `Error adding signature page` | Error adding a signature page | | 406 | `Failed to render image` | Signature image could not be rendered | > \[!NOTE\] Documents added to a session cannot be removed or replaced. If a document is added incorrectly, a new session must be started via `POST /signApi/startSession`. ### POST /signApi/{sessionId}/addDocumentWithAppearance Adds a document with a `signatureAppearance` configuration to the eStamp session. The visualization configuration is passed as a JSON file. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** `documentId` as integer (JSON) # eStamp: Add document with appearance configuration to session # Endpoint: POST /signApi/{sessionId}/addDocumentWithAppearance curl -X POST "https:///signApi//addDocumentWithAppearance" \ -H "Authorization: Bearer " \ -F "documentToSign=@./dokument.pdf;type=application/pdf" \ -F "signatureAppearance=@./appearance.json;type=application/json" **Request-Parameter:** | **Parameter** | **Type** | **Mandatory** | **Description** | |-----------------------|--------------|---------------|------------------------------------------| | `documentToSign` | binary (PDF) | Yes | The PDF document to be added | | `signatureAppearance` | JSON-Datei | Yes | Signature visualization configuration | | `paraphenImage` | JSON | No | Paraphen configuration for this document | **Successful Response (200 OK):** json 2 ### POST /signApi/{sessionId}/addDocumentWithAppearanceParam Adds a document with a server-side stored appearance ID to the eStamp session. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** `documentId` as integer (JSON) # eStamp: Add document with server-side appearance ID to session # Endpoint: POST /signApi/{sessionId}/addDocumentWithAppearanceParam curl -X POST "https:///signApi//addDocumentWithAppearanceParam?appearanceId=" \ -H "Authorization: Bearer " \ -F "file=@./dokument.pdf;type=application/pdf" **Request-Parameter:** | **Parameter** | **Handover** | **Mandatory** | **Description** | |------------------------|-------------------|---------------|--------------------------------------------------------------| | `appearanceId` | Query-Parameter | Yes | ID of the appearance configuration stored on the server side | | `file` | Form-Feld, binary | Yes | The PDF document to be added | | `paraphenAppearanceId` | Query-Parameter | No | ID of the initials configuration stored on the server side | **Error codes:** | **Code** | **Error message** | **Cause** | |----------|-----------------------------------------|-------------------------------------------------| | 404 | `Cannot find paraphen appearance by id` | Specified `paraphenAppearanceId` does not exist | ### POST /signApi/{sessionId}/seal Triggers the signing of all documents added to the eStamp session. The call blocks until all documents are signed (maximum 60--120 seconds). Does not return a body. **Authentication:** Bearer token required **Return:** No body (empty 200 response) # eStamp: Seal all documents in the session # Endpoint: POST /signApi/{sessionId}/seal # Return: no body (empty 200 response if successful) curl -X POST "https:///signApi//seal" \ -H "Authorization: Bearer " **Error messages:** | **Code** | **Error message** | **Cause** | |----------|-----------------------------------|---------------------------------------------------| | 406 | `An error occurred while sealing` | General signing error (e.g., certificate problem) | | 500 | `Could not write data to CSV` | Internal system error during logging | > \[!WARNING\] `getDocument` may only be called after a successful `seal` call. A`getDocument` call before `seal` returns `404 Not Found`. ### GET /signApi/{sessionId}/getDocument/{documentId} Retrieves a single signed document from the eStamp session. Must be called separately for each `documentId` (see *figure* *4*). **Authentication:** Bearer token required **Return:** Signed PDF as binary (`application/pdf`); file name in response header # eStamp: Retrieve signed document from session # Endpoint: GET /signApi/{sessionId}/getDocument/{documentId} # Return: signed PDF as binary curl -X GET "https:///signApi//getDocument/" \ -H "Authorization: Bearer " \ --output ./signiert-dokument.pdf **Error messages:** | **Code** | **Error message** | **Cause** | |----------|-----------------------------|-----------------------------------------------------------| | 404 | `Document for id not found` | Invalid`documentId` or `getDocument` called before `seal` | **Successful Response (200 OK):** json ``` ``` [Sig_OhneVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_3836c3b54719422e3174964f636f6cb3126b55d0874469d73d364c63dd269a9b/Sig_OhneVisualisierung.pdf.md?cb=d9b514367de89d9984a125969a7976d4) [Sig_MitVisualisierung.pdf](https://documentation.moxis.co/__attachments/a_de862cfd4e70576bead06704a41e952dd297faf3db470a5a1e4a6b8b6a30c1be/Sig_MitVisualisierung.pdf.md?cb=b35ae91c35846c67bd3f6af0f51b5ee3) *Figure 4: Depending on what is retrieved, the result is either a PDF document with or without a visual signature display. (You can view the result by clicking on the files.)* ### POST /signApi/{sessionId}/closeSession Ends an eStamp batch signing session and releases all associated resources. Does not return a body. **Authentication:** Bearer token required **Return:** No body # eStamp: Close batch signing session # Endpoint: POST /signApi/{sessionId}/closeSession # Return: no body curl -X POST "https:///signApi//closeSession" \ -H "Authorization: Bearer " > \[!NOTE\] eStamp sessions that are not closed manually are automatically cleaned up after **40 minutes** . However, manual closure using `closeSession` is still recommended in order to free up resources immediately. **Successful Response (200 OK)** *** ** * ** *** ## Signature field endpoints ### POST /signApi/signatureFieldNames Returns the IDs of all existing signature fields in a PDF document. Used to determine `signatureFieldId` values for the `signatureAppearance`configuration. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** JSON array of signature field IDs # eStamp: Query signature field IDs of a PDF # Endpoint: POST /signApi/signatureFieldNames # Return: JSON array of signature field IDs in the document curl -X POST "https:///signApi/signatureFieldNames" \ -H "Authorization: Bearer " \ -F "document=@./eingabe.pdf;type=application/pdf" **Example-Response (200 OK):** ["Signatur1", "Signatur2", "Signatur3"] The returned values can be used directly as `signatureFieldId` in the `signatureAppearance`-configuration. If `signatureFieldId` is set, `x`, `y`, `width`, `height`, `firstPage`, `lastPage` and `onEveryPage` are not required. *** ** * ** *** ## Validation endpoints ### POST /signApi/validatePdf Validates the signature of an existing PDF document and returns a validation report. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** Validation report as XML or PDF binary; file name in response header # eStamp: Validate PDF signature # Endpoint: POST /signApi/validatePdf # reportType: "xml" (default) or "pdf" # Return: Validation report as XML or PDF binary curl -X POST "https:///signApi/validatePdf" \ -H "Authorization: Bearer " \ -F "reportType=xml" \ -F "file=@./signiert.pdf;type=application/pdf" \ --output ./validierungsreport.xml **Request-Parameter:** | **Parameter** | **Type** | **Mandatory** | **Default value** | **Description** | |---------------|--------------|---------------|-------------------|-------------------------------------------------| | `file` | binary (PDF) | Yes | -- | The PDF document to be validated | | `reportType` | string | No | `xml` | Format of the validation report: `xml` or `pdf` | **Successful Response:** If the reportType is a **pdf** , then the return value looks like this: [xmlReport.pdf](https://documentation.moxis.co/__attachments/a_581e5e3905acf9d48d9813a72c212c8538dc4517657d7a33ef3996dbc71bdf9e/xmlReport.pdf.md?cb=3aa10df0a2c5e71a08d7de31ffe42b53) ### POST /xmlSignApi/validateXml Validates the signature of an existing XML document and returns a validation report. **Authentication:** Bearer token required **Content-Type:** `multipart/form-data` **Return:** Validation report as XML or PDF binary # eStamp: Validate XML signature # Endpoint: POST /xmlSignApi/validateXml # reportType: "xml" (default) or "pdf" # Return: Validation report as XML or PDF binary curl -X POST "https:///xmlSignApi/validateXml" \ -H "Authorization: Bearer " \ -F "reportType=pdf" \ -F "file=@./signiert.xml" \ --output ./validierungsreport.pdf **Request-Parameter:** | **Parameter** | **Type** | **Mandatory** | **Default value** | **Description** | |---------------|--------------|---------------|-------------------|-------------------------------------------------| | `file` | binary (XML) | Yes | -- | The XML document to be validated | | `reportType` | string | No | `xml` | Format of the validation report: `xml` or `pdf` | **Successful Response:** If the reportType is **xml** , then the return value looks like this: [xmlReport.xml](https://documentation.moxis.co/__attachments/a_7040b3e280cd699062940b39efd0a33422f365b547d8f89f45aa15013b154008/xmlReport.xml.md?cb=12e13933e1f2e10663886564ac388c3a) *** ** * ** *** ## signatureAppearance: complete field reference The `signatureAppearance` configuration controls the visual appearance of the signature in the PDF. It is always transferred in JSON format --- either as a file or as a server-side configuration (referenced via `appearanceId`). ### Mandatory fields | **Field** | **Type** | **Description** | |--------------------|----------|------------------------------------------------------------| | `signatureImageId` | string | ID of the signature image stored on the server side | | `lastPage` | integer | Last page with signature; `-1` = last document page | | `onEveryPage` | boolean | `true`: Signature on every page in the area; `false`: once | | `x` | integer | Horizontal position in pt | | `y` | integer | ertical position in pt | ### Optional Fields | **Field** | **Type** | **Default value** | **Description** | |---------------------------|----------|-------------------|----------------------------------------------------------------------------------------| | `firstPage` | integer | -- | First page with signature; together with `lastPage` this results in the signature area | | `width` | integer | 400 | Width of the visualization in pt | | `height` | integer | 270 | Height of the visualization in pt | | `signaturePageId` | string | -- | ID of an additional signature page that is appended to the document | | `signatureFieldId` | string | -- | ID of an existing PDF signature field; replaces all coordinate and page information | | `signatureAttributes` | object | -- | Additional X.509 certificate attributes for display (only for official signatures) | | `visualizationAutomation` | object | -- | Automatic positioning at the end of the last text character | ### Supported signatureAttributes (X.509) | **Key** | **Displayed information** | |------------------------------------|-------------------------------------------------| | `subjectDn` | Certificate holder (Subject Distinguished Name) | | `issuerDn` | Certificate issuer | | `notBefore` | Valid from (creation date) | | `notAfter` | Valid until (expiration date) | | `serialNumber` | Serial number of the certificate | | `sigAlgName` | Signature algorithm | | `sigAlgOID` | OID of the signature algorithm | | `version` | Certificate version | | `type` | Certificate type | | `signatureDate?datetime?iso_utc` | Signature date (UTC, ISO format) | | `signatureDate?datetime?iso_local` | Signature date (local time, ISO format) | > \[!NOTE\] The left value (e. g. `subjectDn`) is the technically fixed key. The right value (e. g. `"Subject"`) is the freely selectable display text in the visualization. > \[!WARNING\] The following field combinations in `signatureAppearance` are **not supported** and will result in errors: `signaturePageId` together with `onEveryPage: true` (`400 Bad Request`), and `visualizationAutomation` together with `signatureAttributes` (unsupported combination). ### visualizationAutomation: Mandatory fields When `visualizationAutomation` is set, eStamp automatically positions the signature visualization at the end of the last text character on the last page. The following three fields are mandatory within the`visualizationAutomation` block: | **Field** | **Type** | **Description** | |-----------------------|----------|----------------------------------------------------------------| | `footerHeight` | integer | Height of footer in pt | | `margin` | integer | Distance between last text character and signature image in pt | | `signaturePageMargin` | integer | Distance to signature page when a new page is created, in pt | > \[!WARNING\] When using `visualizationAutomation`, `signaturePageId` must be set to a valid value. `signatureAttributes` must not be set at the same time. ## paraphenImage: Field reference The initials configuration controls the display of a small signature image (initials) on defined pages of the document. It is passed as an optional JSON parameter to seal endpoints. ### Mandatory fields | **Field** | **Type** | **Description** | |-----------------|----------|----------------------------------------------| | `paraphImageId` | string | ID of the initial image stored on the server | | `width` | integer | Width of the initial in pt | | `height` | integer | Height of the initial in pt | | `x` | integer | Horizontal position of the initial in pt | | `y` | integer | Vertical position of the initial in pt | **Example configuration:** { "paraphImageId": "picture1", "width": 50, "height": 22, "x": 10, "y": 800 } ## Endpoint overview All eStamp REST API endpoints at a glance: | **Methode** | **Endpoint** | **Description** | |-------------|-------------------------------------------------------|---------------------------------------------| | GET | `/signApi/parameterInfos` | Query available signature handlers | | GET | `/signApi/signatureAppearanceInfos` | Query server-side appearance configurations | | GET | `/signApi/paraphenInfos` | Query server-side initials configurations | | POST | `/signApi/sealSingle` | Seal individual PDF (without visualization) | | POST | `/signApi/sealSingleWithAppearance` | Seal individual PDF (appearance as file) | | POST | `/signApi/sealSingleWithAppearanceParam` | Seal individual PDF (appearance as ID) | | POST | `/signApi/startSession` | Start batch session | | POST | `/signApi/{sessionId}/addDocument` | Add document to session | | POST | `/signApi/{sessionId}/addDocumentWithAppearance` | Add document with appearance file | | POST | `/signApi/{sessionId}/addDocumentWithAppearanceParam` | Add document with appearance ID | | POST | `/signApi/{sessionId}/seal` | Seal all session documents | | GET | `/signApi/{sessionId}/getDocument/{documentId}` | Retrieve signed document | | POST | `/signApi/{sessionId}/closeSession` | Close session | | POST | `/signApi/signatureFieldNames` | Query signature field IDs of a PDF | | POST | `/signApi/validatePdf` | Validate PDF signature | | POST | `/xmlSignApi/validateXml` | Validate XML signature | --- version: "v1" language: "en" --- # eStamp: Structure, use, and authentication for PDF signatures **Content** eStamp is a service provided by XiTrust for automatically signing and sealing documents via a REST API or a web client. This document describes basic concepts, deployment options, authentication methods, and a quick start guide for new integration teams. *** ** * ** *** ## What is eStamp? eStamp is a service that automatically signs or seals PDF documents (and XML files). The process is always the same: 1. The calling system sends a document to the eStamp REST API. 2. eStamp signs or seals the document with the configured certificate. 3. The signed document is returned directly as a response. eStamp is designed for organizations that need to sign many documents automatically and in compliance with legal requirements---without manual intervention. Typical areas of application include government agencies (notices, official signatures), insurance companies (policies, confirmations), and financial service providers (automatically generated contract documents). ## Deployment options for eStamp eStamp can be operated in two ways. The choice of option determines who is responsible for operation and updates. **Cloud option (recommended):** eStamp is hosted by XiTrust as part of the MOXIS platform. Deployment is carried out by the XiTrust support team. No separate server is required. **On-premises:** eStamp is installed and operated in the customer's own IT infrastructure. Installation and ongoing operation are the responsibility of the customer's team. The following applies to both variants: Each eStamp instance receives its own customer-specific **base URL** (e. g. `https://pbss.kunde.xitrust.cloud/pbss`). This URL is specified during deployment and is a prerequisite for every API call. > \[!NOTE\] eStamp does not use **a client model** . Different configurations (e.g., different certificates or signature types) are mapped within an instance using **signature handlers**. A separate eStamp instance is recommended to ensure complete technical separation between organizational units. ## eStamp Base URL The eStamp Base URL is the customer-specific web address through which an eStamp instance can be accessed. All API calls use this URL as a basis. **Format:** https://pbss..xitrust.cloud/pbss **Beispiel:** https://pbss.acc.xitrust.cloud/pbss The base URL is specified during deployment and communicated by the XiTrust support team. Without the correct base URL, all API calls will fail with a 404 Not Found error. > \[!WARNING\] The eStamp base URL is **customer-specific and individual**. An incorrect or generic URL will result in 404 errors. If an eStamp service is unavailable, the base URL is the first thing to check. ## Authentication and access protection The eStamp REST API is secure. **Please note:**As of version 4.54, the licenseInfos GET call is executed without authentication. However, without valid authentication, no API calls are accepted---neither signing operations nor session management. eStamp supports two authentication methods: **OAuth 2.0 (recommended):** Modern, token-based authentication with the grant type "Client Credentials." A machine or system authenticates itself---not a human user. OAuth 2.0 is the recommended method for all new integrations. **Basic Authorization:** Classic authentication with username and password as HTTP headers. Less recommended than OAuth 2.0. > \[!NOTE\] eStamp does not use **RBAC, user roles, or different authorization levels**. Every validly authenticated client can use all protected endpoints. The only exception are license information endpoints, which are accessible without protection. ## OAuth 2.0 in eStamp: Configuration and Process eStamp uses OAuth 2.0 with the grant type "Client Credentials." This process is specifically designed for machine-to-machine communication. ### Required OAuth 2.0 configuration values The following five values are mandatory for OAuth 2.0 authentication against eStamp. All of them are defined and communicated by the XiTrust support team during deployment: | **Value** | **Description** | |-------------------|-----------------------------------------------------------------------------------------------------| | `client_id` | The "user name" of the application on the authentication server. | | `client_secret` | The application's "password" -- only the application and the authentication server know this value. | | `issuer-uri` | The "home address" of the identity provider (e.g., Keycloak) identifies the token issuer. | | `auth-server-url` | The specific URL of the authentication server to which token requests are sent. | | `grant_type` | Always `client_credentials` for eStamp-integrations | ### Step 1: Request a bearer token bash # eStamp OAuth 2.0: Request bearer token # Endpoint: POST /token on the configured authentication server # Grant Type: client_credentials (machine-to-machine) curl -X POST "https:///token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials" \ -d "client_id=" \ -d "client_secret=" **Successful Response (200 OK):** json { "access_token": "eyJhbGciOiJSUzI1NiIsInR5...", "token_type": "Bearer", "expires_in": 3600 } ### Step 2: Use the bearer token for every API call The bearer token is sent for every eStamp API call in the `Authorization`-Header: Authorization: Bearer > \[!WARNING\] The eStamp Bearer Token has a limited validity period (expires_in). After expiration, the eStamp API returns error 451 Unavailable for Legal Reasons (JWT token is expired). Implement automatic token renewal in your integration before the validity period expires. > \[!IMPORTANT\] Bearer tokens should be treated like passwords. Access data (`client_id`, `client_secret`, Bearer Token) must **never** be stored in source code, plain text configuration files, or version control systems. Recommended storage: Secret Manager (e.g., HashiCorp Vault, Keycloak, AWS Secrets Manager). ## Testing the eStamp API with Swagger Swagger is the interactive API documentation platform that is automatically generated based on eStamp's OpenAPI specification. Swagger allows you to test all eStamp endpoints directly in your browser without having to write your own code. **Swagger URL:** Swagger can be accessed via the respective eStamp instance. The exact URL will be communicated by the XiTrust support team during deployment. ### Using Swagger with OAuth 2.0 1. Open the Swagger UI of the eStamp instance in your browser. 2. Click on the **\[Authorize\]** button in the top right corner. 3. Enter your client_id and client_secret. Swagger automatically requests a bearer token and sets it for all subsequent test requests. 4. Execute any eStamp endpoints directly in the browser. > \[!NOTE\] Swagger is suitable for initial testing and exploration of the eStamp REST API. For production integrations, direct API use via HTTP clients (curl, Postman, programmatic clients) is recommended. ## Quick start: Seal your first PDF with eStamp This quick start guide shows you the minimum steps required to seal a PDF using the eStamp REST API. Requirements: valid eStamp base URL and valid OAuth 2.0 access data. ### Step 1: Query available signature handlers Before the first sealing call, the available parameterId values of the eStamp instance must be queried. The parameterId is a mandatory field for every seal call and controls which signature handler and which certificate is used. bash # eStamp: Query available signature handlers # Endpoint: GET /signApi/parameterInfos # Authentifizierung: Bearer Token required curl -X GET "https://pbss.acc.xitrust.cloud/pbss/signApi/parameterInfos" \ -H "Authorization: Bearer " **Successful response (200 OK):** json [ { "parameterId": "amtssignatur", "displayName": "Amtssignatur", "maxNumberOfDocuments": 100, "signatureHandlerType": "SOFTWARE_KEY" } ] If this call is successful, the base URL, authentication, and availability of the eStamp service are correct. **Common mistake in this step:** 404 Not Found -- "Cannot find handler for parameter" Causes: incorrect base URL, incorrect path, incorrect handler ID name. Check the base URL, token, and endpoint path carefully for spelling and capitalization. ### Step 2: Seal PDF (synchronous workflow) bash # eStamp: PDF versiegeln (synchroner Workflow ohne Visualisierung) # Endpoint: POST /signApi/sealSingle # Authentifizierung: Bearer Token erforderlich # Rückgabe: signiertes PDF als Binary curl -X POST "https://pbss.acc.xitrust.cloud/pbss/signApi/sealSingle" \ -H "Authorization: Bearer " \ -H "accept: application/pdf" \ -H "Content-Type: multipart/form-data" \ -F "parameterId=amtssignatur" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf **Result:** The signed PDF is returned as a binary file and saved under `signiert.pdf`. > \[!NOTE\] `documentToSign` and `file` are synonymous field names and have the same meaning. Both variants are accepted by the eStamp REST API. The different names arose due to historical customer requirements. ## FAQ: Authentication and basic concepts ### What specific base URL do customers receive? Each customer receives their own customer-specific base URL for their eStamp instance, for example [https://pbss.kunde.xitrust.cloud/pbss](https://estamp.kunde.xitrust.cloud/estamp). The base URL is determined and communicated by the XiTrust support team during deployment. Without the correct base URL, no eStamp API calls are possible. ### Does eStamp have a client model? No, eStamp does not have a client model. Different configurations (e.g., different certificates, signature types, or signature visualizations) are mapped via signature handlers within an eStamp instance. A separate eStamp instance is recommended for complete technical separation between organizational units. ### Is there API versioning? No, eStamp does not use URL-based API versioning (such as /api/v1/). Instead, XiTrust guarantees that no breaking changes will be made. Existing integrations will continue to function after updates. The last 3 eStamp versions are actively supported. ### Are there roles or permission levels? No, eStamp does not use RBAC (Role-Based Access Control). There are no user roles or different permission levels. Every validly authenticated client can use all protected eStamp endpoints. ### Which TLS version is required by eStamp? eStamp requires at least TLS 1.2. The standard is TLS 1.3. Older TLS versions are not accepted. ### How do I contact eStamp support? If you have any questions or problems, please contact the XiTrust support team: * **Service Desk Ticket:** via the XiTrust Service Desk Portal * **Email:** [servicedesk@xitrust.com](mailto:servicedesk@xitrust.com) The following information is helpful for support requests regarding API errors: * Timestamp of the request, * endpoint used, * sessionId (if available), and * complete HTTP status code --- version: "v1" language: "en" --- # eStamp: FAQs about authentication, workflows, limits, and error codes **Content** This document answers frequently asked questions about the eStamp REST API, organized by topic. Each question is formulated as a separate unit and contains the complete context for the answer. Prerequisites for using the eStamp REST API: a valid, customer-specific eStamp base URL and a valid bearer token (OAuth 2.0 or Basic Authorization). *** ** * ** *** ## 1. Architecture and basic concepts ### What base URL does an eStamp instance receive? Each eStamp instance receives its own customer-specific base URL during deployment. The format is `https://pbss..xitrust.cloud/pbss`. The base URL is determined by the XiTrust support team and communicated during deployment. Without the correct eStamp base URL, all API calls will fail with at `404 Not Found` error. If an eStamp service is unavailable, the base URL is the first thing to check. ### Does eStamp have a client model? eStamp does not have a client model. There are no separate clients within an eStamp instance. Different configurations---for example, different certificates, signature types, or signature visualizations---are mapped within an instance via **signature handlers**. This allows multiple organizational units to operate with different configurations without requiring their own instance. For complete technical separation, a separate eStamp instance is recommended. ### Is there API versioning in eStamp? eStamp does not use URL-based API versioning such as `/api/v1/` or `/api/v2/`. Instead, XiTrust guarantees that no breaking changes will be made to the eStamp REST API. Existing integrations will continue to function after updates. The last two eStamp versions are actively supported. Special compatibility management is therefore not necessary. ### What is the eStamp REST API and which protocols are used? The eStamp REST API is the interface through which all signing, sealing, and validation operations are performed. Communication takes place exclusively via HTTPS using the standard HTTP methods `GET` (retrieve information) and `POST` (send document, trigger signature). No proprietary or exotic protocols are used. The base path of all eStamp signature endpoints is `/signApi/...`. *** ** * ** *** ## 2. Authentication and Security ### What authentication methods does eStamp support? eStamp supports two authentication methods: **OAuth 2.0** and **Basic Authorization**. Both methods protect all eStamp endpoints that process documents. No signing or sealing operations will be accepted without valid authentication. OAuth 2.0 is the recommended method for all new eStamp integrations. ### What is the eStamp bearer token and how is it used? The eStamp bearer token is an access token obtained from the configured authentication server via the OAuth 2.0 flow (grant type: client credentials). The Bearer Token is sent in the `Authorization`-header with every eStamp API call: `Authorization: Bearer `. The token has a limited validity period (`expires_in`). After expiration, the eStamp API returns `451 Unavailable for Legal Reasons` zurück. Integrations should implement automatic token renewal before the expiration date. > \[!IMPORTANT\] The eStamp bearer token must be treated like a password. `client_id`, `client_secret` and bearer tokens must never be stored in source code, plain text configuration files, or version control systems. Recommended storage: Secret Manager (e.g., HashiCorp Vault, Keycloak, AWS Secrets Manager). ### Which TLS version does eStamp require? eStamp requires at least TLS 1.2. The standard is TLS 1.3. Connection attempts with older TLS versions are rejected. All connections to the eStamp REST API are therefore encrypted and comply with current security standards. ### Are all eStamp endpoints protected equally? No, eStamp distinguishes between protected and unprotected endpoints. Only license information endpoints are accessible without protection, as this information is not security-relevant. All endpoints that process documents---i.e., signing, sealing, and session operations---are protected with OAuth 2.0 or Basic Authorization. Any validly authenticated client can use all protected eStamp endpoints; there is no RBAC, no user roles, and no different authorization levels. *** ** * ** *** ## 3. Workflows: Synchronous and session-based ### What is the difference between synchronous and session-based workflows in eStamp? The synchronous eStamp workflow processes a single document per API call: The document is sent and the signed result is returned immediately --- without sessions, caching, or status queries. The session-based workflow enables batch processing of multiple documents in a multi-step process (`startSession` → `addDocument` → `seal` → `getDocument` → `closeSession`). The synchronous workflow is simpler for individual documents; the session-based workflow is necessary for batch processing of up to 100 documents per session. ### Are there background processes or a status endpoint in eStamp? eStamp does not use background processes, status endpoints, polling, or webhooks. Each eStamp API call blocks until it is completely finished and returns the result directly. This applies to both synchronous calls and the `seal`-step in the session-based workflow.. ### How many documents can be processed per eStamp session? A maximum of 100 documents can be processed per eStamp batch session. The same limit applies per individual REST call. If more than 100 documents need to be signed, multiple sessions must be started. The number of sessions running simultaneously is not limited. Only one session can be started per REST call. ### Is the eStamp session-based workflow a true asynchronous model? No, the session-based eStamp workflow is not an asynchronous model. Every call - including `seal` - blocks until it is completed. There is no status endpoint, no job ID, and no webhook. Once `seal` is complete, `getDocument` can be called. ### How long is an eStamp session valid? An eStamp batch session is valid for **40 minutes** from the `startSession` call. If the session is not terminated with `closeSession` within this time, it expires automatically. A single API call within the session may take a maximum of **30 seconds**. If this time is exceeded, the call is aborted and an error message is returned. A timeout does not necessarily mean that the document is damaged, but rather that the call took too long. ### What happens when an eStamp API call times out or is canceled? If an eStamp API call times out or is canceled, the process is terminated and an error message is returned. No partial processing takes place. Expired or unfinished eStamp sessions are automatically cleaned up---no manual cleanup is required. ### Can documents be removed or replaced from an eStamp session after they have been added? No. Once documents have been added to an eStamp session, they cannot be removed or replaced. If an incorrect document has been added, a new eStamp session must be started using startSession. ### Is there partial failure in eStamp batch processing? eStamp does not support partial failure. A batch operation is either completely successful or completely fails. There is no partial processing of individual documents within a session. *** ** * ** *** ## 4. Limits and performance ### What technical limits apply to the eStamp REST API? The following limits apply to the eStamp REST API: a maximum of **100 documents** per session and per REST call, a **timeout of 30 seconds** per individual API call, a **session validity of 40 minutes** from `startSession`, and a **maximum file size** that is defined instance-specifically in the system configuration. The maximum file size is not fixed and may vary depending on the eStamp instance. ### What rate limits are there for eStamp? eStamp does not define a publicly specified rate limit (e.g., "X requests per second"). Too many simultaneous requests can result in extended response times, timeouts, or HTTP `429 Too Many Requests` eStamp is designed for controlled, sequential API calls and is not a streaming system. Aggressive parallelization should be avoided. ### What does HTTP 429 mean at eStamp and how should you respond to it? HTTP `429 Too Many Requests` signals that too many requests were sent in a short period of time or that the document limit for a session has been reached. The recommended retry strategy is to wait 2--5 seconds and then resend the request. Batch processing should be staggered for high volumes. *** ** * ** *** ## 5. 5. File upload and file formats ### Which file formats does eStamp accept for uploads? eStamp only accepts `application/pdf` for document uploads. Other formats such as `application/octet-stream`, XML, or other document types are not accepted for PDF signature endpoints and result in a `415 Unsupported Media Type`. XML documents can be validated via the separate endpoint `POST /xmlSignApi/validateXml`. ### Is there a maximum file size for eStamp? Yes, but the maximum file size is not globally fixed. It is defined in the system configuration of the respective eStamp instance and can therefore vary depending on the deployment. If an uploaded document exceeds the configured limit, eStamp returns `413 Payload Too Large`. ### What restrictions apply to PDF documents to be uploaded? eStamp does not restrict the number of pages or the PDF variant. All common PDF variants --- including PDF and PDF/A --- are processed. Temporary files are stored in encrypted form during processing. Signature control and visualization ### Which parameter controls signature behavior in eStamp? Signature behavior in eStamp is controlled by the `parameterId`. The `parameterId` is a mandatory field for every seal call and determines which signature handler is used, which certificate is used, and which sealing behavior applies. The available `parameterId`-values for an eStamp instance are queried via `GET /signApi/parameterInfos`. ### How is the signature visualization (`signatureAppearance`) transferred to eStamp? The `signatureAppearance` configuration can be transferred in two ways: as a**JSON file** when calling `sealSingleWithAppearance` or `addDocumentWithAppearance`, or as a **server-side stored ID** (`appearanceId`) when calling `sealSingleWithAppearanceParam` or `addDocumentWithAppearanceParam`. The format of the `signatureAppearance` configuration is always JSON. ### Are signature attributes (`signatureAttributes`) configurable in eStamp? Yes, additional X.509 certificate attributes can be displayed in the signature visualization using the optional `signatureAttributes` - for example, `subjectDn`, `serialNumber` or `notAfter`. The `signatureAttributes` are linked to the official signature and only make sense when used with official signatures. The field should not be set for other signature types. ### What unit does the coordinate system of the eStamp signature visualization use? The position specifications `x` and `y` describe the coordinates of the signature visualization on the PDF page. The size specifications `width` and `height` are given in **pt (points)** . Default values: `width = 400`, `height = 270`. *** ** * ** *** ## 7. Error codes and debugging ### Which HTTP status codes does eStamp use? eStamp uses standard HTTP status codes. The following table shows the most important codes, their meanings, and typical causes: | **Code** | **Meaning** | **Common cause** | |----------|-------------------------------|------------------------------------------------------------------------| | 200 | OK | Request successful; signed document returned as binary | | 400 | Bad Request | Invalid `parameterId`, incorrect PDF format, invalid session operation | | 401 | Unauthorized | No or invalid bearer token | | 403 | Forbidden | Incorrect authentication method | | 404 | Not Found | Incorrect base URL, unknown `sessionId`, signature handler not found | | 406 | Not Acceptable | Incorrect`signatureAppearance` configuration, certificate problem | | 412 | Precondition Failed | Invalid or expired `sessionId` | | 413 | Payload Too Large | File exceeds the configured size limit | | 415 | Unsupported Media Type | Incorrect content type (expected: `application/pdf`) | | 422 | Unprocessable Entity | Invalid or corrupted PDF | | 429 | Too Many Requests | Document limit of the session reached or too many parallel requests | | 451 | Unavailable for Legal Reasons | Bearer Token expired | | 500 | Internal Server Error | Unexpected system error, infrastructure problem | ### What do eStamp error responses look like? eStamp returns errors with an HTTP status code and an error message. There is no additional uniform JSON error schema --- the error information is contained in the HTTP status code and the associated message. ### How do I debug eStamp errors via response headers? eStamp requests can be tracked via the request ID in the response header. The request ID enables internal mapping to log entries, but does not itself contain any error information. The following information is helpful for support requests: timestamp of the request, endpoint used, `sessionId` (if available) and complete HTTP status code. ### What are the most common causes of errors with eStamp? In the majority of cases, eStamp errors can be traced back to four causes: an incorrect or invalid `parameterId` (400), an expired or missing bearer token (401/451), a document that is too large (413), or an invalid or damaged PDF (422). The quick diagnosis for operations and administration: 400 errors indicate configuration problems, 401/403 indicate authentication problems, 413 indicate file size problems, and 500 indicate system problems. ### What to do in case of an HTTP 500 Internal Server Error from eStamp? HTTP `500 Internal Server Error` signals an unexpected system error in eStamp --- for example, an infrastructure problem, a certificate problem, or a failed signature creation. Check the eStamp server logs using the timestamp and session ID. If you cannot resolve the problem yourself, contact the XiTrust support team at [servicedesk@xitrust.com](mailto:servicedesk@xitrust.com) with the timestamp, endpoint, `sessionId` and HTTP status code. *** ** * ** *** ## Quick reference: Rapid diagnosis of eStamp errors If an eStamp API call fails, we recommend the following sequence for error diagnosis: 1. **Check HTTP status code**: Indicates the error type (see table above) 2. **Check bearer token**: Is the token valid and not expired? 3. **Check** `parameterId`**:** Does the value exist in `GET /signApi/parameterInfos`? 4. **Check base URL**: Is the customer-specific eStamp base URL correct? 5. **Check file size**: Does the document exceed the configured limit? 6. **Check logs** : Track using timestamp and `sessionId` in the eStamp server logs. --- version: "v1" language: "en" --- # eStamp Glossary: Terms and concepts related to document signing **Content** This glossary defines all technical terms used in the eStamp documentation. It serves as an authoritative terminology reference for all other eStamp documents. Terms are grouped by topic and are self-explanatory - each entry contains product context, definition, and cross-references. > **Target audience:** Developers and administrators who are new to working with the eStamp REST API. Please direct **support requests** to the XiTrust support team at [++servicedesk@xitrust.com++](mailto:servicedesk@xitrust.com). *** ** * ** *** ## A: Architecture \& Operation This section explains the basic architecture and operating concepts of eStamp. ### eStamp (product) eStamp is a XiTrust service for **automatically signing and sealing documents** via a REST API or a web client. Documents are sent to the eStamp API as PDF files, signed or sealed, and returned as signed PDF files. Typical areas of application are public authorities (notices), insurance companies (policies), and businesses (automated document processes). **Synonyms in the system:** eStamp is also referred to internally as the "Seal Service." In the API, the base path is /signApi/.... → See: \[[++eStamp structure, use, and authentication for PDF signatures: What is eStamp?++](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-aufbau-nutzung-und-authentifizierung-fur-pd)\] ### Base URL (eStamp instance address) The eStamp base URL is the **customer-specific web address** through which an eStamp instance can be accessed. It is defined during deployment and is a prerequisite for every API call. **Format:** `https://pbss..xitrust.cloud/pbss` **Example:** `https://pbss.acc.xitrust.cloud/pbss` \[!WARNING\] The base URL is individual for each customer. Without the correct base URL, all API calls will fail. If the service is not accessible, the base URL is the first checkpoint. → See: \[[++eStamp structure, use, and authentication for PDF signatures: eStamp base URL++](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-aufbau-nutzung-und-authentifizierung-fur-pd#eStamp-Base-URL)\] ### eStamp instance An eStamp instance is a **stand-alone deployment of eStamp**, either as a cloud variant (hosted by XiTrust) or as an on-premises installation (operated in the customer's infrastructure). Each instance has its own base URL and configuration. **Deployment variants:** **Variant** **Operation by** **Server required** Cloud XiTrust Support Team No On-premises Customer itself Yes \[!NOTE\] For complete technical separation between organizational units (e.g., corporate structures), a separate eStamp instance is recommended. **Note: Technical separation = separate instance.** ### Client model (eStamp) eStamp does not use a client model. Unlike other systems, there are no separate clients within an eStamp instance. Instead, different configurations (e.g., different certificates, signature types, visualizations) are mapped within an instance using signature handlers. ### Signature handler (eStamp) An eStamp signature handler is a software component that controls the technical process of a signature operation. It determines which certificate is used and which seal behavior applies. A signature handler is selected via the parameterId in each seal call. **Query available handlers:** `# eStamp API: Retrieve all configured signature handlers` `GET /signApi/parameterInfos` `Authorization: Bearer ` **Example response:** `[` `{` `"parameterId": "software",` `"displayName": "software",` `"maxNumberOfDocuments": 100,` `'signatureHandlerType': "SOFTWARE_KEY"` `}` `]` → See: \[[++eStamp API Reference and Endpoint Catalog: GET /signApi/parameterInfos++](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-api-referenz-und-endpunkt-katalog#GET-/signApi/parameterInfos)\] *** ** * ** *** ## B: Authentication \& Security This section explains all authentication concepts of the eStamp REST API. Without valid authentication, the eStamp API returns HTTP 401 and denies all signature and seal operations. ### Basic Authorization (eStamp) Basic Authorization is a simple authentication method for the eStamp API, in which classic access data (user name + password) is transferred as a Base64-encoded HTTP header. \[!NOTE\] Basic Authorization is supported for eStamp, but is **less recommended** than OAuth 2.0. For production environments, OAuth 2.0 with client credentials should be used. ### OAuth 2.0 (eStamp Authentication) OAuth 2.0 is the **recommended authentication method** for the eStamp REST API. eStamp exclusively uses the **Client Credentials** grant type, which means that a machine or system authenticates itself, not a human user. There are no user accounts, passwords, or roles. **Required fields for OAuth 2.0 configuration in eStamp:** | **Field** | **Description** | **Determined by** | |-------------------|-------------------------------------------------------------|-------------------| | `client-id` | "User name" of the application on the authentication server | XiTrust | | `client-secret` | Application "password" (secret key) | XiTrust | | `auth-server-url` | Specific URL for token requests | XiTrust | | `grant_type` | Always `client_credentials` | XiTrust | **Request token (cURL):** # eStamp OAuth 2.0: Request Bearer Token # Endpoint: POST /token on the auth server (auth-server-url) # Prerequesite: Obtain client-id and client-secret from Deployment curl -X POST "/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials" \ -d "client_id=" \ -d "client_secret=" # Successful response (200 OK): # { # "access_token": "eyJhbGciOiJSUzI1NiIsInR5...", # "token_type": "Bearer", # "expires_in": 3600 # } # # Error 401: client-id oder client-secret incorrect # Error 404: auth-server-url incorrect → Details: \[[++eStamp setup, use, and authentication for PDF signatures: OAuth 2.0++](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-aufbau-nutzung-und-authentifizierung-fur-pd#OAuth-2.0-in-eStamp:-Configuration-and-Process)\] ### Bearer token (eStamp access token) The eStamp bearer token is an **OAuth 2.0 access token** that must be sent in the Authorization header with every eStamp API call. It is the only Authorization header required by the eStamp API. **Usage:** `Authorization: Bearer ` **Validity period:** Specified in the expires_in field of the token response (typically: 3600 seconds = 1 hour). After expiration, the eStamp API returns HTTP 401. \[!WARNING\] **Security rule:** Treat the eStamp bearer token like a password. Never store it in the source code or in plain text. Recommended storage locations: Keycloak, HashiCorp Vault, or a comparable secret store. **Best practices:** * Only make tokens accessible to authorized systems * Monitor expiration time (expires_in) and proactively renew tokens * For HTTP 401: First check token validity, then OAuth configuration ### Client ID / Client Secret (eStamp OAuth) client_id and client_secret are the identification data of an application vis-à-vis the eStamp authentication server. * client_id**:** The "user name" of the application -- the name under which it is registered with the auth server. * client_secret**:** The "password" of the application -- a secret key known only to the application and the auth server. Together with the client_id, it proves the identity of the application. \[!WARNING\] The client_secret must never be stored in the source code or in versioned configuration files. ### issuer-uri / auth-server-url (eStamp OAuth) * issuer-uri**:** The address of the identity provider (e.g., Keycloak) that issues eStamp tokens. Uniquely identifies who authorizes the tokens. * auth-server-url**:** The specific URL to which token requests are sent. Often similar to issuer-uri, but may differ slightly. Both values are determined and communicated by XiTrust during deployment. ### TLS (eStamp connection security) eStamp uses HTTPS connections exclusively. Supported TLS versions: | **Version** | **State** | |-------------------|----------------| | TLS 1.3 | ✅ Standard | | TLS 1.2 | ✅ Supported | | TLS 1.1 and older | ❌ Not accepted | *** ** * ** *** ## C: API Concepts \& Workflows This section explains the basic API concepts and workflow types of the eStamp REST API. Almost all endpoints (exception: XML signature) can be accessed under the base path /signApi/... ### eStamp REST API The eStamp REST API is the standardized HTTP interface for communicating with the eStamp signing service. All calls are made via HTTPS. There are two HTTP methods: * GET -- Retrieve configuration information (e.g., available parameterId values) * POST -- Send documents and trigger signing processes No exotic protocol: Anyone who has already worked with REST web services is familiar with the principle. ### Synchronous workflow (eStamp) An eStamp synchronous workflow is a **single API call** that receives a PDF document, signs it immediately, and returns the signed document directly. There is no session, no caching, and no status endpoint. **Process:** 1. Send PDF + parameterId via POST 2. eStamp signs synchronously 3. Receive signed PDF as binary response **Available endpoints:** | **Endpoint** | **When to use** | |-----------------------------------------------|--------------------------------------------------------| | `POST /signApi/sealSingle` | Signing without visualization | | `POST /signApi/sealSingleWithAppearance` | Signing with custom visualization (JSON file) | | `POST /signApi/sealSingleWithAppearanceParam` | Signing with server-side predefined visualization (ID) | → See: \[[++eStamp workflow instructions: Synchronous signing (single request)++](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-workflow-anleitungen-fur-das-signieren-und-#Workflow-1:-Synchronous-signing-(single-request))\] ### **Session-based workflow / batch workflow (eStamp)** An eStamp session-based workflow (also known as a batch workflow) is a **multi-step process for simultaneously processing multiple documents** within a single session. It is used when more than one document needs to be signed at a time. **Order of calls (binding):** | **Step** | **Method** | **Endpoint** | **Description** | |----------|------------|-----------------------------------------|-------------------------------------------------| | 1 | POST | `/signApi/startSession` | Neue Session starten, `sessionId` erhalten | | 2 | POST | `/{sessionId}/addDocument` | Dokument(e) hinzufügen (wiederholbar, max. 100) | | 3 | POST | `/{sessionId}/seal` | Signiervorgang für alle Dokumente auslösen | | 4 | GET | `/{sessionId}/getDocument/{documentId}` | Signierte Dokumente abrufen | | 5 | POST | `/{sessionId}/closeSession` | Session beenden | > \[!WARNING\] The order is binding. getDocument before seal returns HTTP 404. Retrieve all documents before closeSession -- after that, they will no longer be available. → See: \[[++eStamp workflow instructions for signing and validating PDF documents: Session-based signing (batch)++](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-workflow-anleitungen-fur-das-signieren-und-#Workflow-2:-Session-based-signing-(batch))\] ### **Session (eStamp)** An eStamp session is a **temporary processing context for a batch signing operation.**It is referenced by a sessionId, which is returned by POST /signApi/startSession. **Important session properties:** | **Property** | **Value** | |----------------------------|----------------------------------------------------| | Validity period | 40 minutes | | Max. documents per session | 100 | | Remove documents later | ❌ impossible | | Automatic cleanup | ✅ Yes (expired sessions are automatically deleted) | > \[!NOTE\] If an incorrect document has been added, a new session must be started---documents cannot be removed after they have been added. ### **parameterId (eStamp mandatory field)** The parameterId is a **mandatory field for every eStamp seal call.**It controls which signature handler is used, which certificate is used, and which sealing behavior applies. Without a valid parameterId, the eStamp API returns HTTP 400. **Query available** parameterId **values:** # eStamp API: Retrieve available parameterId values # This call should be executed before the first seal process curl -X GET "https:///pbss/signApi/parameterInfos" \ -H "Authorization: Bearer " # Successful response (200 OK): # [{ "parameterId": "seal", 'displayName': "...", ... }] # # Error 404: Bearer token missing or base URL incorrect ### multipart/form-data (eStamp upload format) multipart/form-data is the HTTP transfer format used by most eStamp endpoints for file uploads. PDF documents, JSON configurations, and string parameters are bundled into a single HTTP request. **Important:** Documents must be transferred with Content-Type: application/pdf. Other formats (application/octet-stream, XML, etc.) are rejected by the eStamp API (HTTP 415). *** ** * ** *** ## **D: Signature visualization** This section explains all concepts related to eStamp signature visualization---i.e., how a signature is visually displayed in a PDF document. Configuration is done using the signatureAppearance JSON object. \[!WARNING\] There are **two special cases** (VisualizationAutomation and signatureFieldId) that are mutually exclusive and must not be combined. ### signatureAppearance (eStamp) The eStamp signatureAppearance is a**JSON configuration that specifies how a signature is visually displayed in the PDF**-- position, size, signature image, and page area. It can be transferred in two ways: 1. As a JSON file directly in the request (sealSingleWithAppearance, addDocumentWithAppearance) 2. As a server-side predefined ID (appearanceId) as a query parameter (sealSingleWithAppearanceParam, addDocumentWithAppearanceParam) **Which mode should be used?** | **Situation** | **Recommended mode** | |----------------------------------------------------------|-----------------------------------------| | Set position and page individually for each call | Transfer JSON file directly | | Reuse standardized company visualization | `appearanceId` as query parameter | | PDF already has defined signature fields | Special case: `signatureFieldId` | | Automatically place signature at the end of the document | Special case: `VisualizationAutomation` | **Mandatory fields (standard case):** | **Field** | **Type** | **Description** | |--------------------|----------|------------------------------------------------------------| | `signatureImageId` | string | ID of the signature image stored on the server | | `lastPage` | int | Last page with signature (`-1`= last page of the document) | | `onEveryPage` | boolean | `true` = signature on every page in the area | | `x` | int | Horizontal position in pt | | `y` | int | Vertical position in pt | **Optionale Felder (Standardfall):** | **Field** | **Type** | **Standard** | **Description** | |-----------------------|----------|--------------|--------------------------------------------------| | `signaturePageId` | string | -- | ID of an additional signature page | | `firstPage` | int | 1 | First page on which the signature appears | | `width` | int | 400 | Width of the visualization in pt | | `height` | int | 270 | Height of the visualization in pt | | `signatureAttributes` | object | -- | Certificate attributes (official signature only) | > \[!NOTE\] **Coordinate system:** x/y are coordinates, width/height are specified in **pt** (points) -- same logic as in MOXIS. **Complete example JSON (standard case):** { "signatureImageId": "amtsSignatur", "signaturePageId": "default", "firstPage": 1, "lastPage": -1, "onEveryPage": "", "x": 100, "y": 100, "width": 400, "height": 250, "signatureAttributes": { "subjectDn": "Aussteller" } } > \[!WARNING\] If onEveryPage: true is set, signaturePageId must **not** be set. → See: \[[++eStamp API Reference and Endpoints: SignatureAppearance++](https://documentation.moxis.co/en/estamp-dokumentation/latest/estamp-api-referenz-und-endpunkt-katalog#POST-/signApi/sealSingleWithAppearance)\] ### **signatureImageId (eStamp required field)** signatureImageId is a **required field in every eStamp** signatureAppearance configuration. It references the signature image stored on the server that is to be displayed in the PDF. Without this field, the visualization will not work. The value must correspond to one of the image IDs configured on the server. ### **signaturePageId (eStamp)** signaturePageId is an **optional field** in eStamp-signatureAppearance. It refers to an additional signature page that is appended to the document. \[!WARNING\] signaturePageId must**not** be used together with onEveryPage: true. For VisualizationAutomation, signaturePageId must be set and valid. ### **signatureFieldId (eStamp -- special case)** signatureFieldId is an**optional field**for the special case where a PDF already contains predefined signature fields. If set, the signature visualization is placed directly in the specified signature field -- without manual coordinate specification. **If** signatureFieldId**is set, these fields are omitted:**firstPage, lastPage, onEveryPage, x, y, width, height **Minimal JSON with signatureFieldId:** { "signatureImageId": "imageOnly", "signatureFieldId": "Signatur2" } **Query signature field names of a PDF:** # eStamp-API: Determine existing signature fields in a PDF POST /signApi/signatureFieldNames # Parameter: document (binary PDF) # Response: JSON-Array der signatureFieldId-Werte > \[!NOTE\] If`signatureFieldId` is not set, the position is automatically taken from the first signature field of the PDF. ### VisualizationAutomation (eStamp -- Special case) `VisualizationAutomation` is a **special case of the eStamp-** `signatureAppearance`, where the signature visualization is automatically placed at the end of the last text character on the last page. If there is no space above the footer, a new signature page is automatically created. **Required fields in the** `visualizationAutomation`**-block:** | Field | Type | Description | |-----------------------|------|----------------------------------------------------------------| | `footerHeight` | int | Height of footer in pt | | `margin` | int | Distance between last text character and signature image in pt | | `signaturePageMargin` | int | Distance above signature page for automatic page break in pt | **Example-JSON:** { "signatureImageId": "amtsSignatur", "signaturePageId": "default", "x": 100, "width": 400, "height": 250, "visualizationAutomation": { "footerHeight": 6, "margin": 10, "signaturePageMargin": 60 } } > \[!WARNING\] The following conditions must be met for`VisualizationAutomation`: > > * `signaturePageId` must be set and valid > > * `signatureAttributes` must **not** be set > > * **Cannot** be combined with `signatureFieldId` ### signatureAttributes (eStamp -- official signature) `signatureAttributes` is an **optional field** in the eStamp-`signatureAppearance`, that displays additional X.509 certificate attributes in the signature visualization. > \[!NOTE\] `signatureAttributes` is **only useful for official signatures**. This field has no effect on other signature types. **Available certificate attributes:** | Key (technical, fix) | Display text (freely selectable) | |----------------------------------|----------------------------------| | `subjectDn` | z.B. `"Exhibitor"` | | `issuerDn` | z.B. `"Certification body"` | | `notBefore` | z.B. `"Creation date"` | | `notAfter` | z.B. `"Expiration date"` | | `serialNumber` | z.B. `"Serial number"` | | `sigAlgName` | z.B. `"Signature algorithm"` | | `sigAlgOID` | z.B. `"Signature OID"` | | `signatureDate?datetime?iso_utc` | z.B. `"Signing date (UTC)"` | | `type` | z.B. `"Type"` | | `version` | z.B. `"Version"` | > \[!TIP\] The left value (key) is technically specified and must not be changed. The right value (display text) can be freely selected. *** ** * ** *** ## E -- Initials This section explains the initials function of the eStamp API. Initials are small signature images that are placed on pages of a document to supplement the main signature. ### Initials (eStamp) An eStamp initial is a **small signature image** that is placed on pages of a document -- typically as a side signature. It is configured using a separate JSON configuration (paraphenImage parameter), which can be optionally added to each seal call. ### paraphImageId (eStamp required field) paraphImageId is a **required field in the eStamp initials configuration**. It references the initials image stored on the server. **Required fields in the initials configuration:** | **Feld** | **Pflicht** | **Beschreibung** | |-----------------|-------------|----------------------------------------------| | `paraphImageId` | ✅ Yes | ID of the initial image stored on the server | | `width` | ✅ Yes | Width of the initial in pt | | `height` | ✅ Yes | Height of the initial in pt | | `x` | ✅ Yes | Horizontal position in pt | | `y` | ✅ Yes | vertical position in pt | **Beispiel-JSON:** { "paraphImageId": "picture1", "width": 50, "height": 22, "x": 10, "y": 800 } ### ParaphenAppearance (eStamp) The eStamp-`ParaphenAppearance` is the **server-side configuration of the paraphen appearance** (YAML). It is analogous to `signatureAppearance`, but for paraphen. Available paraphen IDs are queried via `GET /signApi/paraphenInfos`. **Server-side YAML configuration (example):** estamp: paraphen-image: picture1: classpath:/paraphenImages/picture1.jpg picture2: classpath:/paraphenImages/picture2.png paraphen-appearance: paraphen1: classpath:/paraphenAppearance/paraphenAppearance1.json paraphen2: classpath:/paraphenAppearance/paraphenAppearance2.json *** ** * ** *** ## F -- Error codes \& Operation This section explains all HTTP status codes, timeouts, and operating concepts of the eStamp REST API. Causes and specific solution steps are provided for each error situation. ### HTTP-Statuscodes (eStamp -- Übersicht) | **Code** | **Significance** | **Common cause** | |----------|-------------------------------|---------------------------------------------------------------------------------| | 200 | OK -- Request successful | -- | | 400 | Bad Request | Invalid `parameterId`, missing required fields, incorrect PDF format | | 401 | Unauthorized | Bearer Token missing, invalid or expired | | 403 | Forbidden | Incorrect Authentification method | | 404 | Not Found | Incorrect Base URL, unknown `sessionId`, Handler not found | | 406 | Not Acceptable | Incorrect appearance configuration, certificate problem | | 412 | Precondition Failed | Invalid `sessionId` | | 413 | Payload Too Large | File exceeds configured limit | | 415 | Unsupported Media Type | Incorrect content type (expected: `application/pdf`) | | 422 | Unprocessable Entity | Invalid or damaged PDF, incorrect JSON configuration | | 429 | Too Many Requests | Document limit for the session reached (max. 100) or too many parallel requests | | 451 | Unavailable for Legal Reasons | JWT-Token expired | | 500 | Internal Server Error | Unexpected system error, certificate problem, infrastructure problem | ### HTTP 400 -- Bad Request (eStamp) The eStamp API returns HTTP 400 if the request is invalid. **Common causes:** * parameterId does not exist → call GET /signApi/parameterInfos * Required fields in signatureAppearance are missing * Invalid session operation (e.g., addDocument after seal) Solution steps: Check parameterId, validate JSON configuration against required fields. ### HTTP 401 -- Unauthorized (eStamp) The eStamp API returns HTTP 401 if authentication fails. **Common causes:** * Authorization: Bearer \ header is missing from the request * Bearer token has expired (expires_in exceeded) * Token was generated with incorrect client_id/client_secret values **Solution steps:** 1. Check whether the Authorization header is set correctly 2. Check expires_in from the token response and request a new token if necessary 3. Verify OAuth configuration (issuer-uri, client-id) ### HTTP 404 -- Not Found (eStamp) The eStamp API returns HTTP 404 if an endpoint or resource cannot be found. **Common causes:** * Incorrect base URL or incorrect endpoint path * Unknown or expired sessionId * getDocument called before seal **Solution steps:** Check the base URL, check the path for upper/lower case, check the session status. ### HTTP 422 -- Unprocessable Entity (eStamp) The eStamp API returns HTTP 422 if the PDF document or JSON configuration is invalid. **Common causes:** * PDF is damaged or not a valid PDF/A * Required fields in signatureAppearance are missing * Unauthorized combination of special cases (e.g., VisualizationAutomation + signatureAttributes) **Solution steps:** 1. Validate PDF with POST /signApi/validatePdf 2. Check JSON configuration against required fields 3. Check special case combination: signatureFieldId and VisualizationAutomation are mutually exclusive ### HTTP 500 -- Internal Server Error (eStamp) The eStamp API returns HTTP 500 if an unexpected system error has occurred. **Possible causes:** Infrastructure problem, certificate problem, signature creation fails internally. **Solution steps:** Check logs, contact support at [++servicedesk@xitrust.com++](mailto:servicedesk@xitrust.com) with: timestamp of the request, endpoint, sessionId (if available), and complete HTTP status code. ### Timeout (eStamp) The eStamp API has two time limits that are often confused: | **Time limit** | **Value** | **Description** | |-------------------------|--------------|-----------------------------------------------------------------------------------------------| | API-Call-Timeout | \~30 seconds | Maximum duration of a single API call. If exceeded: termination + error message. | | Session-validity period | 40 minutes | Total validity period of a batch session. After expiration: session invalid, restart process. | > \[!NOTE\] A timeout does not mean that the document is corrupted---only that the request took too long. ### Retry strategy (eStamp) In the event of HTTP 429 (Too Many Requests) or a timeout, the following retry strategy is recommended for the eStamp API: 1. Wait briefly: 2--5 seconds 2. Resend the request 3. Avoid aggressive parallelization 4. For batch processing: stagger requests > \[!TIP\] eStamp is not a streaming system, but is designed for controlled, sequential API calls. ### sessionId (eStamp) The eStamp sessionId is the **unique identifier of a batch signing session**. It is returned as a JSON string in POST /signApi/startSession and used as a path parameter in all subsequent calls (/{sessionId}/addDocument, etc.). **Important for support requests:** If you encounter problems with the batch workflow, always have the sessionId, timestamp, and HTTP status code ready. *** ** * ** *** ## G -- Tools \& Helpful Concepts This section explains supporting tools and overarching concepts related to the eStamp API. ### Swagger (eStamp API test interface) Swagger is an interactive API documentation platform based on the OpenAPI specification that enables direct testing of eStamp endpoints in the browser. It supports the entire API development lifecycle from design to testing. **Using Swagger with OAuth 2.0:** 1. Open the Swagger UI of the eStamp instance 2. Click on the \[Authorize\] button 3. Enter `client_id` and `client_secret` - Bearer token is set automatically 4. Execute API calls directly ### Partial Failure (eStamp) eStamp does not support partial failure. In a batch process, either all documents are signed successfully or the entire process fails. There is no partial processing of individual documents within a session. ### Backward Compatibility (eStamp) eStamp does not implement **any breaking changes**. Existing integrations remain functional after updates. There are no version dependencies, no hidden system couplings, and no complicated upgrade scenarios. The last 3 versions are actively supported. *** ** * ** *** **If you have any questions, please contact our support team:** MOXIS Support Team \| [++servicedesk@xitrust.com++](mailto:servicedesk@xitrust.com) \| Create a service desk ticket --- version: "v1" language: "en" --- # eStamp: Workflow instructions for signing and validating PDF documents **Content** This document describes the available workflow types of the eStamp REST API and explains step by step how PDF documents are signed, sealed, and validated. Prerequisite for all workflows: a valid eStamp base URL and a valid bearer token (see "eStamp: Structure, Use, and Authentication"). *** ** * ** *** ## Overview: What types of workflows are available? The eStamp REST API offers two main workflow types for signing documents and a separate workflow for validation: Synchronous workflow (single request): A single API call immediately returns the signed document. Suitable for individual documents without temporary storage. Three variants available: `sealSingle`, `sealSingleWithAppearance`, `sealSingleWithAppearanceParam`. **Session-based workflow (batch):** Multiple documents are processed within a single session. This involves several steps: `startSession` → `addDocument` → `seal` → `getDocument` → `closeSession`. Suitable for batch processing of up to 100 documents per session. **Validation workflow:** Checks the signature of an existing PDF or XML document and returns a validation report. > \[!NOTE\] eStamp is **not an asynchronous system**. There are no background jobs, no status endpoints, no polling, and no webhooks. Each API call blocks until it is complete and returns the result directly. ## Workflow 1: Synchronous signing (single request) The synchronous signing workflow of the eStamp REST API processes a single document per API call and immediately returns the signed document as a binary file. There are no sessions, no caching, and no status to check. ### Variant 1a: Signing without visualization (`sealSingle`) Seals a PDF document without displaying a visual signature in the document. # eStamp: Seal PDF without signature visualization # Endpoint: POST /signApi/sealSingle # Authentification: Bearer Token required # Return: signed PDF as binary curl -X POST "https:///signApi/sealSingle" \ -H "Authorization: Bearer " \ -H "Content-Type: multipart/form-data" \ -F "parameterId=" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf **Parameter:** | **Parameter** | **Typ** | **Pflicht** | **Beschreibung** | |------------------|--------------|-------------|----------------------------------------------------------------------------------| | `parameterId` | string | Yes | ID of the signature handler (available values via `GET /signApi/parameterInfos`) | | `documentToSign` | binary (PDF) | Yes | The PDF document to be signed. | > \[!NOTE\] `documentToSign` and `file` are synonymous field names with identical meanings. Both variants are accepted by the eStamp REST API. ### Variant 1b: Signing with signature visualization as a file(`sealSingleWithAppearance`) Seals a PDF document and inserts a visual signature representation at the configured position. The visualization configuration is passed as a JSON file. # eStamp: Seal PDF with siganture visualization (Appearance as JSON file) # Endpoint: POST /signApi/sealSingleWithAppearance # Authentification: Bearer Token required # Return: signed PDF with visualization as binary curl -X POST "https:///signApi/sealSingleWithAppearance" \ -H "Authorization: Bearer " \ -H "Content-Type: multipart/form-data" \ -F "parameterId=" \ -F "documentToSign=@./eingabe.pdf;type=application/pdf" \ -F "signatureAppearance=@./appearance.json;type=application/json" \ --output ./signiert.pdf **Example** `appearance.json`**(Required and optional fields):** { "signatureImageId": "amtsSignatur", "lastPage": -1, "onEveryPage": false, "x": 100, "y": 100, "width": 400, "height": 270, "signaturePageId": "default" } ### Variante 1c: Signieren mit Signaturvisualisierung als ID (`sealSingleWithAppearanceParam`) Versiegelt ein PDF-Dokument mit einer serverseitig hinterlegten Visualisierungskonfiguration. Statt einer JSON-Datei wird nur die `appearanceId` als Query-Parameter übergeben. Die Konfiguration liegt serverseitig und muss nicht bei jedem Aufruf mitgesendet werden. # eStamp: Seal PDF with signature visualization (appearance as server-side ID) # Endpoint: POST /signApi/sealSingleWithAppearanceParam # Authentification: Bearer Token required # Return: signed PDF with visualization as binary curl -X POST "https:///signApi/sealSingleWithAppearanceParam?appearanceId=" \ -H "Authorization: Bearer " \ -H "Content-Type: multipart/form-data" \ -F "parameterId=" \ -F "file=@./eingabe.pdf;type=application/pdf" \ --output ./signiert.pdf ## Signature visualization(`signatureAppearance`): Configuration reference The `signatureAppearance`-configuration controls how the signature is displayed visually in the PDF-position, size, signature image used, and page area. The configuration is always transferred in JSON format. > \[!NOTE\] The `signatureAppearance`-configuration is only relevant if the endpoints `sealSingleWithAppearance` or `addDocumentWithAppearance` are used. For `sealSingle` without vizalisation `signatureAppearance` is not necessary. ### Mandatory fields of `signatureAppearance` | **Field** | **Type** | **Description** | |--------------------|----------|-----------------------------------------------------------------------------| | `signatureImageId` | string | ID of the signature image stored on the server side | | `lastPage` | integer | Last page on which the signature appears (`-1` = last page of the document) | | `onEveryPage` | boolean | `true`: Signature on each page in the defined area; `false`: one-time | | `x` | integer | Horizontal position of the signature on the page (in points, pt) | | `y` | integer | Vertical position of the signature on the page (in points, pt) | ### Optional fields of `signatureAppearance` | **Field** | **Type** | **Standard value** | **Description** | |-----------------------|----------|--------------------|-------------------------------------------------------------------------------------------| | `signaturePageId` | string | -- | ID of an additional signature page that is appended to the document | | `firstPage` | integer | -- | First page on which the signature appears | | `width` | integer | 400 | Width of the signature visualization in pt | | `height` | integer | 270 | Height of the signature visualization in pt | | `signatureAttributes` | object | -- | Additional X.509 certificate attributes for display (only useful for official signatures) | | `signatureFieldId` | string | -- | ID of an existing PDF signature field; replaces manual coordinate specification | > \[!WARNING\] `signaturePageId` and `onEveryPage: true` **must not be set simultaneously** . This combination leads to a `400 Bad Request`-error. ### Special case: Automatic positioning (`visualizationAutomation`) `visualizationAutomation` automatically positions the signature visualization at the end of the last text character on the last page. Manual coordinate entry is not necessary. { "signatureImageId": "amtsSignatur", "signaturePageId": "default", "x": 100, "width": 400, "height": 250, "visualizationAutomation": { "footerHeight": 6, "margin": 10, "signaturePageMargin": 60 } } **Required fields within** `visualizationAutomation`**:** | **Field** | **Description** | |-----------------------|------------------------------------------------------------------| | `footerHeight` | Height of footer in pt | | `margin` | Distance between last text character and signature image in pt | | `signaturePageMargin` | Distance to the signature page when a new page is created, in pt | > \[!WARNING\] When using `visualizationAutomation`, two mandatory conditions apply: `signaturePageId` must be set to a valid value, and `signatureAttributes` must **not** be set. The combination of both special cases (`visualizationAutomation` and `signatureAttributes`) is not supported. ### Special case: Placing a signature in an existing PDF signature field If a PDF already contains signature fields, the visualization can be placed directly in an existing field. Coordinates, page information, and size are then not required. { "signatureImageId": "imageOnly", "signatureFieldId": "Signatur2" } The following fields of `signatureAppearance` are **not** reqired when using `signatureFieldId`: `firstPage`, `lastPage`, `onEveryPage`, `x`, `y`, `width`, `height`. To query the existing signature field IDs of a PDF document, use the following endpoint: # eStamp: Query signature field IDs of a PDF # Endpoint: POST /signApi/signatureFieldNames # Rückgabe: JSON list of signature field IDs in the document curl -X POST "https:///signApi/signatureFieldNames" \ -H "Authorization: Bearer " \ -F "document=@./eingabe.pdf;type=application/pdf" ## Workflow 2: Session-based signing (batch) The session-based signing workflow of the eStamp REST API processes multiple documents within a single session. The process involves several steps and must be carried out in the specified order. **Complete process:** POST /startSession → POST /{sessionId}/addDocument (1--100 times) → POST /{sessionId}/seal → GET /{sessionId}/getDocument/{documentId} (for every document) → POST /{sessionId}/closeSession > \[!WARNING\] The order of the session steps must be **strictly adhered to** . A `getDocument`-call before `seal` returns a `404 Not Found` error. A`addDocument`-call after `seal` returns a `400 Bad Request` error. ### Step 1: Start session (`startSession`) # eStamp: Start batch signing session # Endpoint: POST /signApi/startSession # Return: sessionId as JSON string curl -X POST "https:///signApi/startSession" \ -H "Authorization: Bearer " \ -H "Content-Type: multipart/form-data" \ -F "parameterId=" **Successful response (200 OK):** "a1b2c3d4-e5f6-7890-abcd-ef1234567890" The returned `sessionId` is required as a path parameter for all subsequent calls. ### Step 2: Add documents (`addDocument`) # eStamp: Add document to session # Endpoint: POST /signApi/{sessionId}/addDocument # Return: documentId as integer (JSON) # This step is repeated for each document individually (max. 100 per session) curl -X POST "https:///signApi//addDocument" \ -H "Authorization: Bearer " \ -F "documentToSign=@./dokument1.pdf;type=application/pdf" **Successful response (200 OK):** 1 The returned `documentId` is required in step 4 (`getDocument`) benötigt. Each added document is assigned its own `documentId`. > \[!NOTE\] Once added, documents **cannot be replaced or removed** within a session. If an incorrect document has been added, a new session must be started. Alternatively, the following `addDocument`-variants are available: | **Endpoint** | **Usage** | |-----------------------------------------------|-------------------------------------------------------| | `/{sessionId}/addDocument` | Add document without visualization, | | `/{sessionId}/addDocumentWithAppearance` | Add document with `signatureAppearance` as JSON file. | | `/{sessionId}/addDocumentWithAppearanceParam` | Add document with server-side stored `appearanceId`. | ### Step 3: Seal all documents (`seal`) # eStamp: Seal all documents in the session # Endpoint: POST /signApi/{sessionId}/seal # Return: no body (empty 200 response) # Timeout: 60--120 seconds for the entire sealing process curl -X POST "https:///signApi//seal" \ -H "Authorization: Bearer " The `seal`-call blocks until all documents in the session are signed and does not return any content data. The signed documents are then retrieved using `getDocument`. ### Step 4: Retrieve signed documents (`getDocument`) # eStamp: Retrieve signed document from session # Endpoint: GET /signApi/{sessionId}/getDocument/{documentId} # Return: Signed PDF as binary # This step is performed individually for each documentId curl -X GET "https:///signApi//getDocument/" \ -H "Authorization: Bearer " \ --output ./signiert-dokument1.pdf ### Step 5: Close session (`closeSession`) # eStamp: Close batch signing session # Endpoint: POST /signApi/{sessionId}/closeSession # Return: no body curl -X POST "https:///signApi//closeSession" \ -H "Authorization: Bearer " > \[!NOTE\] eStamp sessions that are not closed manually are automatically cleaned up after **40 minutes** . A session that exceeds 40 minutes returns error `412 Precondition Failed` (Illegal session id) on subsequent calls. ## Workflow 3: Signature validation The validation workflow of the eStamp REST API checks the signature of an existing PDF or XML document and returns a validation report. ### Validate PDF signature # eStamp: Validate PDF signature # Endpoint: POST /signApi/validatePdf # Parameter reportType: "xml" (default) or "pdf" # Return: Validation report as XML or PDF binary curl -X POST "https:///signApi/validatePdf" \ -H "Authorization: Bearer " \ -F "reportType=xml" \ -F "file=@./signiert.pdf;type=application/pdf" \ --output ./validierungsreport.xml ### Validate XML signature # eStamp: Validate XML signature # Endpoint: POST /xmlSignApi/validateXml # Parameter reportType: "xml" (default) or "pdf" # Return: Validation report as XML or PDF binary curl -X POST "https:///xmlSignApi/validateXml" \ -H "Authorization: Bearer " \ -F "reportType=pdf" \ -F "file=@./signiert.xml" \ --output ./validierungsreport.pdf **Available** `reportType`**-** values**:** | **Value** | **Return format** | |------------------|-----------------------| | `xml` (standard) | XML-validation report | | `pdf` | PDF-validation report | ## FAQ: Workflows and frequently asked questions ### What is the difference between synchronous and session-based workflows? The synchronous workflow of the eStamp REST API processes a single document per API call and returns the result immediately --- no sessions, no caching. The session-based workflow enables batch processing of up to 100 documents per session in a multi-step process. The synchronous workflow is simpler for individual documents; the session-based workflow is necessary for batch processing. ### How many documents can be processed per session? A maximum of **100 documents** can be processed per eStamp batch session. If more than 100 documents need to be signed, multiple sessions must be started. There is no limit to the number of sessions that can run in parallel. ### How long is an eStamp session valid? An eStamp batch session is valid for **40 minutes** from the `startSession`call. Sessions that are not completed are automatically cleared after 40 minutes. A single API call within a session may take a maximum of **30 seconds**; if this time is exceeded, the call is canceled. ### Can I check the progress of a running `seal`-call? No. eStamp does not offer status endpoints, polling, or webhooks. The seal call blocks until all documents in the session are signed (maximum 60--120 seconds) and then returns an empty 200 response. ### Can I remove documents from a session after adding them? No. Once documents have been added to the session, they cannot be removed or replaced. If an incorrect document has been added, a new eStamp session must be started via startSession. ### Is there partial failure in session processing? No. eStamp does not support partial failure. A batch operation is either completely successful or completely fails. There is no partial processing of individual documents within a session. ### What happens when a session expires or a timeout occurs? When the 40-minute session validity expires, eStamp returns 412 Precondition Failed for subsequent calls. If a single API call times out (30 seconds), the call is canceled and an error message is returned. In both cases, no partial processing takes place. Expired sessions are automatically cleaned up. --- version: "v2" language: "de" --- # MOXIS Plugins Übersicht ## MOXIS Plugins Übersicht ### Documentation #### [Explorer to MOXIS Plugin Handbuch](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/explorer-to-moxis-plugin-handbuch.md) #### [Adobe to MOXIS Plugin Handbuch](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/adobe-to-moxis-plugin-handbuch.md) #### [Office to MOXIS Manual](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/office-to-moxis-handbuch.md) #### [SharePoint to MOXIS](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/sharepoint-to-moxis.md) #### [XiTrust MOXIS Teams-Connector Plugin Handbuch](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/xitrust-moxis-teams-connector-plugin-handbuch.md) #### [MOXIS Connector für Salesforce (Admin Guide)](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/moxis-connector-fur-salesforce-admin-guide.md) --- version: "v2" language: "de" --- # Adobe to MOXIS Handbuch **Inhalt** Mit dem Spring Release 2024 wurde XiTrust um eine Erweiterung reicher: Adobe to MOXIS. Das Plugin erlaubt ab nun die direkte Übertragung von PDF-Dokumenten zu MOXIS. Dieses Handbuch bietet Ihnen einen Überblick über die Installation und die Handhabe der MOXIS Erweiterung. *** ** * ** *** ## 1. Technische Details Das Adobe to MOXIS Plugin ist im Moment (Stand 09/2024) auf Englisch und Deutsch erhältlich. Folgende Versionen des Adobe Acrobat Readers werden aktuell von dem Plugin unterstützt: * Adobe Acrobat Reader 64 Bit * Adobe Acrobat Reader 32 Bit * Adobe Acrobat Standard 64 Bit * Adobe Acrobat 64 Bit Die Installation ist über ein zentral gesteuertes file rollout möglich. ## 2. Setup und Installation Um das Plugin zu installieren, laden Sie es bitte von der XiTrust Website herunter. **XiTipp** Je nach Acrobat Reader, den Sie in Verwendung haben, müssen Sie entweder die 32Bit- oder die 64Bit-Variante herunterladen. Download 32Bit Version: [Link](https://www.xitrust.com/download/acrobat/XiTrust-Adobe2MOXIS-32bit.zip) Download 64Bit Version: [Link](https://www.xitrust.com/download/acrobat/XiTrust-Adobe2MOXIS-64bit.zip) **Bitte beachten Sie:** Im Fall von On Premises Installationen muss außer der kundenspezifischen MOXIS Domain/URL über 443 auch freigeschaltet sein. Bei Fragen wenden Sie sich bitte an Ihre:n zuständige:n XiTrust Ansprechpartner:in. ### 2.1. Schritt-für-Schritt Anleitung: Installation des Plugins **Schritt 1:** Laden Sie die für Sie passende Version herunter und extrahieren Sie sie (siehe *Abbildung 1* ). **Bitte beachten Sie:** Es ist erforderlich, dass Sie den passenden Pfad für die jeweilige Version des Acrobat Readers angeben. Bitte verwenden Sie daher die folgenden Pfade. * **Für 64Bit:** C:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\plug_ins\\ * **Für 32Bit:** C:\\Program Files\\Adobe\\Acrobat DC\\Reader\\plug_ins\\moxis_plugin * **Für 32Bit:** C:\\Program Files (x86)\\Adobe\\Acrobat Reader DC\\Reader\\plug_ins\\moxis_plugin ![01a_Zip_Files.png](https://documentation.moxis.co/__attachments/a_f994b3319d5e6dc2996ed22a514ff5b21a74e0277afaf13ac5466e81a3600569/01a_Zip_Files.png?cb=391ec2e202b49c340c2c891a626ab2e9) *Abbildung 1: Extraktion des ZIP-files nach C:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\plug_ins\\ für 64Bit-Files* **XiTipp** **Bitte beachten Sie:**Aktuell (Stand 09/24) kann es sein, dass Sie einen Warnhinweis von Windows Defender erhalten. Bitte führen Sie die Installation dennoch fort. **Schritt 2:** Öffnen Sie wie gewohnt ein Dokument Ihrer Wahl im Adobe Acrobat Reader. Nun navigieren Sie im Menü (siehe *Abbildung 2 \[1\]* ) zum Reiter Plugins (siehe *Abbildung 2 \[2\]* ) \> Moxis (siehe *Abbildung 2 \[3\]* ) \> Acrobat to MOXIS und klicken auf den Menüpunkt (siehe *Abbildung 2 \[4\]*). ![03a_Adobe2MOXIS_aufrufen.png](https://documentation.moxis.co/__attachments/a_0388a9100bf61683e142f86ccd9cb96935f4da54b259d0ea9d597d40fd6e0ca3/03a_Adobe2MOXIS_aufrufen.png?cb=ad00f066771327fd116fdab18b779f90) *Abbildung 2: Öffnen Sie Acrobat2MOXIS im Acrobat Reader* **Schritt 3:** Im nächsten Schritt hinterlegen Sie bitte einmalig Ihre MOXIS-Instanz (siehe *Abbildung 3 \[1\]* ) und klicken auf den **\[Pair\]** -Button (siehe *Abbildung 3 \[2\]* ). In unserem Beispiel lautet die MOXIS-Instanz demo.moxis.cloud (siehe*Abbildung 3 \[1\]*). Bitte geben Sie im dafür vorgesehenen Feld Ihre persönliche Instanz ein. ![04a_Instanz_hinterlegen_und_Pairen.png](https://documentation.moxis.co/__attachments/a_c894b41374a21fbe1cd55e76dafa3a0c624d485d1b8e3ae30448a3d15d7ff68f/04a_Instanz_hinterlegen_und_Pairen.png?cb=def6f736a685dc47c01b7e676c208a3e) *Abbildung 3: Hinterlegen der MOXIS-Instanz (hier als Beispiel unseres Demo-Instanz-URL) und Pairen der Instanz mit dem Acrobat Reader* Die Installation ist somit abgeschlossen. ### 2.2. Signieren von Dokumenten mit Acrobat to MOXIS Um ein Dokument über das Plugin zu signieren, öffnen Sie es bitte und laden ein PDF-Dokument hoch (siehe *Abbildung 4 \[1\]* ) und klicken Sie auf den **\[Upload\]** -Button (siehe *Abbildung 4 \[2\]*). ![05a_Signieren.png](https://documentation.moxis.co/__attachments/a_2028d8a441d0441f813990272e974c6034e007325f02bb494d23f68248b578f9/05a_Signieren.png?cb=d2a0d1f6c4ea343444b869c7b029d3da) *Abbildung 4: Dokument hochladen* **XiTipp** Vor dem Upload können Sie den Titel des Dokuments ändern und ihn Ihren Wünschen gemäß anpassen. Sollte das Hochladen eines Dokuments nicht funktionieren, prüfen Sie bitte, ob der Dokumentenname Umlaute oder spezielle Sonderzeichen enthält. **Bitte beachten Sie:** Das Dokument darf nicht beschädigt sein und muss bestimmte PDF Normen erfüllen. Sollten Sie sich bezüglich eines Dokuments unsicher sein, wenden Sie sich bitte an unseren Support unter [servicedesk@xitrust.com](mailto:servicedesk@xitrust.com), da das Ändern eines Dokuments die Unterschrift ungültig machen könnte. Sodann steigen Sie in Ihre MOXIS Instanz ein und wählen den Prozess aus, unter welchem das Dokument signiert werden soll (siehe *Abbildung 5*). ![06a_MOXIS.png](https://documentation.moxis.co/__attachments/a_e5aeab2a1b07c66d207ce0345c642dd96ca77c029531aa492680f179fddb23a2/06a_MOXIS.png?cb=0efd45f213c383f8d4d3316fa5ffa00e) *Abbildung 5: Prozess in MOXIS auswählen* Nun können Sie wie gewohnt mit der Bearbeitung Ihres Auftrags fortfahren. --- version: "v2" language: "de" --- # Adobe to MOXIS Plugin Handbuch * [Adobe to MOXIS Handbuch](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/adobe-to-moxis-handbuch.md) --- version: "v2" language: "de" --- # Explorer to MOXIS Handbuch **Inhalt** Das folgende Handbuch versorgt Sie mit einer Übersicht über das aktuelle Explorer to MOXIS Addon von XiTrust. Explorer to MOXIS erlaubt es Ihnen, Ihre Arbeitsabläufe effizient zu gestalten und MOXIS direkt über den Browser (Explorer) zu bedienen. ## 1 Wissenswertes rund um Explorer to MOXIS und Installation ### 1.1 Bedingungen zur Nutzung von Explorer to MOXIS **XiTipp** **Bitte beachten Sie: Explorer to MOXIS** kann **kostenfrei** aus dem Microsoft Store heruntergeladen werden, jedoch ist ein aktives **MOXIS-Abonnement** zusammen mit der Annahme der **MOXIS-Cloud-Servicebestimmungen** erforderlich. Wenn **MOXIS** für Sie neu ist und Sie Ihre Signaturprozesse um bis zu 90% beschleunigen möchten, registrieren Sie sich [hier](https://www.xitrust.com/demo-buchen/) für eine **kostenlose Demo** für die **MOXIS Business Cloud** . Unsere Vertriebsmitarbeiter:innen beraten Sie gerne, wie Sie **MOXIS** für Ihr Unternehmen **gewinnbringend**einsetzen können. Wenn Sie bereits über ein **MOXIS-Abonnement** verfügen, unterliegt die Nutzung des**Explorer to MOXIS-Add-ins** und die damit verbundene Verarbeitung personenbezogener Daten den **MOXIS-Bedingungen** einschließlich der für die erworbenen MOXIS-Versionen geltenden **Datenverarbeitungsvereinbarung**: * MOXIS Cloud Service Provisions, * Enterprise On-Prem Perpetual License Provisions * oder Enterprise On-Prem Subscription Provisions **XiTipp** **Bitte beachten Sie:**Voraussetzung für die Installation ist Windows 11. ### 1.2 Die Grundfunktionen von Explorer to MOXIS **XiTipp** Explorer to MOXIS ist eine rechtskonforme **E-Signature-Lösung** für den **Explorer**. Es ist ein effizientes Tool, das Zeit, Aufwand und somit Kosten spart. Explorer to MOXIS ermöglicht es Ihnen, Ihre PDF-Dokumente sicher in MOXIS hochzuladen, wo Sie sie mit den höchsten rechtlichen Standards hinsichtlich der Signaturqualität verarbeiten. Somit steigern Sie die Effizienz Ihrer Arbeitsabläufe für elektronische Unterschriften mit einem simplen Rechtsklick im Explorer. #### 1.2.1 Explorer to MOXIS: Schnellanleitung **Schritt 1:** Erstellen Sie Ihre zu signierenden **PDF-Dokumente** bequem wie gewohnt. **Schritt 2:** Wechseln Sie dann nahtlos zu einem beliebigen in **MOXIS** verfügbaren **Signaturverfahren** über das**Explorer to MOXIS** **Add-In** von **XiTrust**. **Schritt 3:** Nutzen Sie die Möglichkeiten von MOXIS, um den Signaturprozess nach Ihren Wünschen zu gestalten: * Signaturqualität einrichten, * Entscheidungsebenen definieren, * Empfänger:innen bestimmen * uvm. **Schritt 4:** Versenden Sie den **Link** zum **Dokument** per **E-Mail** an interne und externe Signierende unter der Einhaltung**höchster Rechts- und Sicherheitsstandards** . Sobald der **Signiervorgang** abgeschlossen ist, können Sie das **Dokument herunterladen** und an einem Ort Ihrer Wahl speichern. ### 1.3 Schritt für Schritt zu Explorer to MOXIS: Die Installation Diese Anleitung bringt Ihnen die Erstinstallation von Explorer to MOXIS näher. **XiTipp** Bitte stellen Sie sicher, dass Sie über .NET 8.0 verfügen. Alternativ können Sie das Programm hier herunterladen (für Linux, macOS oder Windows): Bitte starten Sie Ihre Anwendung neu, nachdem Sie .NET 8.0 installiert haben um sicherzustellen, dass alles ordnungsgemäß funktioniert. **Schritt 1:** Explorer to MOXIS kann über den Microsoft Store installiert werden. Um die Installation durchzuführen, öffnen Sie bitte den folgenden Link [ExplorerToMOXIS -- Kostenloser Download und Installation unter Windows \| Microsoft Store](https://apps.microsoft.com/detail/9n9w4v0xgdpl?hl=de-DE&gl=DE) und klicken auf den **\[Im Store anzeigen\]** -Button (siehe *Abbildung 1 \[1\]*). ![01a_Micorsoft_Store_Anmeldung.png](https://documentation.moxis.co/__attachments/a_c727b817b262f079ec2d449f1294b24f4517fa7e978d1c3093bd8f34e442238f/01a_Micorsoft_Store_Anmeldung.png?cb=b0883b23c6d3192f8c21ac0f8dac8772) *Abbildung 1: ExplorerToMOXIS im Microsoft Store* **Schritt 2:** Laden Sie nun das Plugin mit einem Klick auf den**\[Herunterladen\]** -Button aus dem Store herunter (siehe *Abbildung 2 \[1\]*). ![02a_Explorer_To_MOXIS_herunterladen.png](https://documentation.moxis.co/__attachments/a_8b2604836f217e3cc345d7541ebf4d263c4809fcbcbbac42946d741b74752968/02a_Explorer_To_MOXIS_herunterladen.png?cb=fe88c53015a398a8e10ec0fc74b8f93b) *Abbildung 2: ExplorerToMOXIS herunterladen* **Schritt 3:** Sobald Explorer to MOXIS verfügbar ist, verwandelt sich der **\[Herunterladen\]** -Button in einen **\[Öffnen\]** -Button (siehe *Abbildung 3 \[1\]* ) und Sie erhalten eine Benachrichtigung aus dem Microsoft Store, dass die Installation abgeschlossen wurde und Sie das Plugin jetzt mit einem Klick auf den **\[Starten\]** -Button ausprobieren können (siehe *Abbildung 3 \[2\]*). Bitte wählen Sie eine der beiden Möglichkeiten, um das Plugin zu starten. ![03a_Explorer_To_MOXIS_öffnen.png](https://documentation.moxis.co/__attachments/a_db3cc353b742d69b22787f85f02a672310a5fa3d36a8c402dabd01c201fbca93/03a_Explorer_To_MOXIS_%C3%B6ffnen.png?cb=ab61b020498b5df1cb9496fa3e351e09) *Abbildung 3: ExplorerToMOXIS öffnen* **Schritt 4 (OPTIONAL):** Sollten Sie (noch) nicht über .NET 8.0 verfügen, erhalten Sie nun die Meldung, es jetzt zu installieren. Klicken Sie dazu auf den **\[Download it now\]** -Button (siehe *Abbildung 4*). **XiTipp** Sofern Sie .NET 8.0 bereits vorab installiert haben, springen Sie bitte zu **Schritt 5**. ![04a_Infofenster_Download.png](https://documentation.moxis.co/__attachments/a_7a6ab79b65d9fb5d0d57a61c1eaeb2ed1727df29412329cbfd55b36e4b5f23fd/04a_Infofenster_Download.png?cb=11861cc21ca951a0c36699ba536680e8) *Abbildung 4: Herunterladen von .NET 8.0 (Optional)* Sobald das Download vollständig durchgeführt wurde, erhalten Sie eine Bestätigung (siehe *Abbildung 5*). ![05_Bestätigung_Infofenster_Download.PNG](https://documentation.moxis.co/__attachments/a_fdc2ed88f2f488bc37952aad920cb6de723deb4fc0df763bb541177cca444df8/05_Best%C3%A4tigung_Infofenster_Download.PNG?cb=d880ce447b9709d223458be140fa3e7f) *Abbildung 5: Bestätigung über das Download (OPTIONAL)* Bitte führen Sie nun die .exe-Datei aus, sodass das Programm installiert wird (siehe *Abbildung 6 \[1\]*). **XiTipp** Danach starten Sie Ihren Computer neu um sicherzustellen, dass alles ordnungsgemäß funktioniert. ![07a_Exe_Datei_ausführen.png](https://documentation.moxis.co/__attachments/a_ea2f1277cf0812debb4e2b2bf87724951cddd781c91671d81deeefebb32f2224/07a_Exe_Datei_ausf%C3%BChren.png?cb=259af81e355df67ee27ea67c8072a064) *Abbildung 6: Programm ausführen* **Schritt 5:** Um Explorer to MOXIS zum ersten Mal zu starten, öffnen Sie bitte die Windows Suchleiste und suchen nach Explorer to MOXIS (siehe *Abbildung 7*). **XiTipp** Heften Sie Explorer to MOXIS mit einem Klick auf *An "Start anheften"* (siehe *Abbildung 7*) an die Startleiste an, um immer bequem darauf zurückgreifen zu können. ![06_Explorer_To_MOXIS_öffnen.PNG](https://documentation.moxis.co/__attachments/a_a643197ad75ef48ceb5c0572166fbc0232f0b20c72b23c8ac42afd323722bd13/06_Explorer_To_MOXIS_%C3%B6ffnen.PNG?cb=8a550f399d9b52b8c634ded7799714ad) *Abbildung 7: Explorer to MOXIS zum ersten Mal öffnen und an Start anheften* Nun müssen Sie nur noch Ihre MOXIS Instanz mit Explorer to MOXIS verbinden. Der nächste Abschnitt gibt Aufschluss über die einzelnen Schritte. ## 2. So verbinden Sie Explorer to MOXIS mit Ihrer MOXIS Instanz Die Verknüpfung Ihrer MOXIS Instanz via URL ist nur bei der ersten Anwendung des Add-Ins notwendig oder wenn sich die MOXIS URL ändert. Um MOXIS mit Explorer to MOXIS zu verknüpfen, folgen Sie bitte der Schritt-für-Schritt-Anleitung. **Schritt 1:**Öffnen Sie Explorer to MOXIS wie im vorherigen Kapitel beschrieben. **Schritt 2:** Mit einem Klick auf das Zahnrad-Icon (siehe *Abbildung 8 \[1\]*) öffnen Sie die Einstellungen am Dashboard des Plugins. Hier können Sie Explorer to MOXIS mit Ihrer aktuellen MOXIS-Instanz verbinden. ![01a_Startseite_Explorer_to_MOXIS.png](https://documentation.moxis.co/__attachments/a_0b061fc35fb2eb3e6090532e6cb45b1990e65977f66ee6494ad609f262880fb8/01a_Startseite_Explorer_to_MOXIS.png?cb=474e247f98f6deee375848ba4947a2de) *Abbildung 8: Explorer to MOXIS Einstellungen öffnen* **Schritt 3:** Geben Sie nun die **URL** Ihrer **MOXIS Instanz** in den Settings ein (siehe *Abbildung 9 \[1\]* ) und klicken Sie auf den **\[Speichern\]** -Button (siehe *Abbildung 9 \[2\]* ). Ist Ihre Instanz erfolgreich verbunden, erhalten Sie eine entsprechende Erfolgsmeldung in grün (siehe *Abbildung 9 \[5\]*). **XiTipp** **Beachten Sie bitte:** Verwenden Sie nur die **KURZFORM** der **URL** (OHNE ui/protected/#!dashboard), da sie Ihre Instanz darstellt! Sollten Sie die **Langform** verwenden, **schlägt** die **Verbindung fehl** und Sie erhalten eine **Fehlermeldung**. In unserem Beispiel geben wir folglich die folgende **Kurzform** der URL in den MOXIS Settings ein: [https://demo50.moxis.cloud](https://documentation.moxis.cloud/) (siehe *Abbildung 10* ) Die **Langform** (welche im **Browser standardmäßig** angezeigt wird) ist: [https://demo50.moxis.cloud/ui/protected/#!dashboard](https://documentation.moxis.cloud/ui/protected/#!dashboard). (siehe *Abbildung 10*) Abgesehen von der Verbindung zwischen Ihrer MOXIS Instanz und Explorer to MOXIS haben Sie in den Einstellungen folgende Möglichkeiten: * legen Sie Ihr präferiertes Theme fest (hell \[light\] - dunkel \[dark\] - standard \[default\]; (siehe *Abbildung 9 \[3\]*)) * erhalten Sie Auskunft über Ihre Explorer to MOXIS-Version (siehe *Abbildung 9 \[4\]*) ![02a_Explorer_To_MOXIS_verbinden.png](https://documentation.moxis.co/__attachments/a_5d9900683144badf0a6c396151c46663969c2400e8dd86799006c10fc00d3a3e/02a_Explorer_To_MOXIS_verbinden.png?cb=a36f40065a3c9dfaa87a2ca2a7bff9ef) *Abbildung 9: Explorer to MOXIS Einstellungen* ![4_Korrekter_Link_für_Anmeldung.PNG](https://documentation.moxis.co/__attachments/a_b3f299e13c515b18c009c4ecb17d3f0c9ec4f1591fab6ce0de922166f2b3bbde/4_Korrekter_Link_f%C3%BCr_Anmeldung.PNG?cb=b9a70ee2f850cfa60b7e00ba9436fa85) *Abbildung 10: Kurzform (korrekt) vs. Langform (in blau hervorgehoben) der URL - bitte verwenden Sie nur die Kurzform* **Schritt 4: Wir gratulieren! Sie haben Ihre Instanz erfolgreich mit Explorer to MOXIS verbunden.** ## 3. Einfach signieren mit Explorer to MOXIS - so starten Sie den Signaturprozess Es gibt **zwei Möglichkeiten** , **Signaturaufträge** via **Explorer to MOXIS** zu starten: * direkt über den**Explorer (empfohlen)** oder * über den **Desktop**. Der darauffolgende Signaturprozess ist immer der gleiche. ### 3.1 Signaturprozess in Explorer to MOXIS über den Explorer starten (empfohlen) **Schritt 1:** Öffnen Sie den Explorer und navigieren Sie zu dem Dokument, das Sie unterschreiben lassen möchten. Ein einfacher Rechtsklick auf das Dokument öffnet ein Menü (siehe *Abbildung 11).* **Schritt 2:** Im nächsten Schritt klicken Sie bitte auf Sign with MOXIS (siehe*Abbildung 11 \[1\]*). . ![02a_Explorer_to_MOXIS_öffnen.png](https://documentation.moxis.co/__attachments/a_7a82284b2f57bdff4cb29640e16eb2d927edc3538f013cdbda9ef5711f38d592/02a_Explorer_to_MOXIS_%C3%B6ffnen.png?cb=11a67dfbe5ce70fffa53ce468c0abad9) *Abbildung 11: Signaturprozess über Explorer to MOXIS starten* **Schritt 3:** Sofern Sie in MOXIS eingeloggt sind, öffnet sich jetzt automatisch die MOXIS-Oberfläche. Alternativ müssen Sie sich als Zwischenschritt kurz einloggen. So oder so - in der nun geöffneten Oberfläche wählen Sie bitte Ihren gewünschten Prozess aus (siehe*Abbildung 12*). Danach können Sie den Signaturauftrag wie gewohnt abschließen. Eine Beschreibung dazu finden Sie in Kapitel 4. ![03a_Prozess aussuchen.png](https://documentation.moxis.co/__attachments/a_ea26f139cb872b82a89d0543935f7b351f072eeedbe2e8574bd109eadcbf4d5b/03a_Prozess%20aussuchen.png?cb=ca3f90e12b39904baa4c301f91113239) *Abbildung 12: Prozess wählen* ### 3.2 Signaturprozess in Explorer to MOXIS über den Desktop starten **Schritt 1:** Um einen **Signaturauftrag** via **Explorer to MOXIS** über den Desktop anzustoßen, öffnen Sie das Plugin und ziehen das **PDF, das Sie signieren wollen,** bitte per drag and drop in das graue Feld (siehe *Abbildung 13*). ![01b_Startseite_Explorer_to_MOXIS.png](https://documentation.moxis.co/__attachments/a_ee6ed32f5d39b7a6776c3e53e31e62abc2b0527d6a5dab0afe69d580bc3839d6/01b_Startseite_Explorer_to_MOXIS.png?cb=f6e5c7df9c473a45211e459872c46982) *Abbildung 13: Explorer to MOXIS Oberfläche - ziehen Sie ein PDF zum Signieren ins graue Feld* **Schritt 2:** Sobald Sie das PDF in das Feld verschoben haben, öffnet sich die **MOXIS-Oberfläche** (siehe *Abbildung 14 \[2\]* ). Gleichzeitig erhalten Sie eine Meldung darüber, dass das PDF erfolgreich hochgeladen wurde (siehe *Abbildung 14 \[1\]* ). **Bitte beachten Sie:**Voraussetzung dafür, dass sich die MOXIS Oberfläche sofort öffnet, ist, dass Sie bereits in Ihrer MOXIS-Instanz angemeldet sind. Ansonsten müssen Sie sich in einem Zwischenschritt anmelden. ![04a_PDF_signieren.png](https://documentation.moxis.co/__attachments/a_2c62873c12910dd0fe2efd7d8bc2cffc3e8c84c527b216a10f975decfd5d90b0/04a_PDF_signieren.png?cb=84e549fd782c664bb71e4137c53d9678) *Abbildung 14: Starten eines Signiervorgangs via Explorer to MOXIS (Desktop)* Danach können Sie den Signaturauftrag wie gewohnt abschließen. Eine Beschreibung dazu finden Sie im nächsten Kapitel. ## 4. So schließen Sie die Auftragsanlage ab Nachdem Sie den Prozess gewählt haben, öffnet sich das **zu signierende PDF** und Sie können das zu **unterzeichnende Dokument** wie gewohnt als Auftrag bearbeiten. Im Zuge der**Bearbeitung** des **Signaturauftrags** (siehe *Abbildung 15* ) **definieren**Sie bitte: * ob Sie eine oder mehrere [Entscheidungsebenen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.50/v4-50-entscheidungsebenen-definieren.md) benötigen (in unserem Beispiel ist es eine; siehe *Abbildung 15 \[1\]*) * die [Signaturqualität](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.50/v4-50-signaturqualitaten-bestimmen.md) (in unserem Beispiel ist es eine qualifizierte Signatur; siehe *Abbildung 15 \[2\]*) und * die [Anzahl und Qualität](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.50/v4-50-empfanger.md) (intern/extern) der Empfänger:innen Fügen Sie einen oder mehrere [**Platzhalter**](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.50/v4-50-einfuhrung-zum-platzhaltergenerator-optional.md)für die **Unterschriften** hinzu und klicken Sie auf den **\[Auftrag signieren\]**-Button. ![04a_Signaturprozess.png](https://documentation.moxis.co/__attachments/a_0e391c2e4e9f03b879a47bd0c727d5fa340d40eae813310721aff7533b152dfe/04a_Signaturprozess.png?cb=ca64788f6662b65919989cec73dfd542) *Abbildung 15: Abschließen der Auftragsanlage* Danach werden Sie automatisch zur Übersicht **Gesendete Aufträge** weitergeleitet. Hier sehen Sie den**aktuellen Auftrag** und können folgende [**Parameter**](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.50/v4-50-die-detailansicht.md)ablesen: * Empfangsdatum * Empfangszeit * Anzahl der Signaturen * Auftragsnummer * Ablaufdatum * Ablaufzeit Wir gratulieren! Sie haben Ihren ersten **Signaturauftrag** mithilfe von**Explorer to MOXIS**erstellt. --- version: "v2" language: "de" --- # Explorer to MOXIS Plugin Handbuch * [Explorer to MOXIS Handbuch](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/explorer-to-moxis-handbuch.md) --- version: "v2" language: "de" --- # Installation des MOXIS Connector für Salesforce Dieses Kapitel beschreibt die Schritte, die für die Ersteinrichtung des MOXIS Connectors für Salesforce erforderlich sind. *** ** * ** *** ## 1 Installation des MOXIS Connector für Salesforce Packages Bitte öffnen Sie den bereitgestellten Installationslink, um das Paket in Ihrer Salesforce-Organisation zu installieren. Befolgen Sie sodann die Anweisungen auf dem Bildschirm zur Installation des Pakets. ### 1.1 Named Credential Setup Damit der Connector MOXIS erreichen kann, sind Named Credentials erforderlich. Gehen Sie zu „Setup" und öffnen Sie den Menüpunkt „Named Credentials" (siehe *Abbildung 1*). Erstellen Sie eine neue "Named Credential" mit den Informationen aus der unten anstehenden Tabelle. | **Feld** | **Wert** | |-------------------------|-----------------------------------------| | Label | (jegliche Eingabe möglich, z. B. MOXIS) | | Name | MOXIS | | URL | (bereitgestellte MOXIS API URL) | | Identity Type | Named Principal | | Authentication Protocol | Password Authentication | | Username | (bereitgestellter API Username) | | Password | (bereitgestelltes API Passwort) | Lassen Sie die anderen Einstellungen unverändert und klicken Sie auf den **\[Speichern\]**-Button. ![image-20251124-145337.png](https://documentation.moxis.co/__attachments/a_6feaee988a88186963a9b4f3eafa1d66608fd77cb8455dd56d0a20aa880cb582/image-20251124-145337.png?cb=0b1d0db228b26845f57240a263da3964) *Abbildung 1: Erstellen von neuen "Named Credentials"* ### 1.2 Setup der MOXIS Connector Settings Öffnen Sie den Tab *Setup* und öffnen Sie dort den Menüpunkt *Benutzerdefinierte Metadatentypen* . Suchen Sie dort nach den *MOXIS Connector-Einstellungen* und klicken Sie auf *Datensätze verwalten* . Dort sollte finden Sie einen Datensatz namens „*MOXIS* ". Klicken Sie dort auf den **\[Bearbeiten\]**-Button. **XiTipp** Sollte kein MOXIS-Datensatz vorhanden sein, erstellen Sie einen neuen Datensatz und benennen Sie ihn „MOXIS". Sobald Sie im Bearbeitungsmodus des MOXIS-Datensatzes sind, geben Sie in der Tabelle unten anstehenden Daten ein und klicken Sie auf den **\[Speichern\]**-Button. | **Feld** | **Wert** | |-------------------------|------------------------------------------------------------------| | MOXIS Draft Process Url | (bereitgestellte base URL for MOXIS Draft Process) | | MOXIS Internal Sign Url | (bereitgestellte base URL for internal signing of MOXIS Process) | ![image-20251124-150511.png](https://documentation.moxis.co/__attachments/a_8bf7edcf1d6e3f74fd7be3b858db3a2e54d4f17f3487993cd21b0e88f4d48e1c/image-20251124-150511.png?cb=aaec32c2fce404d04b65ac585e913ed5) *Abbildung 2: MOXIS Connector Settings* ### 1.3 MOXIS Integration Permission Set erstellen Erstellen Sie eine neue Berechtigungsgruppe, indem Sie zu „Einrichtung" gehen und den Menüpunkt *Permission Settings* öffnen. Suchen Sie die vorhandene Berechtigungsgruppe *MOXIS-Integration* und klicken Sie auf den **\[Klonen\]** -Button, um sie zu klonen. Geben Sie ihr einen beliebigen Namen und speichern Sie sie. Passen Sie die Berechtigungen für die geklonte Berechtigungsgruppe wie in der folgenden Tabelle dargestellt an: | **Einstellung** | **Wert** | |------------------------------------------|----------| | System Permissions \> Apex Rest Services | Checked | ### 1.4 Setup MOXIS Integration Connected App | **Einstellung** | **Wert** | |-----------------------|-----------------------------------------------------| | Connected App Name | (jeglicher Wert, zum Beispiel MOXIS Integration) | | API Name | (jeglicher Wert, zum Beispiel MOXIS Integration) | | Kontakt E-Mail | (jeglicher Wert, zum Beispiel Admin E-Mail Adresse) | | Enable OAuth Settings | Check | | Callback URL | https:// | | Selected OAuth Scopes | Access and manage your data (api) | Klicken Sie auf den **\[Speichern\]** -Button. Wenn Sie in einer Meldung darüber informiert werden, dass die Änderungen erst nach einer gewissen Zeit wirksam werden, klicken Sie auf den **\[Weiter\]**-Button. Klicken Sie sodann auf den \[Bearbeiten\]-Button und bearbeiten Sie die Policies folgendermaßen: | **Einstellung** | **Wert** | |-----------------|------------------------------------------| | Erlaubte User | Admin approved users are pre-authorised. | Klicken Sie auf den **\[Speichern\]** -Button. Klicken Sie auf derselben Seite in der Liste auf *Berechtigungen* auf *Berechtigungen verwalten* . Wählen Sie die neu erstellte Berechtigung aus (geklont von „MOXIS Integration") und klicken Sie auf den **\[Speichern\]**-Button. ### 1.5 Setup MOXIS Integration User Für die Integration von MOXIS in Salesforce muss ein Benutzer zugewiesen werden, der für die Benachrichtigungen über Statusänderungen der MOXIS-Signaturprozesse zuständig ist. Richten Sie dazu entweder einen neuen Benutzer ein (empfohlen) oder verwenden Sie einen bestehenden Benutzer. Weisen Sie dem Benutzer den neu erstellten Berechtigungssatz zu (geklont aus „MOXIS-Integration"). Notieren Sie sich den Benutzernamen, das Passwort und das Sicherheitstoken für diesen Benutzer. ### 1.6 Konfiguration der MOXIS Integration Um die Statusaktualisierung von MOXIS zu Salesforce einzurichten, sollten dem MOXIS-Administrator die folgenden Informationen zur Verfügung gestellt werden. | **Info** | **Beschreibung** | |---------------------------|-------------------------------------------------------------------| | Org Url | URL der Salesforce Instanz (zB https:((my-company.salesforce.com) | | Client ID | aus der erstellten Integration Connected App | | Client Secret | aus der erstellten Integration Connected App | | Benutzername | des Created Integration Benutzers | | Passwort + Security Token | des Created Integration Benutzers | | Token Endpoint URL | URL for authorization token | ## 2 Konfiguration in MOXS ### 2.1 Einrichtung eines Protokoll Hooks Zunächst muss der Administrator in MOXIS innerhalb des Prozesses den *Protokoll-Hook* hinzufügen. Öffnen Sie dazu die Prozessverwaltung unter dem Reiter *Administration* -\> „*Prozessverwaltung* " und wählen Sie den Prozess aus, in dem Sie den Salesforce Connector verwenden möchten. Klicken Sie auf den *Hooks-Tab* des Prozesses und fügen Sie einen neuen Block hinzu. Wählen Sie *Protokoll-Hook aktualisieren* und aktivieren Sie *Erfolgreich abgeschlossen* unter *Abschließende Ereignisse* (siehe*Abbildung 3).* ![image-20251124-153309.png](https://documentation.moxis.co/__attachments/a_f825a2fac4dbe93f20ae1d073c9d7316778edefcbad1201ad77bc59e0ae5bef3/image-20251124-153309.png?cb=4fbc03b8f35579f6826873ad33ba4c52) *Abbildung 3: Hook-Einstellungen in der MOXIS Prozess-Verwaltung definieren* ### 2.2 Job Status Hook setzen Anschließend konfigurieren Sie innerhalb des Prozesses den JobStatus-Hook. Wählen Sie dazu *Jobstatus-Hook senden* und aktivieren Sie unter *Abschlussereignisse* die Option *Erfolgreich beendet* (siehe*Abbildung 4*). Klicken Sie auf den Bearbeiten-Icon (den Stift), um den Hook mit den Daten aus den letzten Kapiteln zu konfigurieren. ![image-20251124-153734.png](https://documentation.moxis.co/__attachments/a_1d2f7423d1a2dbe2722c043cf729e925a45583bb7c400b06fdf720a1ce018dab/image-20251124-153734.png?cb=3a2838558fd9839a3a3f345ed2ee83eb) *Abbildung 4: Job Status Hook Einstellungen im MOXIS Prozess definieren* ![image-20251124-154639.png](https://documentation.moxis.co/__attachments/a_ea085374c3099617a8fa2f089134509fb8b4c24b3890dbe905d153e6e841413d/image-20251124-154639.png?cb=5d5aa79d212fd2835d1cbe84391cbd1c) *Abbildung 5: Job Status Hook editieren* Der *Authentifizierungsmodus* muss auf *OAUTH2* gesetzt sein. Der *Endpunkt* ist *Org URL* . Das *Passwort* ist die Kombination aus Passwort und Sicherheitstoken (ohne Leerzeichen zwischen beiden). Alle anderen Werte entsprechen der obigen Tabelle. Die Klassifikation des Benutzers, die Header-Parameter und Wiederholungsintervalle sind nicht erforderlich. **XiTipp** Sie können den „Job Status Hook" auch im Block mit dem „Protocol Hook" hinzufügen. Beachten Sie jedoch, dass dieser Hook nach dem Protocol Hook stehen muss. ### 2.3 So erhalten Benutzer Zugriff Gewähren Sie Zugriff auf die MOXIS Connector-Funktionalität, indem Sie die folgenden Berechtigungen (Rollen) in MOXIS zuweisen: **• MOXIS Admin:** für jeden administrativen Benutzer, der für die Verwaltung und Konfiguration des Connectors zuständig ist **• MOXIS User:** für jeden Benutzer, der den MOXIS Connector verwenden soll --- version: "v2" language: "de" --- # Konfiguration - Signieren mit MOXIS via Connector für Salesforce Um die MOXIS-Integration für ein Objekt in Salesforce nutzen zu können, müssen die folgenden Voraussetzungen erfüllt sein: • Eine Lightning-Aktion für MOXIS ist eingerichtet und der Seite hinzugefügt worden. • Eine gültige MOXIS-Prozessvorlage ist konfiguriert. Diese Anleitung informiert Sie über das weitere Vorgehen. *** ** * ** *** ## 1. Mit MOXIS Lightning-Aktion signieren Der MOXIS Connector bietet eine Lightning-Webkomponente, die einfach als benutzerdefinierte Aktion zu jedem Objekt hinzugefügt werden kann. Um sie hinzuzufügen, öffnen Sie die Einrichtungsseite des Objekts und erstellen Sie eine neue Aktion: * Aktionstyp = Lightning-Webkomponente * Lightning-Komponente = mox:moxisSignDoc * Bezeichnung = (z. B. Mit MOXIS unterschreiben) * Name = (z. B. Sign_with_MOXIS) Passen Sie die Seitenlayouts des Objekts oder die Lightning-Seitendefinitionen an, um sicherzustellen, dass die Aktion angezeigt wird (siehe *Abbildung 1*). ![image-20251125-103525.png](https://documentation.moxis.co/__attachments/a_15a115a3f529a6115187245f0d057e22836f3c59de67ebd0077e520d0dd249f4/image-20251125-103525.png?cb=0c31385b107d39c0b79b864e776139ff) *Abbildung 1: Eine Aktion für die MOXIS Signatur erstellen* ## 2. Konfigurieren einer MOXIS Vorlage Der MOXIS Connector stellt ein benutzerdefiniertes Objekt „MOXIS-Prozessvorlage" bereit, mit dem Vorlagenoptionen für die Integration mit MOXIS definiert werden können. Für das Objekt muss eine gültige Vorlage konfiguriert werden, damit die erstellte Lightning-Aktion verwendet werden kann. Wechseln Sie zur Registerkarte MOXIS-Prozessvorlage und erstellen Sie einen neuen Vorlagensatz. Weitere Informationen zum Definieren der Vorlage finden Sie im Abschnitt „Prozessvorlagenkonfiguration". ## 3. MOXIS Status refreshen Zusätzlich zur automatischen Statusaktualisierung ist es möglich, den Status eines mit dem MOXIS Connector gestarteten MOXIS-Prozesses manuell zu aktualisieren. Eine Lightning-Webkomponente, die diese Funktionalität bereitstellt und als Aktion zu jedem Objekt hinzugefügt werden kann, ist Teil des Pakets. Die Komponente ermöglicht es dem Benutzer, den MOXIS-Status bei Bedarf zu aktualisieren. Sie fügt auch das signierte Dokument und den Signaturbericht an, wenn der Signaturprozess erfolgreich abgeschlossen wurde. ### 3.1. MOXIS Status Lightning Aktion refreshen Der MOXIS Connector bietet eine Lightning-Komponente, die einfach als benutzerdefinierte Aktion zu jedem Objekt hinzugefügt werden kann. Gehen Sie zur Einrichtungsseite des Objekts und erstellen Sie eine neue Aktion: * Aktionstyp = Lightning-Webkomponente * Lightning-Komponente = mox:moxisStatusRefresh * Bezeichnung = (z. B. MOXIS-Status aktualisieren) * Name = (z. B. MOXIS_Status_Refresh) ## 4. Konfiguration der Vorlage im Prozess Eine Vorlage in einem MOXIS Prozess definiert, wie und wann ein Dokument mit den MOXIS-Komponenten signiert werden kann. Die Felder in der unten anstehenden Tabelle sind im Vorlagendatensatz verfügbar. | **Feld** | **Beschreibung** | |---------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | MOXIS Process Template Name | Geben Sie der Vorlage einen aussagekräftigen Namen. Dieser dient lediglich Ihrer eigenen Organisation der Vorlagen. | | Source Object-Name | Geben Sie den API-Namen des Objekts an, bei dem die Dokumentensignatur mit dieser Vorlage verwendet werden kann (z. B. Opportunity). | | Active | Überprüfen Sie, ob die Vorlage zur Verwendung verfügbar ist. | | Allowed Signature Categories | Wählen Sie aus, welche Signaturkategorien verfügbar sein sollen, wenn Sie diese Vorlage verwenden. | | Source Object - Check Field | Wenn die Vorlage nur verfügbar sein soll, wenn bestimmte Kriterien erfüllt sind, geben Sie hier den API-Namen des Feldes an, das überprüft werden soll. Das Prüffeld im Quellobjekt sollte den Namen der Vorlage enthalten/zurückgeben. Das Prüffeld kann eine Formel sein, die je nach Datensatzkriterien auch verschiedene Vorlagennamen zurückgeben kann. Hier ist ein Beispiel für eine Formel: IF(Amount\>10000; „Opportunity Large"; „Opportunity Small") Das Feld kann auch ein einfaches Textfeld sein, das mit Apex-Triggern, Prozessgeneratoren, Flows oder anderen verfügbaren Mechanismen ausgefüllt werden kann. | | Source Object - Status Field | Wenn der MOXIS-Signaturstatus in der Opportunity sichtbar sein soll, geben Sie den API-Namen des Feldes an, in das der Status geschrieben werden soll. Sie können eine Auswahlliste mit dem globalen Wertesatz „MOXIS-Prozessstatus" oder auch ein einfaches Textfeld verwenden. Der MOXIS Salesforce Connector aktualisiert das Feld, sobald eine Änderung registriert wurde. | | Source Object - Signed Date Field | Wenn das Datum, an dem das Dokument unterzeichnet wurde, auf der Opportunity sichtbar sein soll, geben Sie den API-Namen des Feldes an, in das das Datum geschrieben werden soll. Sie können ein Datums- oder ein Datums-/Zeitfeld verwenden. | | Save MOXIS Report on Source Record | Aktivieren Sie dieses Feld, wenn das signierte Dokument nach Abschluss des Vorgangs im Quelldatensatz gespeichert werden soll. | | Source Object - Signed Doc Name Field | Wenn Sie eine automatische Benennung für das signierte Dokument wünschen, geben Sie den API-Namen des Feldes an, das den Namen für die signierte Dokument-PDF enthält. Dies kann ein Textfeld oder ein Formelfeld (Text) sein. | | Source Object - Report Name Field | Wenn Sie eine automatische Benennung für das Signaturberichtsdokument bereitstellen möchten, geben Sie den API-Namen des Feldes an, das den Namen für das Bericht-PDF enthält. Dies kann ein Textfeld oder ein Formelfeld (Text) sein. | | MOXIS Process ID | Geben Sie den Namen des Prozesses ein, der zum Erstellen der MOXIS-Prozessinstanz verwendet werden soll. Wenn das Feld leer bleibt, wird der Prozess „moxisDefault" verwendet. | | Target MOXIS Username | Sollten die MOXIS-Prozesse für einen einzelnen dedizierten Benutzer anstelle des laufenden Benutzers erstellt werden, geben Sie hier den MOXIS-Benutzernamen des Zielbenutzers ein. | | Alow Starting Process | Aktivieren Sie dieses Feld, wenn der Benutzer den MOXIS-Prozess direkt aus Salesforce heraus starten darf. | | Quick-Start Process | Aktivieren Sie dieses Feld, wenn der Prozess ohne Benutzerinteraktion gestartet werden soll. Dies funktioniert nur, wenn: • 1 PDF an den Quelldatensatz angehängt ist (bei mehreren Dateien muss der Benutzer eine auswählen) • Das PDF MOXIS-Platzhalter für alle Unterzeichner enthält • Alle Unterzeichnerdaten konfiguriert sind | ### 4.1. Iterationen Es ist möglich, Iterationen für die Signatur auf der Vorlage vorzudefinieren. Verwenden Sie die zugehörige Liste MOXIS Prozessvorlagen-Entscheidungsebenen, die im Vorlagendatensatz verfügbar ist. Für jede Entscheidungsebene auf dem Template sollte die folgende Information vorhanden sein: | **Feld** | **Beschreibung** | |------------------|------------------------------------------------| | Iteration Number | Auftragsnummer der Iteration (beginnend mit 0) | | Category | Choose the signature category. | ### 4.2. Signierende einer Iteration Es ist möglich, vorab Signierende für eine Entscheidungsebene zu definieren. Verwenden Sie dazu die zugehörige Liste MOXIS-Prozessvorlage Signierende im Iterationsdatensatz, um diese zu definieren. Für jeden Signierenden können die folgenden Informationen angegeben werden. | **Feld** | **Beschreibung** | |--------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Type | Verwenden Sie „fixed", wenn immer dieselbe Person als Signierende verwendet wird. Verwenden Sie „Dynamisch", wenn der Signierende dynamisch in Abhängigkeit von Datensatzwerten definiert werden muss. | | Fixed Identitfier | Bei Typ=dynamisch ist die Definition des Speicherorts des Werts für die Kennung des Signierenden (E-Mail) anzugeben. Weitere Informationen finden Sie im Abschnitt Dynamische Werte. Beispiel: „Owner.Email". | | Fixed Name | Bei Typ=fixed den Namen der Person angeben (nur relevant für externe Signierende). Z. B. „Albert Einstein". | | Fixed Locale | Bei Typ=fixed geben Sie die Spracheinstellung für die Person an (nur relevant für externe Signierende). Verwenden Sie den 2-Buchstaben-ISO-Code für die Spracheinstellung (z. B. „en", „de", „fr"). | | Dynamic Identifier | Bei Typ=Dynamisch ist die Definition des Speicherorts des Werts für die Kennung des Signierenden (E-Mail) anzugeben. Weitere Informationen finden Sie im Abschnitt Dynamische Werte. Beispiel: „Owner.Email". | | Dynamic Name | Wenn Typ=Dynamisch, geben Sie die Definition des Speicherorts des Namens des Signierenden an. Weitere Informationen finden Sie im Abschnitt Dynamische Werte. Z. B. „Owner.Name" | | Dynamic Locale | Wenn Typ=Dynamisch, geben Sie die Definition des Speicherorts der Ländereinstellung des Unterzeichners an. Weitere Informationen finden Sie im Abschnitt Dynamische Werte . Z. B. „Owner.Locale__c" | | Role Name | Name der MOXIS Rolle, sofern nötig. | ### 4.3 Dynamische Werte Die dynamischen Werte können verwendet werden, um auf ein Feld im Quelldatensatz oder einem zugehörigen Datensatz zu verweisen. Um auf ein Feld im Quelldatensatz zu verweisen, verwenden Sie einfach den API-Namen des Feldes, z. B.: „E-Mail" oder „Signer_Email__c". Ein Feld in einem zugehörigen Datensatz wird unter Verwendung des API-Namens der Beziehung(en) referenziert, die mit einem Punkt verkettet sind, z. B. „Contact. E-Mail" oder „Related__r.Contact__r.Email". Ein Feld aus einem Datensatz, der auf den Quelldatensatz verweist, d. h. ein untergeordneter Datensatz des Quelldatensatzes, wird unter Verwendung des API-Namens der untergeordneten Beziehung gefolgt vom Namen des Feldes für den Wert referenziert, z. B „OpportunityContactRoles.Email". Wenn dies so definiert ist, wird der erste Datensatz in der zugehörigen Liste übernommen. Es ist möglich, die untergeordneten Datensätze zu filtern, wenn mehrere Datensätze in der Liste vorhanden sind. Dies wird erreicht, indem \[filter\] nach dem Namen der untergeordneten Beziehung hinzugefügt wird, wobei der Filter ein beliebiger gültiger SOQL WHERE-Filter ist. Hier sind einige Beispiele: • OpportunityContactRoles\[Role=‚Decision Maker'\].Name • My_Contacts__r\[Main_Contact__c=TRUE\].Name • My_Contacts__r\[Level__c\>3\].Name ## 5. Weitere Konfigurationsmöglichkeiten ### 5.1. Der Startprozess im Salesforce Flow Es ist möglich, einen MOXIS-Prozess aus einem Salesforce-Flow heraus zu starten, indem die Aktion „Start MOXIS Process" im Flow aufgerufen wird. Dies funktioniert ähnlich wie die Option „Quick-Start Process" in der MOXIS-Prozessvorlage und hat die gleichen Anforderungen (z. B. muss PDF im Datensatz bereitgestellt werden, Vorlage muss vorhanden sein usw.). Da diese Aktion einen externen Webservice aufruft, müssen Sie diese Aktion möglicherweise in einen „geplanten" Flow-Pfad verschieben. Die Parameter für die Aktion sind die folgenden. | **Parameter** | **Beschreibung** | |----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Record ID | Die ID des Datensatzes, für den der MOXIS-Prozess gestartet wird (z. B. die ID der Opportunity oder des Angebots). | | ContentVersion ID | (Optional) Die ID der ContentVersion der PDF-Datei, die im Prozess verwendet werden soll. | | Allow multiple files | (Optional) Dieser Wert wird ignoriert, wenn eine ContentVersion-ID definiert ist. Standardmäßig ist der Wert „false" und erfordert, dass genau 1 PDF-Datei gespeichert wird im Datensatz -- andernfalls wird ein Fehler ausgegeben. Wenn Sie den Vorgang auch dann zulassen möchten, wenn mehrere Dateien im Datensatz gespeichert sind, geben Sie den Wert „true" an. Dadurch wird die zuletzt geänderte Datei für die Aktion verwendet. Wenn keine Dateien im Datensatz vorhanden sind, wird unabhängig von diesem Parameter ein Fehler ausgegeben. | Die Aktion gibt einen einzelnen Textwert zurück, bei dem es sich um die MOXIS-Prozessinstanz-ID (nicht um eine Salesforce-ID) handelt. ### 5.2 Get Signer Information in Salesforce Flow Es ist möglich, grundlegende Informationen über den aktuell aktiven Signierenden für einen MOXIS-Prozess abzurufen, indem man die Flow-Aktion „Get Signer Info" verwendet. Als Eingabeparameter muss die MOXIS-Prozessinstanz-ID angegeben werden. Die Antwort der Aktion enthält die folgenden Informationen über den aktuellen Unterzeichner der Iterationen. | **Output Parameter** | **Beschreibung** | |----------------------|------------------------------------------------------------------------------------------------------------------------------| | Name | Die Kennung des Unterzeichners (in der Regel die E-Mail-Adresse). | | External Signer URL | Die URL für den direkten Zugriff auf die Unterschriftenseite für den Unterzeichner. Nur für externe Unterzeichner verfügbar. | --- version: "v2" language: "de" --- # MOXIS Connector für Salesforce (Admin Guide) --- version: "v2" language: "de" --- # Office to MOXIS: Installation **Content** The Office to MOXIS add-in can be used to increase the efficiency of your workflows. It allows you to **upload your documents** as **PDF files** directly and securely to **MOXIS via the multifunction bar** , where you can then process them further. A**Microsoft Office 365 subscription** is a **prerequisite**for this. *** ** * ** *** Office to MOXIS also works with the following file types: * Microsoft Word * Excel and * PowerPoint **XiTip** **Please note:** The plugin is only compatible with **.docx files**. 'Old' Word files do not work with Word files from Word 1997 - 2003. ## 1. Installation of Office to MOXIS There are two ways to install the add-in: * Complete the add-in basic installation * Download and install the add-in from the Microsoft Store **XiTip** **Please note:** Windows 11 is required for installation (applies to both integration options). Further requirements can be found here: [Office to MOXIS eSignature](https://appsource.microsoft.com/en-us/product/office/WA200004593?tab=DetailsAndSupport). Please contact your administrator if you are unsure which installation method is right for you. **XiTip** Another option for how you can provide Office for MOXIS in your organisation can be found [here](https://documentation.moxis.co/en/moxis-faq/latest/wie-stellen-sie-office-to-moxis-in-unternehmen-ber.md). ### 1.1. Instructions: Finish the basic installation of the add-in In most cases, the basic installation has already been carried out by your administrator. Now it is up to you to finish the installation. To finish the installation, first open a Word document (alternatively, Excel or PowerPoint are as well possible) and click on the **Home-** tab (see *figure 1 \[1\])* and**Add-ins** (see *figure 1 \[2\]*). ![01a_Start.png](https://documentation.moxis.co/__attachments/a_8a432f49cca3e02446efec380de0f215226e50217298ef4a490ffbd92f749d7f/01a_Start.png?cb=7a9a7d31d47b764b3e4068ab7182b70b) *Figure 1: Open Add-ins in MOXIS* The Office Add-ins pop-up will now open. Please click on the **\[+ More Add-ins\]** -Button (see *figure 2 \[1\]*). ![02a_Open_more_add_ins.png](https://documentation.moxis.co/__attachments/a_7bde758e8e69a286e96aa5933047633e09aee7ecbd74e6744d3012176acadbed/02a_Open_more_add_ins.png?cb=7d2e73004bf8007087469c85b0a370ef) *Figure 2: Click on the \[+More Add-ins\]-Button* Please select the option **Admin Managed** (see *figure 3 \[1\]* ) and click on the **Office To MOXIS** add-in (see *figure 3 \[2\]* ) and click on the **\[Add\]** -Button (see *figure 3 \[3\]*). ![03a_Admin_Managed_Plugins.png](https://documentation.moxis.co/__attachments/a_2fd81e1d599dbe5b2f3f5a39b193dcbe84594b0a8ae14d08606b7b1b4e19aca9/03a_Admin_Managed_Plugins.png?cb=4e935a1dcf24c26e7e9bd144c2596f66) *Figure 3: Add Office to MOXIS* **Office To MOXIS** is now available via the **MOXIS** tab in the menu bar of all Microsoft Office programs (see *figure 4*). ![02a_Office2MOXIS_verfügbar (1).png](https://documentation.moxis.co/__attachments/a_0567c3717f7b08840bc0c1012f0d9d33b1574af2eef16f18246f04d208a43494/02a_Office2MOXIS_verf%C3%BCgbar%20(1).png?cb=2688927ec6bf33c052ea285d349b335c) *Figure 4: Office To MOXIS available in Office 365* ### 1.2. Alternative option: Downloading and installing Office To MOXIS via the Microsoft Store With this option, you can download the add-in yourself for free from the [Microsoft Store](https://appsource.microsoft.com/en-us/). However, this is only possible if the application is not managed by the administrator. Search for the add-in in the [Microsoft Store](https://appsource.microsoft.com/en-us/) by entering MOXIS in the search bar (see*figure 5 \[1\]* ). Clicking on the search result tile (see*figure 5 \[2\]* ) opens the overview page with details of functionality and compatibility (see *figure 6* ). This information is only available in English. You can click on **Download now**directly in the search result or on the overview page. **XiTip** We recommend that you sign in to your [Microsoft 365 account](http://www.office.com/) before you start downloading. ![04a_MS_Store_Get_it_now.png](https://documentation.moxis.co/__attachments/a_9ae0c341874d93493a6f0054c4e7e72380c0feb2387456985e57ac8d834f4531/04a_MS_Store_Get_it_now.png?cb=e31d25ab491096a8d9d827e3d1c508d3) *Figure 5: Open Office to MOXIS in the Microsoft AppStore* ![04a_Suchergebnisse_Office_2_MOXIS (1).png](https://documentation.moxis.co/__attachments/a_a3494ff8427fc4598df3c4c74b76a80014b0e6507626e1d4cf013cffe7e39828/04a_Suchergebnisse_Office_2_MOXIS%20(1).png?cb=9f7f05b1814443fe49d806b55c8d3916) *Figure 6: Detail page in the Microsoft Store with information on Office 2 MOXIS* Please confirm in the pop-up that now opens by clicking again on the **\[Get it now\]** -button (see *figure 7*) to confirm your details and agree to the terms of use and the privacy policy. ![image-20250226-135509.png](https://documentation.moxis.co/__attachments/a_12742125bed3b4064a4e97130f8b5b40114a0f8202e7463189a3f44807aa583c/image-20250226-135509.png?cb=8e127927a11c8e81968785d15c9351b6) *Figure 7: Office To MOXIS - Confirming the details in the Microsoft Store* You will be redirected to a page from which the add-in can be started. There are two options: * Office (document opens in desktop app, see *Figure 8 \[1\]*) * Office Online (document opens in browser, *see Figure 8 \[2\]*) When you click **Open in Excel** ,**Open in Word** , **Open in PowerPoint** , **Open in Excel Online** ,**Open in Word Online** or **Open in PowerPoint Online** , the corresponding program opens either in the **desktop app** or in the **browser**. ![06a_Open_MOXIS (1).png](https://documentation.moxis.co/__attachments/a_02d888847c2b4ac0c650c39e4376444c0e1e59ed005334640c9f6f1d3c04c8a8/06a_Open_MOXIS%20(1).png?cb=6502b81222081d00f422af285ac4a847) *Figure 8: Opening Office To MOXIS* **A single** reference is made on the start page to the **MOXIS tab** and to all **available programmes** (see *figure 9*). ![07a_Launch_Add-in (1).png](https://documentation.moxis.co/__attachments/a_e0e6ed14bd6744066c2701b54f3ee7d14418c8d7509c7e560fe8bcfe40839a9b/07a_Launch_Add-in%20(1).png?cb=bf46a9575e1cf13dc2ded730c32a7d4c) *Figure 9: Start page with an overview of all available options* MOXIS is now available in the menu bar. --- version: "v2" language: "de" --- # Office to MOXIS Manual * [Office to MOXIS: Installation](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/office-to-moxis.md) * [Office to MOXIS: How to open \& first steps](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/office-to-moxis-offnen-und-erste-schritte.md) * [Office to MOXIS: Linking Office to MOXIS](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/verknupfung-von-office-to-moxis.md) --- version: "v2" language: "de" --- # Office to MOXIS: How to open & first steps **Content** After you have successfully completed the installation, it's time to try out Office To MOXIS and explore the functionalities. This article will help you get started. *** ** * ** *** ## 1. Open Office To MOXIS The MOXIS tab (see *figure 1* ) is displayed in the editing toolbar for all programs for which the Office To MOXIS add-in has been activated. Clicking on the tab displays the **\[Open Office To MOXIS\]** -button (see *figure 1*) . Clicking on this button opens the Office To MOXIS application. ![image-20250226-141102.png](https://documentation.moxis.co/__attachments/a_6d294580e2bfa60562605afa9ca46b13ff2282739fc4ea74f9748878681b5224/image-20250226-141102.png?cb=025829bc41475be0b152e05503c3adc7) *Figure 1: Open the MOXIS Add-In* The add-in includes instructions for use. These are available in German and English. The language can be changed using the language menu at the top right (see *Figure 2*). ![image-20250226-141257.png](https://documentation.moxis.co/__attachments/a_ab61af6e621449227d896e98418aa47aef601cfa2560d2ea6efa9bb1ed560201/image-20250226-141257.png?cb=ab51ea50b5cf4d1d9dbbd95a564a663e) *Figure 2: Office To MOXIS view* ## 2. Select a process in Office To MOXIS When you log in, you will be taken to an overview page where you can select the desired process for your document. After the selection, the document will open in the chosen process and can be further edited using all the available functions. ![12a_Office_To_MOXIS_Prozessauswahl (1).png](https://documentation.moxis.co/__attachments/a_7bf844a1bf1654c42ef1ba3dab121af43cb100c5dbae624b16321d2048bf99d5/12a_Office_To_MOXIS_Prozessauswahl%20(1).png?cb=08a4a090c54d6e703c8b488e28b522cd) *Figure 3: Select a process in Office To MOXIS* ## 3. Uploading files to Office To MOXIS Office To MOXIS offers a range of options, including the ability to upload Microsoft Word documents. If the document is new and has not yet been saved, you must first enter a file name and click on the **\[Upload\]** -button (see *figure 4*). **XiTip** If the Microsoft Word document that you want to upload to the linked instance has already been saved under a file name, this will be adopted. ![image-20250226-144044.png](https://documentation.moxis.co/__attachments/a_45cdca9efc95b39abce84d55571e0ff973a76d12b1edb0349354717d09bb235e/image-20250226-144044.png?cb=af159861e06776b4c50d62cc3b596f31) *Figure 4: Uploading a Word document to Office To MOXIS* If the operation was successful, a message will appear indicating the date and time of the last upload. If you wish to upload the document again, please click the**\[Upload again\]**-button. --- version: "v2" language: "de" --- # SharePoint to MOXIS * [SharePoint to MOXIS Handbuch](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/sharepoint-to-moxis-handbuch.md) --- version: "v2" language: "de" --- # SharePoint to MOXIS Handbuch Aufträge aus MOXIS können nach der Integration von SharePoint direkt aus SharePoint abgewickelt werden. Dieses Handbuch erklärt, welche Vorteile dies bietet und wie Sie am Besten vorgehen. *** ** * ** *** ## 1. Welche Vorteile bietet die SharePoint Integration? Die Integration eines Kollaborationstools wie SharePoint ist die logische Erweiterung einer ganzheitlichen Lösung für digitale Signaturprozesse wie MOXIS. Wurde SharePoint erfolgreich an MOXIS angebunden, so bietet es folgende Vorteile: * **Schnellere Durchlaufzeiten** * Die nahtlose Integration von SharePoint in die MOXIS Signaturmappe führt zu schnelleren Abwicklung von Aufträgen * **Anzeige des Status des Dokuments in SharePoint** * Dokumente und deren Status werden zwischen SharePoint und MOXIS synchronisiert, was einen schnellen Überblick ermöglicht * **Archivierung von Dokumenten in SharePoint möglich** * Da MOXIS kein Archivierungstool ist, eignet sich SharePoint, signierte Aufträge und Dokumente mit anderen Status zu verwalten. ## 2. Voraussetzungen für die Integration von SharePoint to MOXIS **XiTipp** Voraussetzung für die volle Funktionalität von SharePoint to MOXIS ist mindestens eine **MOXIS 4.52 Instanz**. Der Rest ist denkbar einfach, denn die Integration übernimmt XiTrust für Sie. Dennoch gibt es einige Punkte, die Sie vor der Integration bereits klären und unserem Support-Team zur Verfügung stellen können. So helfen Sie, die Zeit vor dem Setup zu verringern. **Dazu gehören:** * Name der **SharePoint Domain** mit der MOXIS verbunden werden soll. * Eine **Liste** der **Seiten**, auf welchen SharePoint to MOXIS aktiviert werden soll. * Die**Registrierung** der **App**in Microsoft Entra ist bereits erfolgt. * Weitere Informationen zum **MOXIS Webservice Benutzer**, die Sie bitte direkt mit Ihrem oder Ihrer XiTrust Ansprechpartner:in klären. ## 3. Sichere Integration und Erste Schritte ### 3.1. Die Integration von SharePoint to MOXIS Die Integration von SharePoint erfolgt über eine App Registrierung in Microsoft Entra. Die darauffolgende Kommunikation findet über die Microsoft Graph API (Schnittstelle) und den MOXIS Webservice statt. Das Integrieren von SharePoint dauert in etwa 60 Minuten und wird von XiTrust in der Kundeninstanz vorgenommen. Zudem werden die App in Microsoft Entra, der MOIXS Webservice und die SharePoint to MOXIS Berechtigungen konfiguriert. Darüber hinaus werden die zuvor angegebenen SharePoint Sites integriert (siehe *Abbildung 1*). ![image-20250604-065229.png](https://documentation.moxis.co/__attachments/a_cc0b624fea6e55360aa0c75846a67926f2e47f4ce22ca92fda844281cab99542/image-20250604-065229.png?cb=a2d7235c96db498ec35ea39da193b43f) *Abbildung 1: Verbindung MOXIS to SharePoint* ### 3.2. Erste Schritte in SharePoint to MOXIS Sobald die Integration erfolgt ist, kann SharePoint to MOXIS einfach und intuitiv genutzt werden. In den folgenden Kapitel lernen Sie mehr über die Handhabe von SharePoint to MOXIS. ### 3.3. Schritt-für-Schritt Anleitung für die Nutzung von SharePoint to MOXIS #### 3.3.1. Schritt 1: Laden Sie Dokumente zum Signieren hoch Laden Sie mindestens ein Dokument, das Sie mithilfe von SharePoint to MOXIS signieren möchten, auf SharePoint hoch. #### 3.3.2. Schritt 2: Erstellen Sie einen Entwurf in SharePoint Dazu markieren Sie bitte das Dokument, welches Sie zum Signieren freigeben wollen (siehe *Abbildung 2 \[1\]* ). Sodann machen Sie einen Rechtsklick. In dem so geöffneten Fenster klicken Sie bitte auf*Erstelle MOXIS Entwurf* (siehe*Abbildung 2 \[2\]*). ![02a_SharePoint_To_MOXIS_Entwurf_anlegen.png](https://documentation.moxis.co/__attachments/a_d9697eec42f82a5db2e88beb03cbe3c786464534474a48d8229887e9234df6cb/02a_SharePoint_To_MOXIS_Entwurf_anlegen.png?cb=312bd4dd9ae17198c0874b33dbbca793) *Abbildung 2: Erstellung eines MOXIS Entwurfs in SharePoint* #### 3.3.3. Schritt 3: Entwurf in MOXIS fertigstellen Editieren Sie den auf diese Weise kreierten Entwurf wie gewohnt in MOXIS und versenden Sie den Auftrag. Entwürfe und versendete Aufträge werden in SharePoint in der Spalte MOXISStatus entsprechend gekennzeichnet. Einen Entwurf können Sie jederzeit aus SharePoint heraus in MOXIS weiter bearbeiten, indem Sie auf den Button **\[MOXIS öffnen\]** klicken (siehe *Abbildung 3 \[1\]*). Der Status eines bereits versendeten Auftrags wird Ihnen ebenfalls in MOXIS angezeigt (siehe *Abbildung 3 \[2\]*). **XiTipp** Bitte beachten Sie: Die Aktualisierung der Auftragsstatus in SharePoint erfolgt automatisch. ![03a_SharePoint_Integration_Status.png](https://documentation.moxis.co/__attachments/a_86f1588dff3360f62aa0f7bac4441ba6d3fe5c58d66e68ae3d2b9bd3e3f089dd/03a_SharePoint_Integration_Status.png?cb=9dba9396bccb40996389ce4353047c6e) *Abbildung 3: Übersicht über die verschiedenen Aufträge in SharePoint* #### 3.3.4 Schritt 4: Überprüfen Sie den Status Ihrer versendeten Aufträge in SharePoint Es gibt verschiedene Status, die in SharePoint to MOXIS angezeigt werden (siehe *Abbildung 4 \[1\]*). Dazu gehören zum Beispiel: * **MOXIS öffnen**(Bearbeitung möglich) * **Entwurf verworfen**(Auftrag wurde nicht versendet) * **Abgelehnt**(Auftrag versendet, jedoch abgelehnt) * **Erfolgreich**(Auftrag erfolgreich signiert) Die Übersicht ermöglicht es Ihnen, auf einen Blick den Status Ihrer aktuellen Aufträge zu erhalten. ![03b_SharePoint_Integration_Status.png](https://documentation.moxis.co/__attachments/a_f5264c24ca52e1c4fd21756f0bdab3bad4e147feadcf740155a83803d5c60cc3/03b_SharePoint_Integration_Status.png?cb=38e5bb2ecc66b0a731fca0ff1092ca87) *Abbildung 4: Auftragsstatus in SharePoint to MOXIS* **XiTipp** Sollte ein Auftrag nicht korrekt erstellt werden, so wird Ihnen der Status **\[Fehler\]** angezeigt. Sofern der Fehler nicht mithilfe Ihres Administrators oder Ihrer Administratorin vor Ort behoben werden kann, wenden Sie sich bitte an den Support unter [servicedesk@xitrust.com](mailto:servicedesk@xitrust.com). --- version: "v2" language: "de" --- # Office to MOXIS: Linking Office to MOXIS You only need to link your MOXIS URL the first time you use the add-in or if your MOXIS URL changes. If you first link it in one programme (e.g. Word), the settings are automatically adopted for the other programmes. When entering the URL, make sure that you enter the short form of the link to your MOXIS instance. To get to this short form, log in to your account. Now look at the link that is displayed in the address bar on the dashboard. In the example (see *figure 1* ), the URL of the dashboard is https://testfirma6.moxis.cloud/ui/protected/#!dashboard. However, the part ui/protected/#!dashboard must be omitted when copying, otherwise the link will fail. The short form of the link that needs to be copied and pasted for the link in this case is thus for this MOXIS instance. ![13a_Verknüpfung_MOXIS_Cloud (1).png](https://documentation.moxis.co/__attachments/a_9248aa1ee36dce6e1d843a125ffc9a17a2160f82b920fc347872d539c6a13145/13a_Verkn%C3%BCpfung_MOXIS_Cloud%20(1).png?cb=90ed130dc89df4e16e6570efa70d522c) *Figure 1: Office To MOXIS Link* **XiTip** An**invalid URL** will result in an **error message** . Therefore, be sure to enter the shortened URL [**https://testfirma6.moxis.cloud**](https://testfirma6.moxis.cloud/), replacing 'Test Company' with your instance. As soon as you have entered a valid URL, the **\[Pair\]** -button will be activated. If necessary, a link can be easily removed by clicking the **\[Unpair\]** -button (see *figure 2*). ![image-20250226-142242.png](https://documentation.moxis.co/__attachments/a_bb00b8ad7b4995de8b78b74d6672b866e81c648520f63991ae2df6a6934ab7a9/image-20250226-142242.png?cb=33d214489f232595e17da14b50bcb3bd) *Figure 2: Pair with Office To MOXIS* --- version: "v2" language: "de" --- # XiTrust MOXIS Teams-Connector Handbuch **Inhalt** Das folgende Handbuch versorgt Sie mit Anleitungen zum MOXIS Teams-Connector von XiTrust. Der Teams-Connector von XiTrust erlaubt es Ihnen, Ihre Arbeitsabläufe effizient zu gestalten und MOXIS-Aufträge sicher und direkt über Teams zu erstellen und zu bedienen. *** ** * ** *** ## 1. Schritt-für-Schritt Anleitung: Ersteinstieg in den MOXIS Teams-Connector von XiTrust Der MOXIS Teams-Connector von XiTrust verbindet MOXIS mit Microsoft Teams. Sie haben so die Möglichkeit, Dokumente direkt aus Teams zur Unterschrift zu bringen und sie zu bearbeiten. **XiTipp** Für den reibungslosen Einsatz des MOXIS Teams-Connector von XiTrust müssen die folgenden Voraussetzungen gegeben sein: * Eine Microsoft Office 365 Anbindung ist vorhanden. * Ihre MOXIS Enterprise-Instanz ist auf Version 4.53. * Der Teams-Connector muss von einem oder einer Administrator:in dem Tenant hinzugefügt worden sein. **Schritt 1:** Um den MOXIS Teams-Connector zu nutzen, müssen Sie ihn zunächst installieren. Öffnen Sie dazu Microsoft Teams, klicken Sie auf App und suchen Sie in der Suchleiste nach *XiTrust MOXIS Teams-Connector* (siehe *Abbildung 1 \[1\]* ). Klicken Sie nun auf den **\[Hinzufügen\]** -Button der *XiTrust MOXIS Teams-Connector-* Kachel in den Suchergebnissen (siehe *Abbildung 1 \[2\]*). ![03a_Teamsbot_hinzufügen.png](https://documentation.moxis.co/__attachments/a_a6fbaeef48821497ff2490f6aa8d3e902f23f29c8f09617fb97e8b853e1bf968/03a_Teamsbot_hinzuf%C3%BCgen.png?cb=a3153c28e92e17066c567721f45de4aa) *Abbildung 1: MOXIS Teams-Connector suchen und installieren* **Schritt 2:** Nun öffnet sich die MOXIS Teams-Connector Kachel. Hier finden Sie die Beschreibung von MOXIS, eine Übersicht über die App-Features und die Berechtigungen. Klicken Sie auf den **\[Hinzufügen\]** -Button (siehe *Abbildung 2 \[1\]*), um die App final in Ihrem Teams-Account zu installieren. ![02a_Teamsbot_hinzufügen.png](https://documentation.moxis.co/__attachments/a_63bf1615d38f15fbe879350cfc92ea1d54d5a7c8bc2880caf5d5c31f6f589eb7/02a_Teamsbot_hinzuf%C3%BCgen.png?cb=40247dc1e0a4093498f0e44eac73053a) *Abbildung 2: MOXIS Teams-Connector in Teams hinzufügen* **Schritt 3:** Wurde die App erfolgreich hinzugefügt, erhalten Sie eine entsprechende Meldung (siehe *Abbildung 3* ). Sie können die App nun mit einem Klick auf den **\[Öffnen\]** -Button (siehe *Abbildung 3 \[1\]*) sofort öffnen. ![01a_Apps_hinzufügen.png](https://documentation.moxis.co/__attachments/a_579775f2162389d98ed3a4b6e3f3258377b7f0f9bac36171af0db914a417255e/01a_Apps_hinzuf%C3%BCgen.png?cb=b57bc8c7a488e2d99e0145fe3b7de06e) *Abbildung 3: MOXIS Teams-Connector wurde erfolgreich hinzugefügt* **Schritt 4:** In der Chat-Übersicht wird nun neben den Benutzer:innen, mit denen Sie bereits in Kontakt stehen, der *MOXIS Teams-Connector (* siehe *Abbildung 4 \[1\])* angezeigt. Wenn Sie den Chat öffnen, empfängt Sie der *MOXIS Teams-Connector* bereits mit einer ersten Nachricht an Sie. ![04a_Teamsbot_hinzufügen.png](https://documentation.moxis.co/__attachments/a_76f64436ee27b09f2d4671f0304a9873833a75b614587aa4167eea7e5cab6f38/04a_Teamsbot_hinzuf%C3%BCgen.png?cb=e15961b3916a1dfe1c12b564751cc524) *Abbildung 4: MOXIS Teams Connector Start* ## 2. MOXIS Teams-Connector von XiTrust: Die Basics In diesem Kapitel erfahren Sie am Beispiel von Usecases, wie Sie mithilfe des *MOXIS Teams-Connector* die Ausführung Ihrer Aufträge streamlinen. Das folgende Video führt Sie in die Basics ein. In den weiteren Kapiteln finden Sie Details zum Teams Connector. ### 2.1. MOXIS Teams-Connector: Die Oberfläche Nach der Installation des MOXIS Teams Connectors erhält man Zugriff auf dessen Oberfläche. Von hier aus hat man verschiedene Möglichkeiten, den Connector zu bedienen (siehe *Abbildung 5*). ![00_a_Teamsbot_Oberfläche_bearb.png](https://documentation.moxis.co/__attachments/a_bfac027cf3df89f15a34133e98255e8fa0eea9081a4bc04f40448d4fd1fb17fe/00_a_Teamsbot_Oberfl%C3%A4che_bearb.png?cb=0e0225237ffd521e51f8f69d66f04c3e) *Abbildung 5: Bedienmöglichkeiten MOXIS Teams-Connector* **Hier die wichtigsten im Detail:** **(1) Nachricht eingeben** (siehe *Abbildung 5 \[1\]* ): Das Feld dient wie beim Teams-Chat gewohnt der Eingabe von Nachrichten. Nur, dass Sie sie in diesem Fall nicht an einen Menschen senden, sondern in Form von Prompts und Eingabebefehlen an unseren Connector, der diese dann umsetzt. Die Umsetzung erfolgt dabei intuitiv und wird in den nächsten Kapiteln genauer erklärt. **(2) Prompts anzeigen** (siehe *Abbildung 5 \[2\]*): Hier können Sie sich Vorschläge für Prompts anzeigen lassen. Diese können Sie bei Bedarf im Eingabefeld bearbeiten. **(3) Dateien hinzufügen** über das +-Icon (siehe *Abbildung 5 \[3\]*) Um eine Datei hinzuzufügen, klicken Sie hier bitte einfach auf das +-Icon. Alternativ können Sie das Dokument auch einfach via Drag and Drop im Texteingabefeld ablegen. Nun öffnet sich eine Übersicht. Hier können Sie mit einem Klick auf *Datei anfügen* ein Dokument hinzufügen (siehe *Abbildung 6*) und danach hochladen. ![02a_Datei_anfügen.png](https://documentation.moxis.co/__attachments/a_d2659ae6c11c244d0c4ddc71b53efa61d8fd61740a502f251ade327381a58640/02a_Datei_anf%C3%BCgen.png?cb=e0f06abbafd6280b974ffc3df863bcb5) *Abbildung 6: Datei anfügen im MOXIS Teams-Connector* **(4) Dateien hochladen und Nachrichten absenden** (siehe *Abbildung 5 \[4\]*) Damit Sie über den MOXIS Teams-Connector von XiTrust Aufträge oder Entwürfe kreieren können, müssen Sie Dokumente hochladen. Dies gelingt, indem Sie auf das Icon in Form eines Pfeils klicken (siehe *Abbildung 6*). Dasselbe gilt für Nachrichten, die Sie absenden wollen. Auch dieses Verhalten müssen Sie mit einem Klick auf den Pfeil auslösen. ![01a_Dateien hochladen.png](https://documentation.moxis.co/__attachments/a_ae64fb82a3c74117603c525ef79d7fb531abe63067f1cbbcf4b7e231f679cb49/01a_Dateien%20hochladen.png?cb=01e7d509125d84bc52f94331c30cc917) *Abbildung 6: Datei hochladen* ## 2. MOXIS Teams-Connector von XiTrust: Die Anwendung In diesem Abschnitt erfahren Sie, welche Möglichkeiten Sie haben, einen Auftrag oder einen Entwurf via dem MOXIS Teams-Connector anzulegen. Grundsätzlich haben Sie dazu zwei Optionen: * Durch das Hochladen des Dokuments * Mithilfe gezielter Prompts **XiTipp** **Bitte beachten Sie:** Um den MOXIS Teams-Connector im vollen Ausmaß nutzen zu können, müssen Sie über einen Account in MOXIS verfügen und sicherstellen, dass alle internen Benutzer:innen, die Sie einladen möchten, ebenfalls einen solchen haben. ### 2.1 Schritt-für-Schritt Anleitung: Dokument hochladen und weiterbearbeiten Das Hochladen eines Dokuments erfolgt intuitiv und ist an die regulären Schritte angepasst, die normalerweise in Teams dafür angedacht sind. **Schritt 1:** Fügen Sie wie im [letzten Kapitel](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/xitrust-moxis-teams-connector-handbuch.md#2.1.-MOXIS-Teams-Connector:-Die-Oberfl%25C3%25A4che) beschrieben ein Dokument, das Sie signieren oder in einem Entwurf verwenden möchten hinzu und laden Sie es hoch. **Schritt 2:** Der MOXIS Teams-Connector bietet Ihnen nun drei Möglichkeiten, das Dokument weiter zu bearbeiten (siehe *Abbildung 7 \[1\]*): * Entwurf anlegen * Self-Sign starten * Weitere Personen einladen Wie Sie mit den verschiedenen Optionen fortfahren, erfahren Sie in den Usecases in den nächsten Kapiteln. ![03a_MOXIS_Upload_drei_Möglichkeiten.png](https://documentation.moxis.co/__attachments/a_8a20f3c1f09962037313a7d359732bb85ef74e548f1fa8c168739fbd275f1752/03a_MOXIS_Upload_drei_M%C3%B6glichkeiten.png?cb=3a8b55dd0743e3ae24d54ad1b4f39b98) *Abbildung 7: Bearbeitungsmöglichkeiten eines hochgeladenen Dokuments im MOXIS Teams-Connector* #### 2.1.1 Usecase 1: Anlegen eines Entwurfs **Schritt 1:** Nach dem Hochladen eines Dokuments klicken Sie bitte auf die Option Entwurf anlegen (siehe *Abbildung 8*) in der MOXIS Teams-Connector-Kachel. ![04a_Entwurf_anlegen.png](https://documentation.moxis.co/__attachments/a_66eaeb76af2b8b486b911ad123c5655b030dbddf76a3931bf6128e786f45e2b5/04a_Entwurf_anlegen.png?cb=4db540ae1454fa47a369ab999c0b94d2) *Abbildung 8: Entwurf anlegen* **Schritt 2:** Danach öffnet sich eine weitere Kachel. Hier wählen Sie bitte einen Prozess über das Drop-Down-Menü und klicken auf den **\[Fortfahren\]** -Button (siehe *Abbildung 9*). ![01_Prozess_auswählen.png](https://documentation.moxis.co/__attachments/a_e924c52d636498cd3f06f4fb6b3d65b6400acc712ab8d973ff8fa49e440f6b49/01_Prozess_ausw%C3%A4hlen.png?cb=3f9651a1f7cf9ed55600dfd0b3fc688e) *Abbildung 9: Prozess auswählen und fortfahren* **Schritt 3:** Der MOXIS Teams-Connector verbindet sich nun automatisch mit der MOXIS-Instanz für die er konfiguriert wurde und Sie können den Entwurf hier mit entsprechenden Informationen anreichern und aktualisieren (siehe *Abbildung 10*). **Folgende Optionen stehen Ihnen in diesem Fall in MOXIS zur Verfügung:** * Fügen Sie einen oder mehrere [Empfänger:innen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.52/v4-52-arten-von-empfanger-innen.md) hinzu (siehe *Abbildung 10 \[1\]*) * Legen Sie eine oder mehrere [Entscheidungsebenen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.52/v4-52-entscheidungsebenen-definieren.md) an (siehe *Abbildung 10 \[2\]*) * Im Feld Auftragsbeschreibung können Sie eine entsprechende Beschreibung des Auftrags hinzufügen (siehe *Abbildung 10 \[3\]*). * Mittels einer selbstgewählten Referenz ID kann in bestimmten Fällen nach dem Auftrag gesucht werden (siehe *Abbildung 10 \[4\]*) * Das [Ablaufdatum](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.50/v4-50-auftrage-anlegen.md) kann je nach Konfiguration geändert werden (siehe *Abbildung 10 \[5\]*). * Wählen Sie einen [Platzhalter](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.52/4-52-einfuhrung-platzhaltergenerator-optional.md)für die Signatur oder fügen Sie [Formularfelder](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.52/v4-52-formularfelder.md)hinzu (siehe *Abbildung 10 \[6\]*. * Sobald Sie alle Informationen hinzugefügt haben, können Sie den Entwurf speichern, indem Sie auf den **\[Entwurf aktualisieren\]** -Button (siehe *Abbildung 10 \[7\]* ) klicken oder den Auftrag sofort senden, indem Sie den entsprechenden Button nutzen (siehe *Abbildung 10 \[8\]*). **XiTipp** **Bitte beachten Sie:** Die hier aufgeführten Optionen können je nach Konfiguration variieren. In diesem Beispiel wurde Wert darauf gelegt, so viele Optionen als möglich einfließen zu lassen, damit Sie einen guten Überblick erhalten. Sollte Ihnen eine Möglichkeit fehlen, die Sie jedoch gerne in Ihrer Instanz nutzen möchten, wenden Sie sich an Ihre:n zuständige:n XiTrust Ansprechpartner:in. ![03a_Abbild_in_MOXIS.png](https://documentation.moxis.co/__attachments/a_bb0eb8f9e4095ee3b58f9483d5500747ae26c8f94d109afc241408ca83d5cbe9/03a_Abbild_in_MOXIS.png?cb=6ff0c3975efddcd5f445b464c98f4c60) *Abbildung 10: Entwurf aktualisieren in MOXIS* #### 2.1.2 Usecase 2: Einen Auftrag selbst signieren **Schritt 1:** Nach dem Hochladen eines Dokuments klicken Sie bitte auf die Option Self-Sign starten (siehe *Abbildung 11*) in der MOXIS Teams-Connector-Kachel. ![04b_Self-Sign starten.png](https://documentation.moxis.co/__attachments/a_efdc2e68f4ad5270fe04956de461e32f9eb7df86b7a76d20bfc7fbba5c51d67c/04b_Self-Sign%20starten.png?cb=e3200f4c30c0fa3b0fb02935cffe57cc) *Abbildung 11: Self-Sign starten* **Schritt 2:** Danach öffnet sich eine weitere Kachel. Hier wählen Sie bitte wie gehabt einen Prozess und eine Signaturqualität aus und klicken auf den **\[Jetzt signieren\]** -Button (siehe *Abbildung 12* ). Mit einem Klick auf den **\[Abbrechen\]**-Button brechen Sie die Aktion ab. ![02_Signaturqualität_auswählen.png](https://documentation.moxis.co/__attachments/a_802fe7a2428be4b277bb44cd74780fac0cb59ea578c463a0637005c4087fef8c/02_Signaturqualit%C3%A4t_ausw%C3%A4hlen.png?cb=1b56131733eafee81c1f5b9b054efca9) *Abbildung 12: Prozess und Signaturqualität wählen* **Schritt 3:** Der MOXIS Teams-Connector verbindet sich nun automatisch mit der MOXIS-Instanz für die er konfiguriert wurde und Sie können den Auftrag direkt mit einem Klick auf den entsprechenden Button signieren (siehe *Abbildung 13 \[2\]* ) oder ablehnen (siehe *Abbildung 13 \[1\]*). ![03a_MOXIS_Ansicht.png](https://documentation.moxis.co/__attachments/a_398c3c2910eef350b0b70a93e8be138dfad59e4c100c1d0d51bf7f89a97812d4/03a_MOXIS_Ansicht.png?cb=8c61d69794d2486d6a4188bc7fc4858f) *Abbildung 13: Auftrag signieren* #### 2.1.3 Usecase 3: Weitere Personen einladen **Schritt 1:** Nach dem Hochladen eines Dokuments klicken Sie bitte auf die Option Weitere Personen einladen (siehe *Abbildung 14*) in der MOXIS Teams-Connector-Kachel. ![04c_Weitere_Personen_einladen.png](https://documentation.moxis.co/__attachments/a_322c67c038667994f1db31cb3dedf3366320ebecb050007d744bd47d68c4900b/04c_Weitere_Personen_einladen.png?cb=0db5ffd8d633ff38a69b71795776c303) *Abbildung 14: Weitere Personen einladen* **Schritt 2:** Danach öffnet sich eine weitere Kachel. Hier wählen Sie bitte zunächst wie gehabt einen Prozess aus und klicken auf den **\[Fortfahren\]** -Button (siehe *Abbildung 15*). ![01_Weitere_Personen_einladen.png](https://documentation.moxis.co/__attachments/a_24a20fb0ab24f2e51ef297a25e71b721db232418d29a18c2f016acbe8010afe9/01_Weitere_Personen_einladen.png?cb=3f10d43756c56d443418dd54a53c1db3) *Abbildung 15: Prozess auswählen und fortfahren* **Schritt 3:** Nun fügen Sie bitte eine interne **oder** externe [Entscheidungsebene](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.52/v4-52-entscheidungsebenen-definieren.md)hinzu (siehe *Abbildung 16*). ![02_Interne_externe_Entscheidungsebene_hinzufügen.png](https://documentation.moxis.co/__attachments/a_50cdc06c0f72d33c69e43b3cf805848adfbab9a2de24d4058d53ee5feeef7b9d/02_Interne_externe_Entscheidungsebene_hinzuf%C3%BCgen.png?cb=9752614868f067470dbf2ead27096f73) *Abbildung 16: Interne oder externe Entscheidungsebene hinzufügen* **XiTipp** Sollten Sie den Vorgang abbrechen wollen, können Sie dies tun, indem Sie auf die drei Punkt klicken (siehe *Abbildung 17*). ![03_Abbrechen.png](https://documentation.moxis.co/__attachments/a_d38d2e5caeb6523d67ad46661a7948939ba50576759b0b12ad044dfbdafbbcca/03_Abbrechen.png?cb=d8832170c7332d0128dad436d6eece94) *Abbildung 17: Vorgang abbrechen* **Schritt 4:** Fügen Sie nun die [Signaturqualität](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.52/v4-52-signaturqualitaten-bestimmen.md)und die zusätzlichen Signierenden hinzu. Sofern Sie mit Ihren Eingaben zufrieden sind, können Sie nun den Auftrag mit einem Klick auf den **\[Signatur starten\]**-Button abschließen. ![04_Signaturebene_hinzufügen.png](https://documentation.moxis.co/__attachments/a_7a3f42fcde78abb6edaeda409a91f7addb33d9030155cfb4dcea0a63e871a610/04_Signaturebene_hinzuf%C3%BCgen.png?cb=b3059ca1cae34fb4956921136427879b) *Abbildung 18: Signaturqualität und weitere Signierende hinzufügen* Sie haben jedoch noch weitere Möglichkeiten. Sie können den Auftrag mit einem Klick auf den entsprechenden Button entweder als Entwurf in MOXIS bearbeiten oder mit einem Klick auf die drei Punkte aus folgenden Möglichkeiten wählen (siehe *Abbildung 19*): * Weitere [Entscheidungsebene](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.52/v4-52-entscheidungsebenen-definieren.md)hinzufügen ([extern](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.52/v4-52-arten-von-empfanger-innen.md)) * Weitere Entscheidungsebene hinzufügen ([intern](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.52/v4-52-arten-von-empfanger-innen.md)) * Abbrechen ![05_Weitere_Bearbeitungsmöglichkeiten.png](https://documentation.moxis.co/__attachments/a_c5d11d5e54f1e7ee8953a761a8ab2d1738d1c9a7b1a13386ec0c5cf3cd4c7d26/05_Weitere_Bearbeitungsm%C3%B6glichkeiten.png?cb=ea96bbd7e63bd6d5f76c835e75862fca) *Abbildung 19: Weitere Bearbeitungsoptionen* **Schritt 5:** Sobald Sie auf den **\[Signatur starten\]**-Button klicken, wird der Auftrag an MOXIS übertragen und Sie können ihn dort wie gewohnt abschließen. **XiTipp** Nach finaler Signatur wird das signierte Dokument in Teams abgelegt und ist ab nun hier abrufbar. Je nach voreingestellter Prozesskonfiguration in MOXIS können Optionen wie Signaturqualität, das Erstellen von Entwürfen und das Hinzufügen von internen/externen Iterationen und Empfänger:innen variieren. ### 2.2 Arbeiten mit Prompts im MOXIS Teams-Connector Eine weitere Möglichkeit, Dokumente im MOXIS Teams-Connector zu bearbeiten, bietet die Anwendung von sogenannten Prompts. Diese sind im Grunde kurze Befehle, die den Connector dazu auffordern, gewisse Vorgänge anzustoßen. Dieser Abschnitt bringt Ihnen die Arbeit mit Prompts näher. #### 2.2.1 Wo finden Sie die MOXIS Teams-Connector Pompts? Eine Übersicht über die verfügbaren Prompts erhalten Sie in der Einstiegsmaske des MOXIS Teams-Connectors (siehe *Abbildung 5 \[2\]* ). Im Moment (Stand 04/2025) sind drei verschiedene Prompts verfügbar (siehe *Abbildung 20*): * config * start * sign ![01a_Promptvorschläge.png](https://documentation.moxis.co/__attachments/a_6e70af2b0e54ca31cbc029d8ea578c894d8970594c0ffcfedbd568a097b344ef/01a_Promptvorschl%C3%A4ge.png?cb=d4cb42e8b012a80fd7213c58a519f677) *Abbildung 20: Promptvorschläge* #### 2.2.2 Wie starten Sie einen Prompt? Um einen Prompt zu starten, geben Sie ihn in die Eingabeleiste ein (wie in *Abbildung 21 \[1\]* am Beispiel "config" ersichtlich) und drücken auf den Pfeil (siehe*Abbildung 21 \[2\]*). Alternativ können Sie auf die Prompts via Klick auf "Prompts anzeigen" zugreifen und einfach auf den Prompt klicken, den Sie nutzen möchten. ![01a_a_Prompt_starten.png](https://documentation.moxis.co/__attachments/a_df7422762f4b4861fa44b163c15991b053fc46ca55cecd998c4314b4eb6bd4a7/01a_a_Prompt_starten.png?cb=70a0f9adb4ad043112812f1dadc313fb) *Abbildung 21: Prompt starten im Teams-Connector* #### 2.2.3 Was bewirken die einzelnen Prompts? **Prompt 1: Config** Der Config-Prompt ermöglicht es Ihnen, den MOXIS Teams-Connector mit Ihrer MOXIS-Instanz zu verbinden. Geben Sie dazu einfach die entsprechenden Daten ein. Außerdem können Sie in diesem Schritt einen Standardprozess festlegen. Mit einem Klick auf den **\[Speichern\]**-Button speichern Sie Ihre Eingaben. **XiTipp** **Bitte beachten Sie:** Diese Funktion steht nur Benutzer:innen mit der Rolle *Application Administrator* zur Verfügung. Sollten Sie sich bei der Eingabe unsicher sein, wenden Sie sich bitte an den [XiTrust Servicedesk](https://xitrust.atlassian.net/servicedesk/customer/portals). ![02_Config.png](https://documentation.moxis.co/__attachments/a_4a082265bc2d70710c7684ab06845ce0105940c79442d1f605fedf6d72224bda/02_Config.png?cb=a84da563c834d941101e6f99deadb3ec) **Prompt 2: Start** Der Start-Prompt zeigt Ihnen erneut die Welcome-Card. Sie können nun mittels Klick auf den **\[Start\]**-Button überprüfen, ob Ihr Benutzer in MOXIS existiert. ![03_Start.png](https://documentation.moxis.co/__attachments/a_9ecbc7db5cae72327d1b30ca1d45498ee1a370e0a4a74e97b1f1ea53c79e2811/03_Start.png?cb=c2d2132a2a285ff4e8287d881cf2bc47) **Prompt 3: Sign** Der Sign-Prompt startet einen Workflow zum Signieren eines Dokuments. Um fortzufahren, laden Sie bitte wie in dieser Anleitung beschrieben ein Dokument hoch. ![04_Sign.png](https://documentation.moxis.co/__attachments/a_da14d8419bec760cfc6e7805b33406b500257f877c3c98dc6774623ffdc9a422/04_Sign.png?cb=3fcfce89b9f70cdf5e0efc2bca62ef27) **XiTipp** Nach finaler Signatur wird das signierte Dokument in Teams abgelegt und ist ab nun hier abrufbar. Je nach voreingestellter Prozesskonfiguration in MOXIS können Optionen wie Signaturqualität, das Erstellen von Entwürfen und das Hinzufügen von internen/externen Iterationen und Empfänger:innen variieren. --- version: "v2" language: "de" --- # XiTrust MOXIS Teams-Connector Plugin Handbuch * [XiTrust MOXIS Teams-Connector Handbuch](https://documentation.moxis.co/de/moxis-plugins-bersicht/latest/xitrust-moxis-teams-connector-handbuch.md) --- version: "v1" language: "de" --- # Support & Consulting ## Support \& Consulting ### Documentation * #### [Details zu Support \& Consulting](https://documentation.moxis.co/de/support-consulting/latest/service-consulting-details.md) * #### [Gestalten Sie die Zukunft von MOXIS mit. Ihr Feedback zählt!](https://documentation.moxis.co/de/support-consulting/latest/public-roadmap.md) --- version: "v1" language: "de" --- # Gestalten Sie die Zukunft von MOXIS mit. Ihr Feedback zählt! **MOXIS Tipp** **Gestalten Sie die Zukunft von MOXIS mit - ganz nach Ihren Bedürfnissen!** Sie möchten wissen, welche Neuerungen wir für MOXIS planen oder haben eigene Ideen, wie MOXIS Ihren Alltag noch einfacher machen kann? Dann sind Sie hier genau richtig: Auf dieser Seite erfahren Sie, wie Sie in einem **persönlichen Gespräch** Ihre Anforderungen direkt mit unserem Produktmanagement oder unserem Customer Success Team besprechen können. ## Ihr Feedback zählt -- MOXIS nach Ihren Anforderungen Ihr Feedback hilft uns dabei, * bestehende Funktionen zu verfeinern, * Prioritäten besser an Ihrem Bedarf auszurichten und * neue Features so zu entwickeln, dass sie in der Praxis echten Mehrwert bringen. Ob Verbesserungsvorschlag, Funktionswunsch oder eine konkrete Herausforderung aus Ihrem Alltag -- wir freuen uns über jeden Input. **MOXIS Tipp** Je besser wir Ihre Anforderungen kennen, desto passgenauer können wir MOXIS gestalten. Folgende Möglichkeiten stehen Ihnen dafür als MOXIS Kund:in zur Verfügung. ### **Für MOXIS Business Cloud Kund:innen:** **Q\&A-Sessions und individuelle Beratung mit maßgeschneiderter Unterstützung in der Gruppe** Unser Customer Success Team bietet für **MOXIS** **Business Cloud Kund:innen** wöchentliche**Q\&A-Sessions**an. Unsere **Q\&A-Sessions** finden jeweils am **Donnerstag** zwischen **11:00 und 12:00** Uhr statt (ausgenommen Feiertags). Wir bitten um Anmeldung bis eine Stunde vor Termin via E-Mail an [++**academy@xitrust.com**++](mailto:academy@xitrust.com). ### **Für MOXIS Enterprise Kund:innen:** **Reservieren Sie Ihren individuellen Coffee-Break Termin mit uns** Sie möchten Ihre Anforderungen lieber persönlich besprechen? Buchen Sie ganz einfach einen individuellen **Coffee-Break** mit unserem **Produktmanagement** hier: [**Coffee Break**](https://calendly.com/xitrust/coffe-break?month=2026-07) **In diesem 1:1-Gespräch können wir gemeinsam:** * **Ihre Ideen und Anforderungen im Detail durchgehen** Wir nehmen uns Zeit, Ihre Use Cases, Prozesse und speziellen Anforderungen zu verstehen. * **Fragen zu aktuellen oder geplanten Funktionen klären** Sie erhalten Einblicke, wie bestehende oder kommende Features zu Ihren Szenarien passen. * **Neue Lösungsansätze und Weiterentwicklungen diskutieren** Gemeinsam prüfen wir, wie MOXIS Sie künftig noch besser unterstützen kann. **Ihr Nutzen:** Sie erhalten direkten Zugang zu unserem Produktteam, können Ihre Themen priorisiert platzieren und aktiv Einfluss auf die Weiterentwicklung von MOXIS nehmen. Als **Enterprise-Kund:in** steht Ihnen natürlich auch wie gewohnt **Ihre persönliche Ansprechperson** für die Vereinbarung eines individuellen Termins zur Verfügung. --- version: "v1" language: "de" --- # Details zu Support & Consulting **MOXIS Tipp** Falls Sie Fragen zu MOXIS, Ideen für neue Funktionen oder Unterstützung bei der Umsetzung Ihrer Digitalisierungsstrategien benötigen, steht Ihnen unser kompetentes Support-Team zur Verfügung. Wir möchten sicherstellen, dass Ihre Anliegen schnell und effizient bearbeitet werden. ## Wie Sie uns erreichen 1. **Service Desk** : Besuchen Sie unsere Support-Plattform unter [https://servicedesk.xitrust.com](https://servicedesk.xitrust.com/). Hier können Sie bequem Anfragen erstellen, den Status Ihrer Anfragen verfolgen und auf hilfreiche Dokumentationen zugreifen. 2. **E-Mail** : Alternativ können Sie unser Team auch per E-Mail kontaktieren: [servicedesk@xitrust.com](mailto:servicedesk@xitrust.com). Bitte geben Sie in Ihrer Nachricht so viele Informationen wie möglich an (z. B. Ihr Anliegen, betroffene Funktion, relevante Dokumente oder Screenshots). Dies hilft uns, Ihre Anfrage schneller zu bearbeiten. ## Was wir für Sie tun können Unser Support-Team setzt sich aus erfahrenen **MOXIS- und Digitalisierungsexperten** zusammen. Wir stehen Ihnen zur Seite bei: * **Technischen Fragen**: Unterstützung bei der Nutzung von MOXIS und Hilfe bei spezifischen Funktionen. * **Individuellen Anfragen**: Lösung von Problemen, die speziell auf Ihre Bedürfnisse zugeschnitten sind. * **Beratung und Ideen**: Gerne besprechen wir mit Ihnen neue Ansätze, innovative Use Cases oder mögliche Erweiterungen rund um MOXIS. * **Digitalisierungsprojekte**: Beratung zur optimalen Umsetzung Ihrer Digitalisierungsvorhaben und Integration in bestehende Systeme. ## Tipps für eine schnelle Bearbeitung **MOXIS Tipp** Damit wir die Bearbeitungszeit auf ein Minimum reduzieren, unterstützen Sie uns, indem Sie sich an die folgenden Tipps und Tricks halten. * **Genaue Beschreibung**: Schildern Sie Ihr Anliegen so präzise wie möglich, einschließlich relevanter Details und gegebenenfalls der Schritte, die zum Problem geführt haben. * **Priorität angeben**: Falls es sich um eine dringende Angelegenheit handelt, teilen Sie uns dies bitte mit. * **Screenshots und Dateien**: Fügen Sie bei Bedarf Dateien oder Screenshots bei, um Ihr Anliegen zu verdeutlichen. * **Informationen zu Ihnen**: Teilen Sie uns auch mit, welche MOXIS Instanz (URL), welches Produkt Sie verwenden. ## Unser Versprechen Wir setzen alles daran, Ihnen zeitnah und effizient weiterzuhelfen. Ihre Ideen und Anliegen sind uns wichtig, und wir freuen uns, Sie auf Ihrem Weg zur erfolgreichen Digitalisierung zu begleiten. Unser Ziel ist es, gemeinsam mit Ihnen das Potenzial von MOXIS voll auszuschöpfen. Unsere definierten Reaktionszeiten für die Bearbeitung der Fehlermeldungen, sowie Informationen über mögliche Problemlösungen sind in unseren [**AGB**](https://www.xitrust.com/agb/) definiert. **Zögern Sie nicht, uns zu kontaktieren -- wir freuen uns darauf, Ihnen weiterzuhelfen!** --- version: "v1" language: "en" --- # (en) Support & Consulting ## (en) Support \& Consulting ### Documentation * #### [(en) Service \& Consulting Details](https://documentation.moxis.co/en/support-consulting/latest/service-consulting-details.md) * #### [(en) Our promise to you: Your feedback counts!](https://documentation.moxis.co/en/support-consulting/latest/public-roadmap.md) --- version: "v1" language: "en" --- # (en) Our promise to you: Your feedback counts! **XiTip** **Help shape the future of MOXIS -- tailored to your needs!** Would you like to know what innovations we are planning for XiTrust MOXIS -- or do you have your own ideas on how MOXIS could make your everyday life even easier? Then you've come to the right place: on this page, you can find out how to **discuss your requirements** directly with our product management or customer success team in a **personal conversation**. ## **Your feedback matters -- MOXIS tailored to your requirements** Your feedback helps us to * refine existing functions, * better align priorities with your needs, and * develop new features that deliver real added value in practice. Whether you have a suggestion for improvement, a feature request, or a specific challenge from your everyday life, we welcome any input. **XiTip** The better we understand your requirements, the more precisely we can tailor MOXIS to your needs. As a MOXIS customer, you have the following options for providing feedback. ### **For MOXIS Business Cloud customers:** **Q\&A sessions and individual consulting with tailor-made group support** Our Customer Success Team offers **weekly Q\&A-Sessions** for MOXIS Business Cloud Customers. **XiTip** Our Q\&A sessions take place every Thursday between 11:00 a.m. and 12:00 p.m. (except on public holidays). Please register at least one hour before the session by sending an email to [++academy@xitrust.com++](mailto:academy@xitrust.com). ### **Individual consultation for Enterprise customers:** Reserve your individual Coffee-Break appointment with us Would you prefer to discuss your requirements in person? Simply book an individual **coffee break** with our **product management** team at: [MOXIS Coffee Break - XiTrust](https://calendly.com/xitrust/coffe-break) **In this one-to-one meeting, we can work together to:** * **Go through your ideas and requirements in detail** * We take the time to understand your use cases, processes and specific requirements. * **Clarify questions about current or planned functions** * You will gain insights into how existing or upcoming features fit your scenarios. * **Discuss new solutions and further developments** * Together, we will examine how MOXIS can support you even better in the future. **Your benefits:** You will have direct access to our product team, can prioritise your topics and actively influence the further development of MOXIS. For **Enterprise customers** , **your personal contact person** is of course available as well to arrange an individual appointment. --- version: "v1" language: "en" --- # (en) Service & Consulting Details ## Service \& Consulting If you have questions about MOXIS, ideas for new features, or need support for implementing your digitalization strategies, our competent support team is here to assist you. We are committed to ensuring your concerns are addressed quickly and efficiently. ### How to Reach Us 1. **Service Desk:** Visit our support platform at [https://servicedesk.xitrust.com](https://servicedesk.xitrust.com/). Here, you can easily create support tickets, track the status of your requests, and access helpful documentation. 2. **E-Mail:** Alternatively, you can contact our team via email at [servicedesk@xitrust.com](mailto:servicedesk@xitrust.com). Please include as much information as possible in your message (e.g., your query, affected feature, relevant documents, or screenshots). This will help us process your request more quickly. ### What We Can Do for You Our support team is composed of experienced **MOXIS and digitalization experts**, ready to assist you with: * **Technical Questions:** Support with using MOXIS and assistance with specific features. * **Custom Requests:** Solutions tailored to your unique needs. * **Consultation and Ideas:** We are happy to discuss new approaches, innovative use cases, or potential enhancements related to MOXIS. * **Digitalization Projects:** Guidance on implementing your digitalization goals and integrating them into your existing systems. ### Tips for Quick Resolution * **Detailed Description:** Provide a precise description of your concern, including relevant details and, if applicable, the steps leading to the issue. * **Priority Indication:** Let us know if your issue is urgent. * **Screenshots and Files:** Attach any files or screenshots that can help clarify your request. * **Your Information:** Please include details about your MOXIS instance (URL) and the product you are using. ### Our Commitment We strive to assist you promptly and effectively. Your ideas and concerns are important to us, and we look forward to supporting you on your journey to successful digitalization. Our goal is to help you fully leverage the potential of MOXIS. Our defined response times for addressing error reports, as well as information on possible solutions, are outlined in our Terms and Conditions (AGB). ### We Understand Your Needs We recognize the critical role a functioning service plays in your business success. That's why we are committed to clearly defined response times, which include handling error reports and providing information about potential solutions. These terms are specified in our [AGB](https://www.xitrust.com/agb/). *** ** * ** *** Do not hesitate to contact us -- we look forward to assisting you! --- version: "[4.55]" language: "de" --- # MOXIS 4.55 Enterprise Cloud & On Premises Benutzerhandbuch ## MOXIS 4.55 Enterprise Cloud \& On Premises Benutzerhandbuch ### Documentation * #### [MOXIS 4.55: Neues Design mit erweiterten Funktionen und Signaturqualitäten!](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/moxis-4-55-neues-design-mit-erweiterten-funktionen.md) * #### [Der Signaturprozess in MOXIS 4.55](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-der-signaturprozess-in-moxis-4-52.md) * #### [Das Dashboard: Funktion und Übersicht](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v-4-52-das-dashboard-funktion-und-ubersicht.md) * #### [Auftragsübersicht und Unterschriftenmappen in MOXIS 4.55](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/auftragsubersicht-und-unterschriftenmappen-in-moxi.md) * #### [Verhalten von MOXIS 4.55 auf Tablets und Smartphones (Responsive Design)](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/verhalten-von-moxis-4-55-auf-tablets-und-smartphon.md) #### [Tägliche Arbeitsabläufe](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-tagliche-arbeitsablaufe.md) #### [Empfänger:innen Übersicht](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-empfanger-innen-ubersicht.md) #### [Unterschriftenposition festlegen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-unterschriftenposition-festlegen.md) #### [Formularfelder in MOXIS 4.55 Übersicht](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-formularfelder-ubersicht.md) * #### [Die Detailansicht](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-die-detailansicht.md) #### [Dokumente signieren](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-dokumente-signieren.md) #### [Aufträge verwalten Übersicht](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-auftrage-verwalten-ubersicht.md) #### [Externe Signierende Übersicht](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-externe-unterschreiber-innen-ubersicht.md) * #### [Zusätzliche Empfänger:innen des unterschriebenen Dokuments hinzufügen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-zusatzliche-empfanger-innen-des-unterschrieb.md) #### [Arbeiten mit Vorlagen Übersicht](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-arbeiten-mit-vorlagen-ubersicht.md) * #### [Wiederverwenden von bereits erstellten Aufträgen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-wiederverwenden-von-bereits-erstellten-auftr.md) * #### [Arbeiten mit Entwürfen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-arbeiten-mit-entwurfen.md) * #### [OPTIONAL: Private Entscheidungsebenen definieren](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-private-entscheidungsebenen-definieren-option.md) * #### [OPTIONAL: Mehrfachvisualisierungen anlegen, signieren und prüfen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-mehrfachvisualisierungen-ubersicht-optional.md) #### [Persönliche Einstellungen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-personliche-einstellungen.md) * #### [Erweiterung der Sprachauswahl](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-erweiterung-der-sprachauswahl-in-moxis-4-52.md) * #### [PDF/A-Konvertierung](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/pdf-a-konvertierung.md) * #### [Doc/DocX Konvertierung](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/doc-docx-konvertierung.md) --- version: "[4.55]" language: "de" --- # OPTIONAL: Anmerkungen zu Entscheidungsebenen Als Auftraggeber:in können Sie in MOXIS unter den Entscheidungsebenen Anmerkungen für die Signierenden hinzuzufügen (siehe *Abbildung 1* ). Diese Anmerkungen sind für die Signierenden in der Detailansicht des Auftrags ebenfalls unter den Entscheidungsebenen (siehe *Abbildung 2 \[1\]*) ersichtlich. **MOXIS Tipp** Die Möglichkeit ein Kommentar zu setzen hängt von dem MOXIS Produkt, das Sie nutzen und den seitens der Administrator:innen hinterlegten Einstellungen ab. Bei Fragen zu diesem Feature und seiner Anwendbarkeit wenden Sie sich bitte an Ihr:e XiTrust Ansprechpartner:in. ![01_Entscheidungsebene.png](https://documentation.moxis.co/__attachments/a_6d700204590aa72cbdf7cc2d3bc18dd1bb2f9bb97b8617b4dabf33f61ff871a8/01_Entscheidungsebene.png?cb=c5a828f6a5082ece88429b27d5059e42) *Abbildung 1: Anmerkung in Entscheidungsebene* ![02_Detailansicht_Kommentar.png](https://documentation.moxis.co/__attachments/a_b0e068578c8a71a90dd36bd85c6cf3db85df1e324a6c5d29f914a9738aebbc7c/02_Detailansicht_Kommentar.png?cb=d35477ea93d6262803a024c4a7c298c1) *Abbildung 2: Detailansicht des Auftrags mit Kommentar* **MOXIS Tipp** Anmerkungen sind auch in MOXIS Guest für externe Signierende möglich. --- version: "[4.55]" language: "de" --- # Benachrichtigungen konfigurieren **Inhalt** MOXIS bietet Ihnen in den Benutzereinstellungen die Möglichkeit, prozessabhängige und regelmäßige E-Mail-Benachrichtigungen individuell zu konfigurieren. Dieser Artikel informiert Sie über die Grundlagen. *** ** * ** *** ## 1. Konfiguration von Benachrichtigungen in MOXIS 4.55 Grundsätzlich haben Sie **zwei Möglichkeiten** , **Benachrichtigungen**zu konfigurieren: * Einstellungen für Prozesse (siehe *Abbildung 2 \[1\]*) * Einstellungen für regelmäßige Benachrichtigungen (siehe *Abbildung 2 \[2\]*) Zu**beiden Optionen** gelangen Sie über die**MOXIS Einstellungen** \>**Benachrichtigungen**. ### 1.1. Konfiguration von prozessabhängigen Benachrichtigungen Sollten Sie dazu berechtigt sein, mehrere Prozesse zu verwenden, müssen Sie zunächst den Prozess wählen, für den Sie die Einstellungen festlegen möchten (siehe *Abbildung 1* und *2 \[3\]* ). **Bitte beachten Sie:** Die Einstellungen müssen für jeden Prozess einzeln konfiguriert und abgespeichert werden. ![98b764b1-1e66-4359-a81a-900dfd9a1829](https://documentation.moxis.co/__attachments/a_fd6d206af7d54dd78de34262322003ddf1912e3c3f1a675283cbc64c1d627735/98b764b1-1e66-4359-a81a-900dfd9a1829?cb=ac26fa9750e3d171f9265d1bd7373049) *Abbildung 1: Prozess zum Editieren in den Einstellungen für Prozesse auswählen* Bei den **prozessabhängigen Benachrichtigungen** können je Prozess und Prozessschritt E-Mail-Benachrichtigungen durch das Setzen oder Entfernen des Häkchens aktiviert bzw. deaktiviert werden (siehe *Abbildung 2 \[4\]* ). Mit einem Klick auf den **\[Speichern\]** -Button (siehe *Abbildung 2 \[5\]*) speichern Sie die Einstellungen. ![06_Beachrichtigungen.png](https://documentation.moxis.co/__attachments/a_78a183f373736234d2163c61cd6c4c409b246634cf06c6843be3b638160059bf/06_Beachrichtigungen.png?cb=c5252962c7bffbeff2624b3d9a8e4430) *Abbildung 2: Benachrichtigungen für Prozesse* ### 1.2. Konfiguration von regelmäßigen Benachrichtigungen Für regelmäßige Benachrichtigungen können beliebig viele Benachrichtigungszeiträume hinterlegt werden. Dadurch erfolgt eine Benachrichtigung über alle empfangenen Aufträge (sogenannte Sammelbenachrichtigungen; siehe *Abbildung 3* ). Um Benachrichtigungen zu erhalten, setzen Sie bitte das Häkchen in der Checkbox (siehe *Abbildung 3 \[1\]* ). Um diese zu bearbeiten, klicken Sie auf das Stift-Icon (siehe *Abbildung 3 \[3\]* ) in der Zeile des entsprechenden Eintrags oder klicken Sie auf das x-Icon, um den Eintrag zu löschen (siehe *Abbildung 3 \[3\]* ) . In der Spalte Tage erhalten Sie die Übersicht über die für die bestimmte Benachrichtigung konfigurierten Stunden und Tage (siehe *Abbildung 3 \[2\]*). ![07_Regelmäßige_Benachrichtigungen.png](https://documentation.moxis.co/__attachments/a_c33348d5c21130ec32ca8b5e4a46593146ee374b1c8231bee8c8472a131574b4/07_Regelm%C3%A4%C3%9Fige_Benachrichtigungen.png?cb=b2566475a86daf52278123a35cdc3c29) *Abbildung 3: Einstellungen für regelmäßige Benachrichtigungen* --- version: "[4.55]" language: "de" --- # OPTIONAL: Einführung Platzhaltergenerator **Inhalt** Um Signierenden in MOXIS die Möglichkeit zu geben, ihre Unterschrift abzugeben, können Sie unter anderem einen sogenannten Platzhalter nutzen. Dies ist abhängig von der Konfiguration Ihrer MOXIS-Instanz bzw. den an Sie vergebenen Rechten. *** ** * ** *** ## 1. Allgemeine Informationen zu Platzhaltern Es gibt **zwei Arten** von **Platzhaltern**: * Persönliche Platzhalter (siehe *Abbildung 1*) und * Gruppenplatzhalter * Ein **Gruppenplatzhalter** ist ein Platzhalter, der festlegt, dass hier nur Benutzer:innen, welche Mitglieder einer bestimmten Gruppe bzw. Rolle sind, hier signieren dürfen. Diese Gruppen werden beispielsweise bei einer Anbindung an das Active Directory von dem oder der Netzwerkadministrator:in angelegt. Man unterscheidet zwischen **Einzelplatzhaltern** und **Mehrfachplatzhaltern**. **MOXIS Tipp** Platzhalter funktionieren nur in der Instanz, in der sie generiert wurden! Folgende Informationen können Sie aus dem Beispiel eines Persönlichen Platzhalters (siehe *Abbildung 1* ) ziehen: Im **QR-Code** des**Platzhalters** ist die Information enthalten, **wer** in **welchem Prozess** in **welcher Qualität** (Unterschrift, Freigabe, intern oder extern) und in welcher **Entscheidungsebene**signieren soll. Dies kann dann nachträglich im Prozess nicht mehr geändert werden, weil die Platzhalter bereits als Teil des Dokuments hochgeladen werden. Zudem enthalten persönliche Platzhalter weitere Informationen, wie zum Beispiel den Namen des Benutzers oder der Benutzerin, die unterschreiben soll und die Entscheidungsebene (in unserem Beispiel ist dies die erste, da mit U1 gekennzeichnet). ![02a_Beispiel_für_Platzhalter.jpg](https://documentation.moxis.co/__attachments/a_b396a29432c9e9352c90d6e38b171c1b966b80accb251cd7f2da0ab7e7145a3e/02a_Beispiel_f%C3%BCr_Platzhalter.jpg?cb=a1e1bb771bae030509d7c2743b1749ae) *Abbildung 1: Persönlicher Platzhalter* ## 2. Der Platzhaltergenerator Sie können im**Platzhaltergenerator** persönliche Platzhalter und Gruppenplatzhalter erstellen. Den Platzhaltergenerator finden Sie in Ihren **Profileinstellungen** . Im ersten Schritt wählen Sie bitte, ob Sie einen Gruppenplatzhalter oder einen Persönlichen Platzhalter generieren möchten (siehe *Abbildung 2*). Je nachdem, für welchen Platzhalter Sie sich entschieden haben, folgen Sie bitte den Ausführungen in den nächsten Kapiteln. ### 2.1. Gruppenplatzhalter erstellen Unter dem Reiter Gruppenplatzhalter generieren finden Sie alle relevanten Informationen zur Generierung eines Gruppenplatzhalters. Zunächst aber werfen wir einen Blick auf die einzelnen Optionen, die Sie beim Erstellen eines Gruppenplatzhalters haben (siehe *Abbildung 2 \[1\] - \[5\]*). **(1) Platzhaltertyp auswählen:** Hier legen Sie fest, ob Sie einen Einzel- oder Mehrfachplatzhalter erstellen möchten.**Bitte beachten Sie:** Bei der Variante **Einzelplatzhalter** wird nur**eine Person** aus einer Gruppe eingeladen. Hingegen können bei der Variante **Mehrfachplatzhalter** **eine**oder**mehrere Personen** eingeladen werden. Dabei bekommen alle eingeladenen Personen eine E-Mail mit der Aufforderung zur Unterschrift zugesendet, jedoch kann pro Platzhalter nur eine Person aus der Gruppe unterschreiben. Hierbei gilt das **First-Come-First-Serve-Prinzip**. **(2) Signaturtyp wählen:** Im nächsten Schritt wählen Sie den Signaturtyp. **(3) Platzhalterrolle definieren:** Geben Sie hier bitte den Namen der Gruppe ein, aus der eine Person eingeladen werden soll. **Bitte beachten Sie:** Diese Option gilt nur, wenn Sie im Platzhaltertyp **Einzelplatzhalter**gewählt haben. **(4) Platzhaltertext eingeben:**Fügen Sie hier einen Platzhaltertext (frei wählbar) ein. Der Text sollte so gestaltet sein, dass auf einen Blick klar erkennbar ist, um welchen Gruppenplatzhalter es sich handelt. **(5) Platzhalteriteration bestimmen:**Hier bestimmen Sie, in welcher Entscheidungsebene der Platzhalter platziert werden darf. ![10_Platzhalter.png](https://documentation.moxis.co/__attachments/a_5aed279c9b21928a8939bac3ed6f7d42ab43236fde95b3aa8cdb78e80deaf9cf/10_Platzhalter.png?cb=9e2fda538df325a99602299b2bc5b4e4) *Abbildung 2: Platzhaltergenerator - Gruppenplatzhalter generieren Übersicht* #### 2.1.1. Gruppenplatzhalter als Einzelplatzhalter generieren Um einen **Einzelplatzhalter** zu erstellen, wählen Sie als **Platzhaltertyp** im **Reiter Gruppenplatzhalter generieren** die Option **Einzelplatzhalter** (siehe *Abbildung 3*). Sobald Sie alle weiteren Felder befüllt haben, können Sie den Platzhalter herunterladen. Ihnen stehen dabei drei Größen zur Verfügung: * **klein**(200 px breit) * **mittel**(270 px breit) * **groß**(400 px breit) ![11_Einzelplatzhalter.png](https://documentation.moxis.co/__attachments/a_32594976bbe2457589694d06be217babb56115799137b0ea045b67aabe73e887/11_Einzelplatzhalter.png?cb=a7697218bd27b01246af194b4153c75c) *Abbildung 3: Einzelplatzhalter generieren* #### 2.1.2. Gruppenplatzhalter als Mehrfachplatzhalter generieren Um einen **Mehrfachplatzhalter** zu erstellen, wählen Sie als **Platzhaltertyp** im **Reiter Gruppenplatzhalter generieren** die Option **Mehrfachplatzhalter** (siehe *Abbildung 3*). Sobald Sie alle weiteren Felder befüllt haben, können Sie den Platzhalter herunterladen. Ihnen stehen dabei drei Größen zur Verfügung: * **klein**(200 px breit) * **mittel**(270 px breit) * **groß**(400 px breit) ![12_Gruppenplatzhalter.png](https://documentation.moxis.co/__attachments/a_5159074f0d019560d3888e25ca8b76344ae8881e371f8a0629ed27965834ec2d/12_Gruppenplatzhalter.png?cb=215ec29f656c9eb96a776325b49cbba5) *Abbildung 4: Mehrfachplatzhalter in MOXIS* ### 2.2. Persönlichen Platzhalter erstellen Ein persönlicher Platzhalter ist fest einem oder einer MOXIS-Benutzer:in zugeordnet. Um einen persönlichen Platzhalter zu erstellen, klicken Sie auf den Reiter **Persönlichen Platzhalter generieren** , wählen den **Signaturtyp** und die **Person** aus, für welche Sie den Platzhalter erstellen wollen, und definieren darüber hinaus die Entscheidungsebene. (siehe *Abbildung 5*). Wie bei Gruppenplatzhaltern können Sie beim Download zwischen drei Größen wählen. ![14a_Platzhalter_generieren.png](https://documentation.moxis.co/__attachments/a_a7ee22813a26d7f0f0a6411e5796667ac4a410bdf00e9c546ba5162d222ff518/14a_Platzhalter_generieren.png?cb=d25db8230f37337bef98a0fdd7c46c5d) *Abbildung 5: Persönlichen Platzhalter generieren* --- version: "[4.55]" language: "de" --- # OPTIONAL: Einsichtnehmer:innen bearbeiten **Inhalt** In den MOXIS-Einstellungen können Benutzer:innen unter dem Menüpunkt **Einsichtnehmer bearbeiten** anderen MOXIS-User:innen Einsicht in Unterschriften- oder Freigabeprozesse gewähren. Dieser Artikel bringt Ihnen das Thema näher. **MOXIS Tipp** **Bitte beachten Sie:** Einsichtnehmer:innen verfügen über keinerlei Eingriffsmöglichkeiten auf die für sie ersichtlichen Prozesse -- sie besitzen lediglich Leserechte. Die einzige erlaubte Aktion ist der Download von Dokumenten. *** ** * ** *** ## 1. Konfiguration von Einsichtnehmenden Um Einsichtnehmer:innen für Ihre Mappe zu konfigurieren, klicken Sie einfach auf den**\[+ Einsichtnehmer hinzufügen\]** -Button. Sodann öffnet sich eine Maske, in welcher Sie die folgenden Daten konfigurieren können (siehe *Abbildung 1*): * **Typ:**Wählen Sie zwischen Ihrer persönlichen Unterschriftenmappe oder Freigabemappe bzw. entscheiden Sie sich für beide. * **Name der Mappe:** Unter diesem Namen wird die Mappe beim Einsichtnehmer angezeigt. * **Einsichtnehmer:in:**Dieser Person gewähren Sie Einsicht auf Ihre Mappe. Wenn Sie die ersten Buchstaben des Namens eintragen, wird der oder die korrespondierende User:in angezeigt. **Bitte beachten Sie:** Jedes dieser Felder ist ein Pflichtfeld. Mit einem Klick auf den**\[Speichern\]**-Button speichern Sie Ihre Änderungen. ![image-20241128-190511.png](https://documentation.moxis.co/__attachments/a_c634424e7db8ebf7a146d4a4b2bf5eb3c476f0f5ed4334a0f3c890b9419f5606/image-20241128-190511.png?cb=bfd850345a807eeb46e780664d0b5a14) *Abbildung 1: Einsichtnehmer:innen hinzufügen* Um eine:n Einsichtnehmer:in zu **bearbeiten** , klicken Sie auf das **Stift-Icon** in der **Einsichtnehmer bearbeiten-Übersicht** (siehe *Abbildung 2 \[1\]* ). Um ihn zu **löschen** , klicken Sie auf das **X-Icon** (siehe *Abbildung 2 \[2\]*). ![09_Einsichtnehmer_einrichten.png](https://documentation.moxis.co/__attachments/a_3c2e01ab970cb74cfd189f6e35a8d9af9ef5545382a884551702da63f3b3f3e1/09_Einsichtnehmer_einrichten.png?cb=0e18720e0afb5a42579c69402894913c) *Abbildung 2: Einsichtnehmer:innen bearbeiten und löschen in MOXIS* ## 2. Zugang für Einsichtnehmende Für berechtigte **Einsichtnehmer:innen** wird die Option zur Einsichtnahme im **Seitenmenü** in der Auftragsübersicht unter dem Punkt **Zur Einsicht** und der entsprechenden Mappe angezeigt (siehe *Abbildung 3*). **MOXIS Tipp** **Neu ab MOXIS 4.55** ist, dass Einsichtnehmer:innen in der Auftragsübersicht unter dem Tab "Einsichtnehmer" zu finden sind. Ist ein:e Einsichtnehmer:in für mehrere Personen eingetragen, öffnet sich beim Klick auf den Tab eine Auswahlliste mit allen Personen (Namen und ggf. Avatar). Mit einem Klick auf die gewünschte Person öffnet sich deren Auftragsmappe. Nach dem Wechsel werden Ihnen die Offenen Aufträge und die Erledigte Aufträge der zu beobachtenden Person angezeigt. **Bitte beachten Sie:**Alle anderen Mappen sind nicht sichtbar für Einsichtnehmer:innen. Abgesehen davon ist es abhängig vom konfigurierten Typ der Einsichtnahme, welche Aufträge Einsichtnehmer:innen genau angezeigt werden. Dafür gibt es drei Möglichkeiten: * **Alle Signaturen/Freigaben** Alle Aufträge sind sichtbar * **Qualifizierte Signaturen** Nur QES-Aufträge * **Freigaben \& Signaturen** Freigabe- und FES- und SES-Aufträge --- version: "[4.55]" language: "de" --- # Erweiterung der Sprachauswahl MOXIS ist seit Version 4.55 in **18 Sprachen**verfügbar: * Deutsch * Schweizerdeutsch * Englisch * Bulgarisch * Tschechisch * Rumänisch * Griechisch * Spanisch * Französisch * Kroatisch * Ungarisch * Italienisch * Japanisch * Mazedonisch * Polnisch * Slowakisch * Slowenisch * Chinesisch **MOXIS Tipp** Die Sprache wird bei Bedarf beim Deployment hinzugefügt. Sollte Rumänisch auf Ihrer Wunschliste für die optimale Konfiguration Ihrer MOXIS Instanz stehen, so wenden Sie sich bitte an Ihre:n XiTrust Ansprechpartner:in und bringen Sie dies zur Sprache. --- version: "[4.55]" language: "de" --- # Formularfelder Adaptionen und Konfigurationen **Inhalt** Formularfelder können konfiguriert und intuitiv für Ihre Zwecke angepasst werden. Dieser Artikel beschreibt, welche Möglichkeiten Sie hinsichtlich der Anpassung von Formularfeldern in MOXIS haben. *** ** * ** *** ## 1. Verschieben von Formularfeldern Um ein Formularfeld zu verschieben, klicken Sie auf das **=** ***-Zeichen*** (siehe *Abbildung 1 \[1\])* . Via drag-and-drop können Sie nun das Formularfeld verschieben. Das**+** ***-Zeichen*** (siehe *Abbildung 2 \[1\]*) eröffnet Ihnen weitere Möglichkeiten der Bearbeitung, die im nächsten Kapitel erklärt werden. ![04a_Zustimmung_Radiobutton(1).png](https://documentation.moxis.co/__attachments/a_303848dafd4e161725e6df79276050b05b55efcdb50136a22c20ea079df49c56/04a_Zustimmung_Radiobutton(1).png?cb=2badbb80ea045a8df27dd0b903539f29) *Abbildung 1: Verschieben von Formularfeldern in MOXIS und weitere Bearbeitungsmöglichkeiten* ## 2. Sperren, bearbeiten, drehen und löschen von Formularfeldern Zur Bearbeitung von **Formularfeldern** stehen Ihnen weitere Möglichkeiten in **MOXIS** zur Verfügung. Um diese zu nutzen, streichen Sie einfach über das **+** ***-Zeichen*** . Daraufhin verwandelt sich das **Plus-Zeichen** in ein**X** (siehe *Abbildung 2 \[1**\]* ) und es scheinen weitere **Möglichkeiten** zur **Bearbeitung.** ![01a_Übersicht_Bearbeitungsmöglichkeiten(1).png](https://documentation.moxis.co/__attachments/a_d02f402fd0651370f1ff6c7728c04f295cff70aa91ea8ce75b1c3345fa6e4b7e/01a_%C3%9Cbersicht_Bearbeitungsm%C3%B6glichkeiten(1).png?cb=cb597aa938b7f379588b17a537f97e79) *Abbildung 2: Übersicht Bearbeitungsmöglichkeiten von Formularfeldern* **Diese Möglichkeiten haben Sie, um Formularfelder anzupassen:** **(2)** **Sperren:** Ist diese **Option aktiviert** (das Schloss geschlossen), kann das Formularfeld von **niemandem** mehr **bearbeitet**werden. Durch einen erneuten Klick auf das Schloss, welches dann "geöffnet" erscheint, wird das Formularfeld wieder für alle zur Bearbeitung frei gegeben. **(3) Bearbeiten:** Mit einem Klick auf diesen Button eröffnen Sie sich diverse Möglichkeiten zur **Bearbeitung** des **Formularfeldes**. **(4) Drehen:** Mit Hilfe dieses Buttons können Sie das **Formularfeld** dem **Layout** Ihres **hochgeladenen Dokuments** anpassen (sofern zB im Querformat unterschrieben werden soll oder hochkant). Ein Klick auf den Button bewirkt, dass das Feld sich um **90 Grad**dreht. **(5) Löschen:** Hier **entfernen**Sie das Formularfeld. ## 3. Konfigurieren von Formularfeldern Über das Zahnrad (siehe *Abbildung 2 \[3\]*) haben Sie die Möglichkeit, Formularfelder im Detail zu bearbeiten. Wir bilden die Bearbeitung hier anhand des Beispiels eines Währungsformularfeldes ab. Die Konfiguration aller anderen Felder unterscheidet sich hauptsächlich darin, dass feldspezifische Parameter konfiguriert werden können. Öffnen Sie den **Editor** des **Formularfelds** *Währung* mit einem **Klick** auf das **Zahnrad** . In der so geöffneten Oberfläche können Sie die Konfiguration des Feldes vornehmen (siehe *Abbildung 3, \[1-6\]*). ![02a_Währungsfeld.png](https://documentation.moxis.co/__attachments/a_95b238407a2acc237a5fb25a377ba164c3458689f7ebce72b68e846a56068208/02a_W%C3%A4hrungsfeld.png?cb=3b37da03f81a5d883a3674c1f0541f7b) *Abbildung 3: Übersicht über die Konfigurationsmöglichkeiten eines Währungsfeldes in MOXIS* **Folgende Möglichkeiten stehen Ihnen zur Verfügung, das Formularfeld zu konfigurieren:** **(1) Name:** Hinterlegen Sie hier eine Bezeichnung für das Währungsfeld (zB US-Dollar für Auslandsauftrag). **(2) Währung:**Über das Drop-Down Menü Währung haben sie die Möglichkeit, eine bestimmte Währung auszuwählen. Klicken Sie dafür auf den Pfeil neben dem Euro-Symbol. Sie können aktuelle zwischen Euro, Dollar, Schweizer Franken oder Pfund wählen (Stand 06/24). **(3) Dezimalstellen:**Legen Sie hier fest, wie viele Ziffern hinter dem Komma angezeigt werden sollen, indem Sie die entsprechende Zahl angeben. **(4) Formatierung:** Halten Sie hier das Format fest, in welchem die Hunderter-Schritte der Währung angezeigt werden sollen. Sie können zwischen Punkt, Komma, Hochkomma oder keinen Trennenden Elementen wählen. **(5) Währung vorangestellt:**Über diesen Regler bestimmen Sie, ob das Währungssymbol voran oder hintan gestellt wird. **(6) Schriftart:** Mit einem Klick auf den Drop-Down Pfeil neben der Zahl (in unserem Beispiel sehen Sie die standardmäßig eingestellte Schriftgröße 12) können Sie die Größe der Schrift ändern. **MOXIS Tipp** Bitte beachten Sie: Wenn Sie die Schriftgröße ändern, kann es sein, dass Sie auch die Größe des Formularfeldes anpassen müssen (siehe nächstes Kapitel) ## 4. Größenanpassung von Formularfeldern in MOXIS Die **Größe** eines **Formularfelds** zu **verändern** ist denkbar einfach und erfolgt intuitiv. Klicken Sie dazu einfach in das Formularfeld. Im **rechten unteren Eck** des Feldes erscheint ein **Kantensymbol** . Wenn Sie mit der Maus darüber streichen, verwandelt sich der **Mauszeiger** in einen **Pfeil** (siehe *Abbildung 4 \[1\]* ). Sobald das geschehen ist, klicken Sie das Kantensymbol mit der linken Maustaste an und ziehen das Feld nach Belieben größer oder kleiner. In unserem Beispiel wurde das Feld vergrößert (siehe *Abbildung 4 \[2\]*) ![03a_Größe_anpassen.png](https://documentation.moxis.co/__attachments/a_2c0f6948b6c2515d9445973c53ab36860301dd6b14028a180156e3a52f3023c5/03a_Gr%C3%B6%C3%9Fe_anpassen.png?cb=0121c63b34268c26fb4305c854c889f4) *Abbildung 4: Größe von Formularfeldern in MOXIS anpassen* --- version: "[4.55]" language: "de" --- # Formularfelder sperren **Inhalt** MOXIS erlaubt es, zugewiesene Formularfelder zu sperren. Dazu gibt es zwei Möglichkeiten. Entweder, Sie laden ein PDF mit Formularfeldern hoch, die Sie zuweisen müssen oder Sie arbeiten mit entsprechend zu sperrenden und zuzuweisenden Feldern direkt in MOXIS. Dieser Artikel informiert über die Möglichkeiten, die MOXIS dahingehend bietet. *** ** * ** *** ## 1. Funktion Formularfelder sperren Formularfelder dienen der Integration von diversen Feldern (Text, Währung, Signatur ...) in PDFs, die in MOXIS hochgeladen und später befüllt werden können. Für generelle Informationen zur Handhabe von Formularfeldern klicken Sie bitte [hier](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-formularfelder-sperren-ab-moxis-4-52). ### 1.1. Gesperrte Formularfelder erkennen Formularfelder, die Ihnen in MOXIS zugewiesen werden, sind farblich hinterlegt bis die Signatur erfolgt ist. **MOXIS Tipp** **Bitte beachten Sie:**Formularfelder können alle Signaturqualitäten (von der Freigabe bis zur Qualifizierten Signatur) beinhalten ### 1.2. Regeln zu gesperrten Formularfeldern **Verhalten bei mehreren Signierenden in einer Entscheidungsebene** Wenn mehrere User:innen in einer Entscheidungsebene zu unterschreiben haben, dann werden die Formularfelder nach jeder einzelnen Signatur des jeweiligen Users gesperrt. **Verhalten bei einer Gruppe von Signierenden in einer Entscheidungsebene** Wenn mehrere User:innen aus einer Gruppe in einer Entscheidungsebene unterschreiben sollen, so werden die Formularfelder erst gesperrt, wenn der letzte User oder die letzte User:in unterschrieben hat. **Verhalten, wenn Formularfelder nicht zugewiesen werden** Wenn Formularfelder nicht zugewiesen werden, dann werden sie auch nicht gesperrt. **Verhalten, wenn Formularfelder zugewiesen, aber nicht bearbeitet werden** Wenn Formularfelder zugewiesen werden, aber nicht bearbeitet, dann werden sie ebenfalls gesperrt. **Verhalten bei mehreren User:innen in mehreren Entscheidungsebenen** Wenn es mehrere Benutzer:innen in mehreren Entscheidungsebenen gibt, so bekommt jede:r eigene Formularfelder zugewiesen (siehe *Abbildung 1 \[1\] und* siehe *Abbildung 1 \[2\]*). Diese erhalten jeweils eine Farbe (Signierende 1 türkis, Signierender 2 gold). Diese Farbe ist dem oder der User:in durchgehend zugeordnet - von der Auftragsanlegeseite (nur von der Auftraggeber:in einsehbar) bis hin zum Auftrag selbst, der von den jeweiligen Signierenden unterschrieben werden soll. Nachdem die erste Signierende unterschrieben hat, werden ihre oder seine Formfelder gesperrt. Dies gilt jedoch nicht für die Formularfelder der oder des zweiten Signierenden (siehe *Abbildung 1 \[2\] in gold hinterlegt*) Letztere werden erst gesperrt, wenn der oder die zweite User:in unterschrieben hat. ![06_Formularfelder.png](https://documentation.moxis.co/__attachments/a_b2d96dd7728f8757582291d4815de3399a850274aa46d8bf36331e0a3e11f07e/06_Formularfelder.png?cb=6612b9b6530e86addb9573de1e32431c) *Abbildung 1: Zwei Signierende mit dazugehörigen Formularfeldern in zwei Entscheidungsebenen* --- version: "[4.55]" language: "de" --- # Formularfelder in MOXIS 4.55 Übersicht * [Formularfelder](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-formularfelder.md) Formularfelder in MOXIS dienen dem Zuweisen von Personen auf bestimmte Felder in einem zu signierenden Dokument. Dabei gibt es mehrere Arten von Formularfelder, unter anderem Text- oder Datumsfelder und Radiobuttons. Es gibt zwei Möglichkeiten, Formularfelder zu platzieren. Dieser Artikel informiert Sie über die verschiedenen Arten von Formularfeldern, die es gibt und die Möglichkeiten ihrer Platzierung. * [Schritt-für-Schritt Anleitung zur Konfiguration von Radiobuttons in MOXIS](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/schritt-fur-schritt-anleitung-zur-konfiguration-vo.md) Radiobuttons erlauben es, zwischen mehreren Optionen zu wählen. In dieser Anleitung erfahren Sie, wie Sie sie konfigurieren. * [Formularfelder Adaptionen und Konfigurationen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-formularfelder-adaptionen-und-konfigurationen.md) Formularfelder können konfiguriert und intuitiv für Ihre Zwecke angepasst werden. Dieser Artikel beschreibt, welche Möglichkeiten Sie hinsichtlich der Anpassung von Formularfeldern in MOXIS haben. * [Formularfelder sperren](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-formularfelder-sperren-ab-moxis-4-52.md) MOXIS erlaubt es, zugewiesene Formularfelder zu sperren. Dazu gibt es zwei Möglichkeiten. Entweder, Sie laden ein PDF mit Formularfeldern hoch, die Sie zuweisen müssen oder Sie arbeiten mit entsprechend zu sperrenden und zuzuweisenden Feldern direkt in MOXIS. Dieser Artikel informiert über die Möglichkeiten, die MOXIS dahingehend bietet. --- version: "[4.55]" language: "de" --- # Kontoeinstellungen: Der Konto-Tab **Inhalt** Hier haben Sie die Möglichkeit, Ihre Kontoeinstellungen zu ändern. Dieser Artikel zeigt auf, wie. *** ** * ** *** ## 1. Kontoeinstellungen in MOXIS 4.55 In den Kontoeinstellungen können Sie folgende Anpassungen vornehmen (siehe *Abbildung 1 \[1\] - \[6\]*): **(1) Sprachwahl:**MOXIS steht den Benutzer:innen in verschiedenen Sprachen zur Verfügung. Sie können die Spracheinstellungen mithilfe des Drop-Down-Menüs ändern und Ihre bevorzugte Sprache hier wählen. **MOXIS Tipp** Schon gewusst? MOXIS ist ab Version 4.55 in 18 verschiedenen Sprachen erhältlich. **(2) Kontodetails:** Die Basis-Kontodaten (Name, E-Mail-Adresse) werden je nach Konfiguration entweder über die MOXIS-Datenbank oder aus dem Active Directory ausgelesen und können daher nicht selbst von Benutzer:innen abgeändert werden. Etwaige Änderungen können Administrator:innen über das führende System durchführen. Über den **\[Benutzerdaten ändern\]**-Button können Sie (sofern Sie Keycloak Login nutzen) die Einstellungen für Ihre Authentifizierung bearbeiten. **(3) Profilbild:** Hier können Sie ein eigenes Profilbild hochladen, das anstelle des farbigen Benutzer-Icons angezeigt wird. **(4) Benutzer-Icon:**Das Benutzer-Icon kann hinsichtlich Füll- und Textfarbe individualisiert werden. **(5) WCAG-Modus:**Mit WCAG sind die Web Content Accessibility Guidelines gemeint. Wenn Sie das Kästchen durch das Setzen eines Häkchens aktivieren, dann starten Sie MOXIS im barrierefreien Modus. **\[Speichern\]-Button:** Bitte vergessen Sie nicht, Ihre Änderungen zu speichern.**Bitte beachten Sie:**Bereits während der Ausführung des nächsten Navigationsschrittes sind alle Änderungen sichtbar. ![03_Konto_Tab.png](https://documentation.moxis.co/__attachments/a_bf3d87edf4f86666edabd00aca3bf3da6cf5a2b977db73f75594215988c2b952/03_Konto_Tab.png?cb=e9b4ffb0bc4a8e77104d019ade47a4a5) *Abbildung 1: Kontoeinstellungen in MOXIS* ### 1.1. Änderung der Einstellungen für die Authentifizierung via Keycloak Login Um diese Einstellungen zu ändern, klicken Sie zunächst bitte auf den **\[Benutzerdaten ändern\]** -Button in den Kontodetails (siehe *Abbildung 1 \[2\]*). Ein neues Fenster öffnet sich. Im *Reiter Persönliche Angaben* ist es möglich, die persönlichen Angaben zu ändern (siehe *Abbildung 2* ). Unter dem Reiter *Kontosicherheit \> Anmeldung* kann sodann das Passwort und die 2-Faktor-Authentifizierung aktiviert werden, indem Sie den Instruktionen folgen (siehe *Abbildung 3*). ![5fbdc2ce-c309-4c94-a8bd-908a1d95da26.png](https://documentation.moxis.co/__attachments/a_7f28e23c318f21bd6343841d8efdbf027afcc530b63632fc25571cc6b97391ed/5fbdc2ce-c309-4c94-a8bd-908a1d95da26.png?cb=a7d50313ae63aae0aec1e946044af43c) *Abbildung 2: Passwort ändern und Zwei-Faktor Authentifizierung aktivieren* ![f866cce5-1b49-4e70-bfc6-3152bfbdd12a.png](https://documentation.moxis.co/__attachments/a_b860da509a9ede21124ebf0fd5fb73ce47a4ccb18632083c2c08cb54f2a9ed6d/f866cce5-1b49-4e70-bfc6-3152bfbdd12a.png?cb=965da2a2bf5d3302af327c11dfaf6fb6) *Abbildung 3: Passwort ändern und Zwei-Faktor Authentifizierung aktivieren* --- version: "[4.55]" language: "de" --- # OPTIONAL: Mehrfachvisualisierungen anlegen, signieren und prüfen **Inhalt** MOXIS ermöglicht es User:innen dank eines definierten Prozesses mehrere gleiche Signaturbilder an einem Dokument anzubringen. Dieser Artikel zeigt auf, wie Sie diese sogenannten Mehrfachvisualisierungen anlegen, ein entsprechendes Dokument signieren und prüfen. *** ** * ** *** ## 1. Grundsätzliches Vorgehen bei einer Mehrfachvisualisierung Im Grunde gehen Sie bei der Erstellung eines Dokuments mit **Mehrfachvisualisierung** so vor wie bei der Erstellung eines regulären Auftrags. Sie laden das entsprechende Dokument hoch, definieren die Entscheidungsebenen und platzieren die Platzhalter. Die signierende Person unterschreibt durch **einmaliges Ausführen** des **Signaturvorgangs**. ### 1.1. Details zum Anlegen eines Auftrags mit Mehrfachvisualisierungen Wie bereits erwähnt, legt man bei einer Mehrfachvisualisierung zunächst wie gewohnt [einen Auftrag](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-auftrage-anlegen.md) an. Doch statt einem Platzhalter fügt man dem Dokument mehrere bei, indem man immer wieder den gleichen Platzhalter auf das Dokument zieht. Das bedeutet, pro Signierendem oder Signierender können mehrere Platzhalter auf das Dokument gezogen werden. So können zum Beispiel drei Personen ein Dokument an drei verschiedenen Stellen unterzeichnen. Damit die Signierenden den Signaturvorgang nur einmal durchführen müssen, wird ihnen jeweils ein individueller Platzhalter zugewiesen, der drei Mal auf dem Dokument verteilt wird. Um den Vorgang so einfach als möglich zu visualisieren, haben wir unser Beispiel auf eine Person reduziert, die ein Dokument drei Mal unterschreiben soll. Daher fügen wir unserem Beispiel unten drei Platzhalter für die Signatur einer Person hinzu (siehe *Abbildung 1 \[2\]* ). Nach erfolgter Platzierung der gewünschten Anzahl an Platzhaltern sehen Sie die Anzahl der Platzhalter pro Entscheidungsebene im rechten Seitenmenü (siehe *Abbildung 1 \[1\]*). Im linken Seitenmenü ist weiterhin die Auftragsanlegemaske geöffnet und Sie können den Auftrag in den Unterschriftenlauf senden. ![01_Mehrfachvisualisierung.png](https://documentation.moxis.co/__attachments/a_7e3a02b2b4c83c89ed093aedf84665e170717cb68dd36292f2d492e781290ea4/01_Mehrfachvisualisierung.png?cb=48d14b6328fb8142dce96eae0e061cca) *Abbildung 1: Mehrfachvisualisierung in MOXIS* *- vereinfachte Darstellung* ### 1.2. Signieren eines Dokuments mit Mehrfachvisualisierungen Die Person(en), die das Dokument „mehrfach" signieren soll(en), signiert oder signieren dieses wie gewohnt. Denn der oder die Empfänger:in muss den Signaturvorgang lediglich einmal ausführen, auch wenn sich mehrere Visualisierungen und Signaturen auf dem Dokument befinden. ### 1.3. Darstellung der Mehrfachvisualisierung im Auftrag In unserem Beispiel (siehe*Abbildung 2* ) wird ein dreiseitiges Dokument durch eine einfache Signatur zur Weiterverarbeitung frei gegeben. Dabei muss jede Seite von dieser ersten Entscheidungsebene paraphiert werden (siehe in blau gehalten *Abbildung 2, "Erste Unterschrift"*). Im nächsten Schritt werden die Dokumente im selben Auftrag in der zweiten Entscheidungsebene an externe Empfänger:innen versendet. Diese unterfertigen die Dokumente mit einer qualifizierten Unterschrift (siehe in grün gehalten *Abbildung 2, "Zweite Unterschrift"*) - jeweils auf Seite eins, zwei und drei. Schließlich werden die Dokumente wieder retourniert und nach Prüfung von internen Entscheider:innen qualifiziert unterschrieben (siehe in orange gehalten *Abbildung 2, "Dritte Unterschrift"*). Dies ebenfalls in allen drei Seiten in derselben Entscheidungsebene. Es wird folglich nur mehr drei Mal unterschrieben (SES, externe QSig und interne QSig) und die zusätzlichen Visualisierungen, die in Bezug zur jeweiligen Signatur stehen, werden lediglich als Bildmarke angebracht. ![01a_Mehrfachvisualisierung neu(1).png](https://documentation.moxis.co/__attachments/a_b54ac8f6539f676119eed68acc968395aa4edac0f5aca35178149edcd802311a/01a_Mehrfachvisualisierung%20neu(1).png?cb=e37384557835b344406b93bb217ca18f) *Abbildung 2: Ansicht von Mehrfachvisualisierungen im Adobe Acrobate Reader* --- version: "[4.55]" language: "de" --- # Persönliche Einstellungen * [Persönliche Einstellungen Menü](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-personliche-einstellungen-ubersicht.md) Die persönlichen Einstellungen in MOXIS enthalten einerseits die Möglichkeit, das eigene Konto zu bearbeiten und andererseits (je nach durch die von Ihrer Adminstratorin oder Ihrem Administrator an Sie vergebenen Rechten) die Möglichkeit, verschiedene Features in MOXIS zu nutzen. Wir gehen in unserem Beispiel davon aus, dass Sie alle Rechte innehaben. Dieser Artikel gibt Ihnen einen Überblick über die Bearbeitungsmöglichkeiten, die Sie in den persönlichen Einstellungen haben. Weiterführende Links erlauben es Ihnen gegebenenfalls tiefer in das Thema einzutauchen. * [Kontoeinstellungen: Der Konto-Tab](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-kontoeinstellungen.md) Hier haben Sie die Möglichkeit, Ihre Kontoeinstellungen zu ändern. Dieser Artikel zeigt auf, wie. * [Signaturtyp (vormals Unterschriftentyp)](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-signaturtyp-vormals-unterschriftentyp.md) Dieses Kapitel bietet Ihnen eine Übersicht über die Signaturtypen, die Ihnen in MOXIS zur Verfügung stehen und wie Sie diese einrichten. * [Erweiterte Sicherheit](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/erweiterte-sicherheit.md) Um die Fortgeschrittene Signatur (FES) als interne signierende Person verwenden zu können, müssen Sie einmalig einen zweiten Faktor in ihren persönlichen Einstellungen einrichten. Dieser Artikel erklärt Schritt für Schritt, wie das geht. * [Profile für Qualifizierte Signatur Übersicht](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-profile-fur-qualifizierte-signatur-ubersicht.md) In diesem Kapitel finden Sie wissenswerte Informationen rund um Signaturprofile für Qualifizierte Signaturen * [Profile für Einfache Signatur einrichten](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-profile-fur-einfache-signatur-ubersicht.md) * [Benachrichtigungen konfigurieren](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-benachrichtigungen.md) MOXIS bietet Ihnen in den Benutzereinstellungen die Möglichkeit, prozessabhängige und regelmäßige E-Mail-Benachrichtigungen individuell zu konfigurieren. Dieser Artikel informiert Sie über die Grundlagen. * [Vertreter:innen bearbeiten](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-vertretung.md) Dank der Vertreterfunktion können Sie sowohl für die qualifizierte Signatur als auch für die Freigabe Stellvertreter:innen für ausgewählte Zeiträume hinterlegen. Dieser Artikel zeigt auf, wie Sie dabei am Besten vorgehen. * [OPTIONAL: Einsichtnehmer:innen bearbeiten](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-einsichtnehmer-innen-optional.md) In den MOXIS-Einstellungen können Benutzer:innen unter dem Menüpunkt Einsichtnehmer bearbeiten anderen MOXIS-User:innen Einsicht in Unterschriften- oder Freigabeprozesse gewähren. Dieser Artikel bringt Ihnen das Thema näher. * [Adressbuch](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/adressbuch.md) In MOXIS unterscheiden wir zwischen zwei Typen von Adressbüchern: das persönliche und das globale. Während das persönliche nur von Ihnen selbst (also von den jeweilig angemeldeten Benutzer:innen) einsehbar ist, kann das globale je nach Konfiguration von allen Benutzer:innen Ihrer Abteilung oder Ihrer Firma aufgerufen werden. Im Folgenden werden beide Optionen beschrieben, jedoch gilt: während das persönliche Adressbuch zum Standard gehört, ist das globale optional konfigurierbar. * [Vorlagen verwalten](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-vorlagen.md) Im Menü Vorlagen verwalten haben Sie die Möglichkeit, Ihre selbst erstellten Vorlagen zu verwalten. Dieser Artikel bringt Ihnen die Thematik näher. * [OPTIONAL: Platzhaltergenerator Übersicht](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-platzhaltergenerator-ubersicht-optional.md) In diesem Kapitel finden Sie wissenswerte Informationen rund um das Thema Platzhalter. --- version: "[4.55]" language: "de" --- # Persönliche Einstellungen Menü **Inhalt** Die persönlichen Einstellungen in MOXIS enthalten einerseits die Möglichkeit, das eigene Konto zu bearbeiten und andererseits (je nach durch die von Ihrer Adminstratorin oder Ihrem Administrator an Sie vergebenen Rechten) die Möglichkeit, verschiedene Features in MOXIS zu nutzen. Wir gehen in unserem Beispiel davon aus, dass Sie alle Rechte innehaben. Dieser Artikel gibt Ihnen einen Überblick über die Bearbeitungsmöglichkeiten, die Sie in den persönlichen Einstellungen haben. Weiterführende Links erlauben es Ihnen gegebenenfalls tiefer in das Thema einzutauchen. *** ** * ** *** ## 1. Persönliche Einstellungen Übersicht ### 1.1. Persönliche Einstellungen öffnen Um die persönlichen Einstellungen zu öffnen, klicken Sie bitte auf das Benutzer-Icon in der rechten oberen Ecke (siehe *Abbildung 1 \[1\]* ). Dann klicken Sie bitte auf den Benutzer (siehe *Abbildung 1 \[2\]*). ![01_Übersicht.png](https://documentation.moxis.co/__attachments/a_a4f762647d8f89c0a37779ea5cd4a3816eb5a410613c9ec6f139c5668f8e572f/01_%C3%9Cbersicht.png?cb=c9d2101f7dec5c618723f74874939f5e) *Abbildung 1: Persönliche Einstellungen Übersicht* Auf der linken Seite öffnet sich nun ein Menü. Sie werden feststellen, dass Sie manche der Menüpunkte sowohl über die linke Übersicht, als auch das Menü auf der rechten Seite öffnen können (siehe Abbildung *1 \[3 - 5\], jeweils rechts und links*). Dabei handelt es sich um Punkte, die naturgemäß am meisten gebraucht werden. Entsprechend müssen Sie dann nicht die Einstellungen öffnen, sondern es reicht ein Klick auf den Menüpunkt Ihrer Wahl im Benutzermenü. **MOXIS Tipp** **Bitte beachten Sie:** Die auf der rechten Seite sichtbaren Punkte sind abhängig von den an Sie vergebenen Rollen. Sie sehen die Ansicht ist in ihrer vollen Ausprägung. ### 1.2. Persönliche Einstellungen Übersicht Im folgenden finden Sie eine kurze Beschreibung über Ihre Möglichkeiten in den persönlichen Einstellungen (siehe *Abbildung 2 \[1\]-\[12\]*). **MOXIS Tipp** **Bitte beachten Sie:**Die Persönlichen Einstellungen sind abhängig von der Konfiguration Ihrer MOXIS Instanz. Das heißt, es können, müssen aber nicht alle Reiter der folgenden Übersicht in Ihrer Instanz verfügbar sein. **(1) Konto:** Hier haben Sie die Möglichkeit, Ihre Kontoeinstellungen zu ändern (für weitere Informationen klicken Sie bitte [hier](https://xitrust-public.atlassian.net/wiki/pages/createpage.action?spaceKey=pkb&title=%28v4.53-de%29%20%5B4.52%5D%20Konto-Tab&linkCreation=true&fromPageId=107643848)). **(2) Signaturtyp:** Unter dem Reiter Signaturtyp haben Sie die Möglichkeit, diverse Einstellungen Ihrer bevorzugten Trust-Center zu hinterlegen (für weitere Informationen klicken Sie bitte [hier](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-signaturtyp-vormals-unterschriftentyp.md)). **(3) Erweiterte Sicherheit:** Dieser Punkt erlaubt es Ihnen, einen zweiten Faktor für die Fortgeschrittene Signatur zu definieren. **(4) Profile für Qualifizierte Signatur:** Hier haben Sie die Möglichkeit, [Profile für Qualifizierte Signaturen anzulegen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-profile-fur-qualifizierte-signaturen-erstelle.md) und [Regeln zu definieren](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-regeln-fur-profile-bearbeiten-und-reihen.md). Das spart Zeit und optimiert Ihre Vorgänge. **(5) Profile für Einfache Signatur:** Hier haben Sie die Möglichkeit, Profile für Einfache Signaturen anzulegen. Das spart Zeit und optimiert Ihre Vorgänge (für weitere Informationen klicken Sie bitte [hier](https://xitrust-public.atlassian.net/wiki/spaces/PKB/pages/108200700)). **(6) Benachrichtigungen:** Unter dem Reiter Benachrichtigungen definieren Sie die Benachrichtigungseinstellungen für Ihre Prozesse und allgemeine Einstellungen für Benachrichtigungen (für weitere Informationen klicken Sie bitte [hier](https://xitrust-public.atlassian.net/wiki/pages/createpage.action?spaceKey=pkb&title=%28v4.53-de%29%20%5B4.52%5D%20Benachrichtigungen%20konfigurieren&linkCreation=true&fromPageId=107643848)). **(7) Vertreter bearbeiten:** Hier legen Sie eine Vertretung fest und bestimmen über die Benachrichtigungen, welche die Vertretung erhält (für weitere Informationen klicken Sie bitte [hier](https://xitrust-public.atlassian.net/wiki/pages/createpage.action?spaceKey=pkb&title=%28v4.53-de%29%20%5B4.52%5D%20Vertreter%3Ainnen%20bearbeiten&linkCreation=true&fromPageId=107643848)). **(8) Einsichtnehmer bearbeiten:** Unter dem Reiter fügen Sie eine:n Einsichtnehmer:in hinzu (für weitere Informationen klicken Sie bitte [hier](https://xitrust-public.atlassian.net/wiki/pages/createpage.action?spaceKey=pkb&title=%28v4.53-de%29%20%5B4.52%5D%20Einsichtnehmer%3Ainnen%20bearbeiten%20%28optional%29&linkCreation=true&fromPageId=107643848)). **(9) Adressbuch:** Hier finden Sie die Adressbücher für externe Benutzer und Gruppen (für weitere Informationen klicken Sie bitte [hier](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/v4-52-die-adressbucher.md)). **(10) Vorlagen verwalten:** Der Tab erlaubt es Ihnen, eigene oder von anderen geteilte Vorlagen zu verwalten (für weitere Informationen klicken Sie bitte [hier](https://xitrust-public.atlassian.net/wiki/pages/createpage.action?spaceKey=pkb&title=%28v4.53-de%29%20%5B4.52%5D%20Vorlagen%20verwalten&linkCreation=true&fromPageId=107643848)). **(11) Platzhalter generieren:** Unter dem Reiter generieren Sie entweder einen Gruppenplatzhalter oder einen persönlichen Platzhalter (für weitere Informationen klicken Sie bitte [hier](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-einfuhrung-platzhaltergenerator-optional.md)). **(12) MCP Einstellungen:** Hier können Sie Ihre persönlichen Einstellungen für den MOXIS AI Connector bearbeiten. **(13) Persönliche Verschlüsselung:** Hier haben Sie die Möglichkeit, einen persönlichen Schlüssel zu erzeugen, der über ein Passwort geschützt ist. **(14) Über MOXIS:** Dieser Menüpunkt versorgt Sie mit Informationen über MOXIS, wie zum Beispiel die laufende Versionsnummer. ![02_Einstellungen_Unterpunkte.png](https://documentation.moxis.co/__attachments/a_627041a4de4266b87c3548cd7df9a689d04a399197afc7a809dc38ad4b86500c/02_Einstellungen_Unterpunkte.png?cb=1efd697a16d13ee700b3ecca5a525b96) *Abbildung 2: Übersicht über die Benutzereinstellungen in MOXIS* --- version: "[4.55]" language: "de" --- # Platzhalter Einschränkungen **Inhalt** Platzhalter können gewissen Einschränkungen unterliegen. Dieser Artikel informiert Sie über die potentielle Möglichkeiten hinsichtlich dieser. *** ** * ** *** Werden Platzhalter in Dokumenten angewendet, muss beachtet werden, dass die Signaturqualität innerhalb einer Entscheidungsebene dieselbe ist (z. B. Freigaben in Entscheidungsebene 1, Qualifizierte Unterschriften in Entscheidungsebene 2 etc.). **MOXIS Tipp** Platzhalter funktionieren nur in der Instanz, in der sie generiert wurden! Werden Platzhalter mit unterschiedlichen Signaturqualitäten (siehe *Abbildung 1* ) innerhalb derselben Entscheidungsebene eingefügt, kann das Dokument nicht hochgeladen werden und eine Fehlermeldung wird angezeigt (siehe *Abbildung 2*). ![06a_Platzhalter Einschränkungen.png](https://documentation.moxis.co/__attachments/a_d870a2d90528b9c92ea1ea1a8d3aa0f168a6657d62aac7982b8101d0d81a8a0d/06a_Platzhalter%20Einschr%C3%A4nkungen.png?cb=1bced49117ac2468610f0f574d9214ed) *Abbildung 1: Platzhalter auf Auftrag mit unterschiedlichen Signaturqualitäten* ![07a_Platzhalter_Einschränkungen.png](https://documentation.moxis.co/__attachments/a_0a6f670353594fa3401806e69d5de843bdbe06cb73cf978b12280df1718dbd3a/07a_Platzhalter_Einschr%C3%A4nkungen.png?cb=a31f3ffa56819f5348c17702ef6e7b08) *Abbildung 2: Fehlermeldung ungültiger Platzhalter beim Hochladen eines Dokuments* --- version: "[4.55]" language: "de" --- # OPTIONAL: Platzhaltergenerator Übersicht In diesem Kapitel finden Sie wissenswerte Informationen rund um das Thema Platzhalter. * [OPTIONAL: Einführung Platzhaltergenerator](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-einfuhrung-platzhaltergenerator-optional.md) * [Platzhalter Einschränkungen](https://documentation.moxis.co/de/moxis-enterprise-user-guides/4.55/4-52-platzhalter-einschrankungen.md) --- version: "[4.55]" language: "de" --- # OPTIONAL: Private Entscheidungsebenen definieren **Inhalt** **MOXIS** bietet die Möglichkeit, **Entscheidungsebenen** als privat zu kennzeichnen. Dieser Artikel gibt Aufschluss über das Feature. *** ** * ** *** Um die Funktion zu nutzen, aktivieren Sie bitte die Checkbox der Ebene, die jeweils nur von den beteiligten Signierenden eingesehen werden soll (siehe *Abbildung 1 \[1\]*). **MOXIS Tipp** **Bitte beachten Sie:** Das "Privat" bezieht sich immer nur auf die jeweilige angehakte Entscheidungsebene. Diese Ebene sehen folgende Personenkreise: * Empfänger:innen des Auftrags * Auftraggeber:innen und deren Vertreter:innen Das Dokument kann jedoch NICHT von Vertreter:innen der Empfänger:innen eingesehen werden. ![07_Private_Entscheidungsebene.png](https://documentation.moxis.co/__attachments/a_4d0f9c41e76c9cc560a18cdf56aa7e8f710b5935a42623c36efe3daf8f4daa2a/07_Private_Entscheidungsebene.png?cb=cbf34692e9dfbe5f1560028d4da7560e) *Abbildung 1: Entscheidungsebenen in MOXIS als privat kennzeichnen* [Next Page](https://documentation.moxis.co/llms-full.txt/1)