XML, RIDE y correo
Los archivos de un comprobante autorizado y cómo le llegan a tu cliente.
Cuando el SRI autoriza un comprobante, tiene dos archivos:
| Archivo | Qué es | Endpoint |
|---|---|---|
| XML autorizado | La autorizacion del SRI con tu comprobante firmado adentro. Es el comprobante legal, idéntico al que descargas del portal del SRI. Un comprobante importado trae el XML tal como lo subiste: si llegó solo firmado y el SRI no lo confirmó, sigue solo firmado | GET …/{id}/xml |
| RIDE | La representación impresa en PDF, tamaño A4, con el código de barras de la clave de acceso | GET …/{id}/pdf |
curl https://api.fiscalbase.io/v1/ec/invoices/$ID/pdf \
-H "Authorization: Bearer $FISCALBASE_API_KEY" -o factura.pdfAntes de la autorización respondemos 409: un comprobante que el SRI no ha autorizado no tiene archivos que valgan. El RIDE se genera justo después de autorizar; si lo pides en ese instante, también responde 409 y basta con reintentar en unos segundos.
En Sandbox y Pruebas el RIDE lleva una marca de agua: sin validez tributaria.
El correo a tu cliente
En todos los ambientes, al autorizarse, enviamos un correo con el RIDE y el XML adjuntos a quien corresponde: el comprador, el proveedor o cada destinatario de la guía (a quien llega solo el RIDE, con su transportista, placa y unidades). Cada familia cuenta lo suyo: la factura, su total y su vencimiento; la nota de crédito, lo acreditado y el saldo de la factura; la retención, lo retenido por impuesto. El correo incluye un enlace al portal del receptor, donde tu cliente ve todos los comprobantes que le emitiste en Producción.
El correo del receptor es obligatorio: la factura, las notas, la retención, la liquidación y cada destinatario de una guía lo piden, y sin él respondemos 422 en buyer.email, supplier.email o recipients.0.email. La excepción es la factura a consumidor final, que no tiene a quién escribirle y no se envía. Los correos de Sandbox y Pruebas salen igual, con [Sandbox] o [Pruebas] en el asunto y un aviso de que no tienen validez tributaria: usa direcciones que puedas leer.
El correo sale con el nombre de tu emisor; si registraste reply_to_email, las respuestas de tu cliente llegan ahí y el correo lo muestra al pie, junto con tu footer_legend.
No tienes que hacer nada: es parte de emitir.
Saber si llegó
Cada comprobante dice cómo van sus correos. emails lista los de su revisión actual, uno por destinatario, y delivery_status resume el resultado que más pesa:
| Estado | Qué pasó |
|---|---|
sent | El proveedor de correo lo aceptó y aún no hay noticias |
delivered | Llegó al buzón |
opened | El correo del cliente cargó la imagen de seguimiento. Es una pista: algunos clientes la bloquean y otros abren solos |
bounced | No llegó. bounce_type dice permanent si la dirección no existe, o transient si el buzón estaba lleno o el servidor caído |
complained | Tu cliente lo marcó como spam |
El estado nunca retrocede: un aviso de entrega que llega tarde no desmarca un correo abierto, y un rebote pesa más que una apertura. Cada correo guarda además la primera hora de cada cosa (delivered_at, opened_at, bounced_at, complained_at). Sin un proveedor de correo de verdad detrás, como en el desarrollo local, el estado queda en sent.
En Receptores, email_bounced marca a quien tiene el correo rebotado para siempre o un reclamo por spam, y GET /v1/ec/recipients?email_bounced=true los lista.
Reenviar un comprobante
¿Tu cliente perdió el correo, o quieres enviarlo a contabilidad? Pídenos un envío:
curl -X POST https://api.fiscalbase.io/v1/ec/invoices/$ID/email \
-H "Authorization: Bearer $FISCALBASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "to": ["contabilidad@elsol.ec"] }'toadmite hasta 10 direcciones.- Sin
to, lo reenviamos a los destinatarios del comprobante, en cualquier ambiente.
Respondemos 202: el envío está encolado. Si reintentas un envío que falló a medias, quien ya lo recibió no lo recibe dos veces.