# Ambientes y URLs base

> Homologación y producción, y qué cambia entre ellas

| Ambiente | URL base | Uso |
|---|---|---|
| Homologación | `https://gatewaytest.pymo.uy` | Integración y pruebas - emite contra la ePrueba de DGI |
| Producción | `https://gateway.pymo.uy` | Comprobantes fiscales reales |

<Info>
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.
</Info>

## Políticas

| Tema | Valor |
|---|---|
| Autenticación | Sesión por cookie vía `POST /v1/login` - ver [Autenticación](/autenticacion) |
| Duración de sesión | **1 hora** desde el login |
| Rate limiting | **No hay** rate limiting |
| Timeout del cliente | La API no fija un timeout. La respuesta de emisión es rápida porque el envío a DGI es asíncrono (ver [Emisión](/emision)); igual conviene un timeout de cliente generoso |
| CORS | Habilitado con credenciales, sólo para una lista de orígenes permitidos |
| Formato de fechas | ISO 8601 (`2026-08-03T00:00:00-03:00`) |

<Note>
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.
</Note>

## 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 a `gateway.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:

1. **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.
2. **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 `.env`
   faltante debería dejarte en homologación, no en producción.
3. **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 `.env` entre entornos cambia de ambiente sin que nadie lo note.
4. **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.
5. **Reservá una serie o un rango de `clientEmissionId` para pruebas.** No impide
   el error, pero hace que se note enseguida al mirar los comprobantes emitidos.

<Warning>
El gateway **no** te va a avisar. Un request bien formado a producción es
indistinguible, del lado de la API, de uno de prueba: responde `SUCCESS` igual.
La única confirmación de que estabas en el ambiente que creías es la URL que
usaste.
</Warning>