Sandbox y producción
Un solo dominio, api.oden.tax, y una sola versión de la API. Lo que cambia entre
probar y facturar de verdad no es la dirección: es el sello con el que firmas.
El sello decide
En sandbox se firma con los CSD de prueba que el SAT publica, cuyo RFC es uno de los suyos:
EKU9003173C9 es el más usado. Cargar uno de ésos en un emisor lo deja timbrando
contra el ambiente de pruebas del PAC.
En producción se firma con el CSD real del contribuyente, el que descargó de su portal del SAT. Un CSD real contra el
ambiente de pruebas y un CSD de prueba contra producción devuelven los dos un rechazo: el PAC contesta
csd_not_from_sat en el segundo caso.
Los timbres
Un timbre se consume cuando el PAC certifica el comprobante. Un rechazo no lo gasta, y por eso vale la pena que lo que esté mal se rechace lo antes posible: antes de llegar al PAC validamos el XML contra el esquema del SAT, el uso del CFDI contra el régimen del receptor, y que la fecha del comprobante caiga dentro de las 72 horas.
Los del sandbox no se cobran. Es el lugar para probar los casos que dan miedo: una nota de crédito, una cancelación con motivo 01, una factura en dólares.
Todo es síncrono
No hay trabajos en segundo plano ni webhooks. POST /v1/invoices sostiene la petición
hasta que el PAC contesta y devuelve el comprobante timbrado, o el motivo por el que no. No existe un estado
"timbrando" que puedas encontrarte después: cuando la llamada regresa, la respuesta es definitiva.
Eso implica un timeout generoso de tu lado. Damos hasta 45 segundos al PAC; en la práctica contesta en dos o tres. Si tu cliente corta antes que nosotros, la factura pudo haberse timbrado sin que lo sepas, y para eso está la llave de idempotencia.