Si estás implementando guías de remisión electrónicas (GRE 2.0) y recibes errores de autenticación una y otra vez, hay una posibilidad muy alta de que estés usando las credenciales equivocadas. No las mal escritas: las equivocadas.
Dos sistemas distintos, dos juegos de credenciales
Las facturas, boletas y notas de crédito viajan a SUNAT por SOAP, y se autentican con tu usuario y clave SOL. Eso es lo que casi todo el mundo conoce.
Las guías de remisión, en cambio, usan una API REST con OAuth2. Y OAuth2 no trabaja con usuario y contraseña: trabaja con un client_id y un client_secret que se emiten aparte.
| Tipo de comprobante | Protocolo | Autenticación |
|---|---|---|
| Factura, boleta, notas, retención, percepción | SOAP | Usuario + clave SOL |
| Guía de remisión (tipo 09) | REST | OAuth2: client_id + client_secret |
Esa tabla es toda la explicación. El problema es que nadie te la muestra antes de que pierdas medio día.
Dónde se obtienen realmente
El client_id y el client_secret no se generan automáticamente y no llegan por correo. Hay que ir a buscarlos:
- Ingresa a SUNAT Operaciones en Línea con tu clave SOL.
- Busca en el Menú SOL la opción de credenciales de API para el servicio de guías de remisión.
- Registra la aplicación y guarda las dos cadenas que te entrega.
El client_secret normalmente se muestra una sola vez. Si lo pierdes, hay que generar uno nuevo.
Por qué la confusión es tan común
Porque el nombre engaña. Uno asume que si ya tiene «las credenciales de SUNAT», sirven para todo lo de SUNAT. Y encima el error que devuelve la API no siempre dice «credencial inválida» de forma clara: a veces responde con un token rechazado, o con un 401 sin cuerpo, que se puede confundir con un problema de red o de configuración del endpoint.
Hay un segundo motivo más sutil. En el flujo OAuth2 tú primero pides un token y después envías la guía. Si las credenciales están mal, falla el primer paso, no el segundo. Así que el mensaje de error habla del token y no de la guía, y uno se pone a revisar el XML de la guía cuando el problema estaba antes.
Los ambientes también son distintos
Otro detalle que se pasa por alto: GRE tiene sus propios endpoints, que no son los de SOAP.
- Pruebas:
gre-beta.sunat.gob.pe - Producción:
api-cpe.sunat.gob.pe
Apuntar al endpoint de SOAP con credenciales de OAuth2, o al contrario, es otra fuente de errores que se ven como problemas de autenticación sin serlo.
Cómo verificar rápido si es tu caso
Antes de revisar tu código, responde esto: ¿la cadena que pusiste en client_id se parece a tu usuario SOL? Si es algo como MODDATOS o el nombre de un usuario secundario, ese es el problema. El client_id de OAuth2 es una cadena larga sin relación con tu usuario.
En ZMRFact las credenciales de GRE se guardan como campos separados de la clave SOL, precisamente para que no se confundan. Son dos cosas distintas y la interfaz lo refleja.