La API es idéntica en ambos ambientes. Lo que cambia es el endpoint de DGI al
que el gateway envía (ePrueba vs producción) y las credenciales de la empresa.
Políticas
Que no haya rate limiting hoy no es una garantía de contrato: pymo puede agregarlo.
Un integrador robusto no debería asumir un límite ni depender de su ausencia.
Cómo no emitir en producción sin querer
Lo único que separa una prueba de un comprobante fiscal real es la URL base a la que llamás. No hay una bandera de “modo prueba”, ni un parámetro, ni una cabecera: mandar el mismo request agateway.pymo.uy en lugar de
gatewaytest.pymo.uy emite de verdad.
Vale la pena entender por qué eso importa más que en otras APIs. Un CFE
confirmado consume un número de CAE que no vuelve. No se puede borrar: lo
único que existe después es una nota de crédito o la anulación, que son
comprobantes nuevos y también quedan registrados ante DGI. Un error de ambiente
no se limpia, se compensa.
Recomendaciones concretas, en orden de cuánto protegen:
- La URL base va en configuración, nunca escrita en el código. Si un desarrollador puede cambiar de ambiente editando una constante, en algún momento se va a mergear la constante equivocada.
- Que producción sea explícita. Que el default de tu configuración sea
homologación y que producción haya que pedirla, no al revés. Un
.envfaltante debería dejarte en homologación, no en producción. - Credenciales separadas por ambiente. Las de homologación no deberían
funcionar en producción ni al revés; si en tu sistema son las mismas variables,
una copia de
.enventre entornos cambia de ambiente sin que nadie lo note. - Chequeá el ambiente en el arranque, no en el request. Loguear a qué host apunta el cliente al iniciar convierte un error de configuración en algo visible antes de la primera emisión.
- Reservá una serie o un rango de
clientEmissionIdpara pruebas. No impide el error, pero hace que se note enseguida al mirar los comprobantes emitidos.