Cómo un documento recorre las seis fases del PSB: de Submit a Delivered o Failed, con mensajes de estado, webhooks y política de reintentos.
Un documento enviado a través del PSB sigue una secuencia fija de fases de procesamiento — desde la presentación hasta la entrega confirmada o el fallo definitivo. En cada punto de transición, el PSB publica un mensaje de estado que puede recuperarse a través de la API de estado o capturarse mediante un webhook.
Submit → Validate → Transform → Route → Acknowledge → Delivered
↘ Failed
PendingValidated, *ReceivedError en caso de errorRoutedAcknowledged*Sent, *SentErrorPendingValidatedRoutedDeliveredRejectedFailed*SentError inmediato| Evento por intento | HookSentRetry |
| Evento tras fallo definitivo | HookSentError |
Los endpoints de Submit admiten idempotencia mediante la cabecera X-EConnect-DocumentId. Ante un envío duplicado, el PSB responde HTTP 409 Conflict. Así, los reintentos, por ejemplo tras un error de red, nunca se procesan dos veces. Consulte Idempotencia para la explicación completa.
Tiene dos opciones. A través de la API de estado (GET …/salesInvoice/{documentId}/status) recupera el estado actual. Para monitorización en tiempo real, configure webhooks en los topics relevantes como InvoiceSent, InvoiceSentRetry e InvoiceSentError.
El PSB reintenta la entrega automáticamente hasta 8 veces durante aproximadamente 3 días (72 horas). Tras el fallo definitivo, sigue {DocumentType}SentError y se requiere acción manual.
El PSB intenta entregar una notificación webhook hasta 12 veces, distribuidas a lo largo de aproximadamente 6 días (137 horas). Tras el fallo definitivo, sigue el evento HookSentError.
Ver la documentación API interactiva