Zum Hauptinhalt springen

Fehlerbehebung bei der Send-Validierung

Die Sendepipeline validiert ihre Eingabe, bevor die Dokumenterstellung beginnt. Wenn die Validierung fehlschlägt, gibt die Mutation den Fehler direkt an den Client zurück und es wird keine Aufgaben-ID zurückgegeben.

Dies gilt für:

Text für Ihre KI

Verwenden Sie dies, wenn Sie ein KI-Tool auffordern, bei Legalesign GraphQL-Send-Workflows zu helfen:

Use the Legalesign GraphQL send validation rules below as the source of truth.

- Treat send input as strictly validated JSON.
- If send input is invalid, the mutation returns an error immediately and no task ID is returned.
- Only poll task after send succeeds and returns a task ID.
- For send workflows, monitor task.report.status until it reaches COMPLETED or FAILED.
- Prefer subscriptions over polling for production real-time UX.
- groupId, templateId, title, and recipients are required.
- Base64 IDs must decode to the expected prefixes:
groupId=grp, templateId=tpl, roleId=rol, scheduleId=sch, experience=exp, field id=ele, attachment id=att.
- recipients must contain fewer than 200 items.
- Each recipient must include email and order.
- The input must include an initial recipient: either order 0, or order 1 when roleId is provided.
- The recipient with the lowest order number must have a non-empty email.
- title must be 1028 characters or fewer.
- tag must be 250 characters or fewer.
- pdfPassword must be 150 characters or fewer.
- documentCCEmail must contain 10 email addresses or fewer.
- redirect must be a valid URI or null.

Wenn die KI umfassendere Anleitungen benötigt, verweisen Sie sie auf diese Seite.

KI-Zusammenfassung

  • Behandeln Sie send Eingaben als striktes JSON mit Validierungsregeln.
  • Wenn die send-Eingabe ungültig ist, gibt die Mutation sofort einen Fehler zurück und es wird keine Aufgaben-ID zurückgegeben.
  • Abfragen Sie task nur, nachdem send erfolgreich war und eine Aufgaben-ID zurückgegeben hat.
  • Überwachen Sie für Send-Workflows task.report.status, bis dieser den Status COMPLETED oder FAILED erreicht.
  • Für den produktiven Echtzeit-UX-Einsatz sind Subscriptions Polling vorzuziehen.

Wie man eine Validierungsfehlfunktion erkennt

Führen Sie die Mutation wie gewohnt aus.

  • Wenn die Eingabe ungültig ist, gibt die Mutation sofort einen Validierungsfehler zurück.
  • Wenn die Eingabe gültig ist, gibt die Mutation eine Aufgaben-ID zurück und die Dokumenterstellung läuft asynchron weiter.

Das bedeutet, die Fehlerbehebung bei der Validierung erfolgt zur Mutation-Zeit, nicht über die task Abfrage.

Beginnen Sie erst, task abzufragen, nachdem send erfolgreich war und eine Aufgaben-ID zurückgegeben hat.

Welche Art von Fehlern Sie erwarten können

Der Send-Validator überprüft die Form und den Inhalt des Eingabe-JSONs, bevor die Verarbeitung fortgesetzt wird. Validierungsfehler beziehen sich spezifisch auf das jeweilige fehlerhafte Feld, zum Beispiel:

  • send input missing required field 'groupId'
  • send input.groupId must be a base64-encoded group id
  • send input.recipients must include a recipient with order 0, or order 1 when roleId is provided
  • recipients[0].email must be a valid email
  • recipients[1].attachments[0] must be a base64-encoded attachment id

Häufige Validierungsprobleme

Fehlende erforderliche Top-Level-Felder

Diese Felder sind erforderlich:

  • groupId
  • templateId
  • title
  • recipients

Ungültige kodierte IDs

Der Validator prüft, dass IDs base64-kodiert sind und den erwarteten dekodierten Präfix haben:

  • groupId -> grp
  • templateId -> tpl
  • roleId -> rol
  • scheduleId -> sch
  • experience -> exp
  • Feld id -> ele
  • Anhang id -> att

Probleme mit der Reihenfolge der Empfänger

Die send-Eingabe muss einen initialen Empfänger enthalten:

  • entweder einen Empfänger mit order: 0
  • oder einen Empfänger mit order: 1, wenn roleId angegeben ist

Außerdem muss der Empfänger mit der niedrigsten Ordnungsnummer eine nicht-leere email haben.

Grenzwerte für Empfängerfelder

Gängige Validierungsregeln für Empfänger umfassen:

  • email muss gültig sein und höchstens 75 Zeichen lang sein
  • firstName und lastName müssen höchstens 60 Zeichen lang sein
  • phoneNumber darf höchstens 120 Zeichen enthalten
  • message darf höchstens 10000 Zeichen enthalten
  • expiryDate muss ein gültiges ISO 8601-Datum oder null sein
  • ccEmail muss eine gültige Email sein
  • ccIncludeLink muss ein Boolean sein

Grenzwerte für Top-Level-Felder

Gängige Send-Level-Validierungsregeln umfassen:

  • title darf höchstens 1028 Zeichen enthalten
  • tag darf höchstens 250 Zeichen enthalten
  • pdfPassword darf höchstens 150 Zeichen enthalten
  • documentCCEmail darf maximal 10 Email-Adressen enthalten
  • redirect muss eine gültige URI oder null sein
  • recipients darf weniger als 200 Elemente enthalten
  • senderFields und participantFields dürfen jeweils weniger als 1000 Elemente enthalten

Ungültige Schedule- oder Feld-Payloads

Wenn Sie Empfängerpläne oder Feldwerte inline angeben:

  • muss jedes Plan-Element daysAfter, frequency, when, timeOfDay, subject, message und skipWeekend enthalten
  • darf when nur 1, 2 oder 3 sein
  • dürfen subject und message höchstens 500 Zeichen enthalten
  • muss jede Feldeingabe eine gültige Element-id enthalten

Empfohlener Debugging-Ablauf

  1. Validieren Sie Ihre Payload lokal mit dem Send Input JSON Schema.
  2. Führen Sie die Mutation aus.
  3. Wenn die Mutation einen Validierungsfehler zurückgibt, korrigieren Sie die Payload und versuchen Sie es erneut.
  4. Wenn die Mutation eine Aufgaben-ID zurückgibt, beginnen Sie mit dem Abfragen von task, um die Dokumenterstellung zu überwachen.

Wann man stattdessen Subscriptions verwenden sollte

Das Abfragen von task ist gut geeignet, um zu starten, zu testen und zu prototypisieren.

Für produktive Workflows verwenden Sie Subscriptions für Echtzeit-Updates und behandeln polled Task-Status als Fallback oder für Prototypen.

Für task-spezifische Subscription-Anleitungen siehe Track Send Tasks with Subscriptions.

Verwandte Inhalte