Saltar al contenido principal
El sandbox envía los comprobantes al ambiente de pruebas de la DGII: no tienen validez fiscal y no cuentan para tus límites mensuales.
Una llave de un ambiente se rechaza en el otro con 401. Mientras integras, usa solo la llave de prueba y la URL del sandbox.
1

Consigue tu llave de prueba

Pide a AC-PAY una llave acpay_test_... para tu comercio. Guárdala como un secreto de tu servidor (por ejemplo, en una variable de entorno), nunca en el código ni en una aplicación web o móvil.
Envíala en cada solicitud: Authorization: Bearer $ACPAY_TEST_KEY.
2

Revisa tus secuencias

Para emitir necesitas una secuencia de e-NCF vigente del tipo que vas a usar (usable: true).
3

Emite una factura

Cada POST lleva un Idempotency-Key único que generas tú (un UUID). Si la red falla, repites la solicitud con la misma llave y no se emite un segundo comprobante: ver Idempotencia.
La respuesta (201) trae el id del documento y casi siempre status: pending: ya se firmó y se envió a la DGII, que todavía no responde. Guarda el id.
4

Espera el resultado

El estado se actualiza solo, en segundo plano. Tienes dos formas de enterarte:
  • Webhook (recomendado): registra una URL HTTPS de tu servidor y recibes ecf.accepted o ecf.rejected. Ver Webhooks.
  • Consulta: GET /v1/invoices/{id} devuelve el estado actual (y lo actualiza al momento si sigue pending).
accepted o accepted_with_observations es un comprobante válido. rejected trae el motivo en statusMessage. Ver Estados de un e-CF.
5

Descarga el PDF y el XML

Pruébalo sin escribir código

En la pestaña Referencia de la API, cada endpoint tiene un panel para probarlo: pega tu llave de prueba, completa los campos y envía la solicitud al sandbox. Las solicitudes van directo de tu navegador al sandbox de AC-PAY, sin pasar por terceros.
En el panel de pruebas usa solo tu llave acpay_test_.... Nunca pegues una llave de producción en un sitio web.