Saltar al contenido principal

Solucionar problemas de validación de envío

La canalización de envío valida su entrada antes de que comience la creación del documento. Si la validación falla, la mutación devuelve el error directamente al cliente y no se devuelve ningún ID de tarea.

Esto se aplica a:

Texto para tu IA​

Usa esto al solicitar a una herramienta de IA que ayude con los flujos de trabajo de envío de Legalesign GraphQL:

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.

Si la IA necesita una guía más completa, dirígela a esta página.

Resumen para IA​

  • Trata la entrada de send como JSON estricto con reglas de validación.
  • Si la entrada de send es inválida, la mutación retorna un error inmediatamente y no se devuelve ningún ID de tarea.
  • Solo realiza polling de task después de que send haya tenido éxito y devuelto un ID de tarea.
  • Para flujos de trabajo de envío, monitorea task.report.status hasta que alcance COMPLETED o FAILED.
  • Para UX en tiempo real en producción, prefiere suscripciones en lugar de polling.

Cómo detectar un fallo de validación​

Ejecuta la mutación como de costumbre.

  • Si la entrada es inválida, la mutación retorna un error de validación inmediatamente.
  • Si la entrada es válida, la mutación devuelve un ID de tarea y la creación del documento continúa de forma asincrónica.

Eso significa que la solución de problemas de validación ocurre en el momento de la mutación, no a través de la consulta task.

Solo comienza a hacer polling de task después de que send haya tenido éxito y devuelto un ID de tarea.

Qué tipo de errores puedes esperar​

El validador de envío verifica la forma y el contenido del JSON de entrada antes de continuar el procesamiento. Las fallas de validación son específicas del campo que falló, por ejemplo:

  • 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

Problemas comunes de validación​

Campos obligatorios de nivel superior faltantes​

Estos campos son obligatorios:

  • groupId
  • templateId
  • title
  • recipients

IDs codificados inválidos​

El validador verifica que los IDs estén codificados en base64 y tengan el prefijo decodificado esperado:

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

Problemas con el orden de los destinatarios​

La entrada de envío debe incluir un destinatario inicial:

  • ya sea un destinatario con order: 0
  • o un destinatario con order: 1 cuando se proporciona roleId

Además, el destinatario con el número de orden más bajo debe tener un email no vacío.

Límites de campos del destinatario​

Las reglas comunes de validación de destinatarios incluyen:

  • email debe ser válido y tener 75 caracteres o menos
  • firstName y lastName deben tener 60 caracteres o menos
  • phoneNumber debe tener 120 caracteres o menos
  • message debe tener 10000 caracteres o menos
  • expiryDate debe ser un datetime ISO 8601 válido o null
  • ccEmail debe ser un email válido
  • ccIncludeLink debe ser un booleano

Límites de campos de nivel superior​

Las reglas comunes de validación a nivel de envío incluyen:

  • title debe tener 1028 caracteres o menos
  • tag debe tener 250 caracteres o menos
  • pdfPassword debe tener 150 caracteres o menos
  • documentCCEmail debe contener como máximo 10 direcciones de correo electrónico
  • redirect debe ser un URI válido o null
  • recipients debe contener menos de 200 elementos
  • senderFields y participantFields deben contener menos de 1000 elementos cada uno

Payloads inválidos de schedule o campos​

Si defines en línea schedules o valores de campos de los destinatarios:

  • cada ítem de schedule debe incluir daysAfter, frequency, when, timeOfDay, subject, message y skipWeekend
  • when del schedule debe ser uno de 1, 2 o 3
  • subject y message del schedule deben tener 500 caracteres o menos
  • cada entrada de campo debe incluir un id de elemento válido

Flujo de depuración recomendado​

  1. Valida tu payload localmente con el Send Input JSON Schema.
  2. Ejecuta la mutación.
  3. Si la mutación devuelve un error de validación, corrige el payload y reintenta.
  4. Si la mutación devuelve un ID de tarea, comienza a hacer polling de task para monitorear la creación del documento.

Cuándo usar suscripciones en su lugar​

Hacer polling de task es adecuado para empezar, probar y hacer prototipos.

Para flujos de trabajo en producción, usa suscripciones para actualizaciones en tiempo real y considera el estado obtenido por polling como una herramienta de respaldo o prototipo.

Para guía específica de suscripciones para tareas, consulta Track Send Tasks with Subscriptions.

Relacionados​

Export This Article

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