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
sendEingaben 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
tasknur, nachdemsenderfolgreich war und eine Aufgaben-ID zurückgegeben hat. - Überwachen Sie für Send-Workflows
task.report.status, bis dieser den StatusCOMPLETEDoderFAILEDerreicht. - 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 idsend input.recipients must include a recipient with order 0, or order 1 when roleId is providedrecipients[0].email must be a valid emailrecipients[1].attachments[0] must be a base64-encoded attachment id
Häufige Validierungsprobleme
Fehlende erforderliche Top-Level-Felder
Diese Felder sind erforderlich:
groupIdtemplateIdtitlerecipients
Ungültige kodierte IDs
Der Validator prüft, dass IDs base64-kodiert sind und den erwarteten dekodierten Präfix haben:
groupId->grptemplateId->tplroleId->rolscheduleId->schexperience->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, wennroleIdangegeben 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:
emailmuss gültig sein und höchstens75Zeichen lang seinfirstNameundlastNamemüssen höchstens60Zeichen lang seinphoneNumberdarf höchstens120Zeichen enthaltenmessagedarf höchstens10000Zeichen enthaltenexpiryDatemuss ein gültiges ISO 8601-Datum odernullseinccEmailmuss eine gültige Email seinccIncludeLinkmuss ein Boolean sein
Grenzwerte für Top-Level-Felder
Gängige Send-Level-Validierungsregeln umfassen:
titledarf höchstens1028Zeichen enthaltentagdarf höchstens250Zeichen enthaltenpdfPassworddarf höchstens150Zeichen enthaltendocumentCCEmaildarf maximal10Email-Adressen enthaltenredirectmuss eine gültige URI odernullseinrecipientsdarf weniger als200Elemente enthaltensenderFieldsundparticipantFieldsdürfen jeweils weniger als1000Elemente 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,messageundskipWeekendenthalten - darf
whennur1,2oder3sein - dürfen
subjectundmessagehöchstens500Zeichen enthalten - muss jede Feldeingabe eine gültige Element-
identhalten
Empfohlener Debugging-Ablauf
- Validieren Sie Ihre Payload lokal mit dem Send Input JSON Schema.
- Führen Sie die Mutation aus.
- Wenn die Mutation einen Validierungsfehler zurückgibt, korrigieren Sie die Payload und versuchen Sie es erneut.
- 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.