Vai al contenuto principale

Risolvi Problemi di Validazione Invia

La pipeline di invio convalida il suo input prima che inizi la creazione del documento. Se la validazione fallisce, la mutation restituisce immediatamente l'errore al client e non viene restituito alcun ID attività.

Questo vale per:

Testo Per La Tua AI​

Usa questo quando chiedi a uno strumento AI di aiutarti con i flussi di lavoro Legalesign GraphQL di invio:

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.

Se l’AI necessita di una guida più completa, indirizzala a questa pagina.

Sommario AI​

  • Tratta l’input di send come JSON rigoroso con regole di validazione.
  • Se l’input di send è invalido, la mutation restituisce subito un errore e non viene restituito alcun ID attività.
  • Esegui il polling di task solo dopo che send ha avuto successo e ha restituito un ID attività.
  • Per i flussi di invio, monitora task.report.status fino a quando non raggiunge COMPLETED o FAILED.
  • Per un'esperienza UX in tempo reale in produzione, preferisci le subscription al polling.

Come Rilevare un Fallimento di Validazione​

Esegui la mutation normalmente.

  • Se l’input è invalido, la mutation restituisce immediatamente un errore di validazione.
  • Se l’input è valido, la mutation restituisce un ID attività e la creazione del documento continua in modo asincrono.

Ciò significa che la risoluzione dei problemi di validazione avviene al momento della mutation, non tramite la query task.

Inizia il polling di task solo dopo che send ha avuto successo e ha restituito un ID attività.

Che Tipo di Errori Puoi Aspettarti​

Il validatore di invio controlla la forma e il contenuto del JSON di input prima che il processo continui. I fallimenti di validazione sono specifici per il campo che ha fallito, ad esempio:

  • 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

Problemi Comuni di Validazione​

Mancanza di campi obbligatori di livello superiore​

Questi campi sono obbligatori:

  • groupId
  • templateId
  • title
  • recipients

ID codificati non validi​

Il validatore controlla che gli ID siano codificati in base64 e abbiano il prefisso decodificato previsto:

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

Problemi di ordinamento destinatari​

L’input di invio deve includere un destinatario iniziale:

  • o un destinatario con order: 0
  • o un destinatario con order: 1 quando è fornito roleId

Inoltre, il destinatario con il numero d’ordine più basso deve avere un email non vuoto.

Limiti dei campi destinatario​

Le regole comuni di validazione destinatari includono:

  • email deve essere valida e con massimo 75 caratteri
  • firstName e lastName devono essere di massimo 60 caratteri
  • phoneNumber deve essere di massimo 120 caratteri
  • message deve essere di massimo 10000 caratteri
  • expiryDate deve essere una data-ora valida ISO 8601 o null
  • ccEmail deve essere una email valida
  • ccIncludeLink deve essere un booleano

Limiti dei campi di livello superiore​

Le regole comuni di validazione a livello di invio includono:

  • title deve essere di massimo 1028 caratteri
  • tag deve essere di massimo 250 caratteri
  • pdfPassword deve essere di massimo 150 caratteri
  • documentCCEmail deve contenere al massimo 10 indirizzi email
  • redirect deve essere un URI valido o null
  • recipients deve contenere meno di 200 elementi
  • senderFields e participantFields devono contenere ciascuno meno di 1000 elementi

Payload di schedule o campi non validi​

Se inserisci inline orari destinatari o valori di campo:

  • ogni elemento schedule deve includere daysAfter, frequency, when, timeOfDay, subject, message e skipWeekend
  • when dello schedule deve essere uno tra 1, 2 o 3
  • subject e message dello schedule devono essere di massimo 500 caratteri
  • ogni input di campo deve includere un id elemento valido

Flusso Consigliato per il Debug​

  1. Valida il tuo payload localmente con lo Schema JSON di Input Send.
  2. Esegui la mutation.
  3. Se la mutation restituisce un errore di validazione, correggi il payload e riprova.
  4. Se la mutation restituisce un ID attività, inizia il polling di task per monitorare la creazione del documento.

Quando Usare Invece le Subscription​

Il polling di task è utile per iniziare, testare e fare prototipi.

Per flussi di lavoro in produzione, usa le subscription per aggiornamenti in tempo reale e considera lo stato del task ottenuto dal polling come fallback o strumento di prototipo.

Per guide specifiche alle subscription per task, consulta Traccia i Task di Invio con Subscription.

Correlati​

Export This Article

Save a copy of this page as PDF or plain text.