# WSAA de ARCA explicado: ticket de acceso y TRA

El WSAA es la puerta de entrada de todos los web services de ARCA (ex AFIP). Antes de pedir un CAE, consultar un padrón o informar un CAEA, alguien tiene que presentarle un ticket de acceso válido. Acá vemos cómo se arma ese ticket, qué prueba y qué no, y qué parte te ahorrás cuando facturás por la API de YoFacturo.

## Qué es el WSAA y por qué existe

WSAA significa Web Service de Autenticación y Autorización. Es el servicio de ARCA que le entrega un **ticket de acceso** (TA) a quien demuestra tener un certificado digital válido. Ese ticket es la credencial que después se adjunta en cada llamada a los demás web services: el de facturación electrónica (WSFEv1), los de padrón, el de exportación, etc. Ningún web service de ARCA acepta un pedido sin un ticket vigente para ese servicio.

La idea es la misma que un token de sesión, con una diferencia importante: el ticket no se obtiene con usuario y contraseña, sino firmando un pedido con la clave privada de un certificado que ARCA reconoce.

## El circuito completo en cuatro pasos

1. **Armar el TRA.** El TRA es el Ticket de Requerimiento de Acceso, un XML llamado `loginTicketRequest`. Lleva un `uniqueId`, un `generationTime`, un `expirationTime` y el nombre del servicio para el que pedís el ticket (por ejemplo `wsfe`). En YoFacturo el `generationTime` se fija diez minutos en el pasado, para absorber diferencias de reloj, y la vigencia pedida es de 12 horas.
2. **Firmarlo.** El TRA se firma con el certificado y la clave privada, en formato CMS, y el resultado se codifica en base64.
3. **Llamar a `loginCms`.** Ese base64 viaja al WSAA en la operación `loginCms`.
4. **Recibir el ticket.** La respuesta trae un `Token`, un `Sign` y la fecha de vencimiento. Con eso ya podés llamar al servicio pedido.

En las llamadas posteriores, por ejemplo a WSFEv1, el `Token` y el `Sign` viajan dentro del bloque de autenticación junto con el CUIT en cuyo nombre se opera. Ese último dato es clave: lo decide el pedido a WSFEv1, no el ticket.

## Qué prueba el ticket y qué no

El TRA no lleva ningún CUIT de destino. El ticket se emite al CUIT del **certificado que firma**, y sirve para operar en nombre de cualquier CUIT que haya delegado ese servicio a esa identidad. Por eso un ticket válido, por sí solo, **no demuestra que un contribuyente haya delegado el servicio**. Solo una llamada real al web service con el CUIT del contribuyente lo demuestra.

Es una confusión frecuente: alguien obtiene un ticket sin errores, lo toma como prueba de que todo está bien configurado y recién al emitir el primer comprobante aparece el rechazo por falta de relación. Si querés entender cómo se prueba una delegación de verdad, mirá la guía de [delegación del web service de facturación](https://yo-facturo.com/dev/arca/delegar-web-service-facturacion/).

## URLs de producción y homologación

| Ambiente | Endpoint de `loginCms` | Web service de facturación |
| --- | --- | --- |
| Producción | `https://wsaa.afip.gov.ar/ws/services/LoginCms` | `https://servicios1.afip.gov.ar/wsfev1/service.asmx` |
| Homologación | `https://wsaahomo.afip.gov.ar/ws/services/LoginCms` | `https://wswhomo.afip.gov.ar/wsfev1/service.asmx` |

Los dos ambientes son independientes. El certificado de homologación lo emite ARCA por separado del de producción, y el WSAA de homologación rechaza el certificado de producción. Hay más detalle en la guía de [homologación vs producción](https://yo-facturo.com/dev/arca/homologacion-vs-produccion/).

## Cuánto dura el ticket y cómo se reutiliza

El ticket dura unas 12 horas. Pedir uno nuevo por cada request sería lento y desperdiciaría un servicio compartido, así que lo correcto es guardarlo y reutilizarlo hasta que venza. YoFacturo lo hace así: el ticket se cachea y lo comparten todos los procesos y todos los clientes de la plataforma hasta su vencimiento. Cuando hace falta, se fuerza la emisión de un ticket genuinamente nuevo.

Que el ticket sea compartido tiene una consecuencia práctica: no existe un "ticket por cliente" para facturar. El firmante es siempre la identidad de la plataforma, y lo que cambia de un cliente a otro es el CUIT que se indica en cada llamada a WSFEv1.

## Errores típicos del WSAA y cómo leerlos

- **`600` `ValidacionDeToken`.** El certificado activo firmó con una identidad que ARCA no reconoce para ese CUIT. Puede ser que el certificado ya no represente a ese CUIT, o que la delegación no esté aceptada todavía.
- **"lista de relaciones".** El mensaje aparece cuando el WSAA autenticó bien pero el CUIT del contribuyente no figura entre las relaciones que ARCA reconoce para el certificado. Casi siempre es una delegación mal hecha o que todavía no se propagó.
- **"Computador no autorizado a acceder al servicio".** Es el rechazo de un servicio puntual, por ejemplo uno de los padrones, para el que no hay delegación. Los servicios se delegan de a uno.
- **Certificado de otro ambiente.** Firmar con el certificado de producción contra el WSAA de homologación, o al revés, falla siempre.

## Qué hace YoFacturo por vos

Si facturás con la API de YoFacturo no escribís una sola línea de WSAA. La plataforma arma el TRA, lo firma con su certificado, guarda el ticket y lo renueva. Vos hacés dos cosas: delegar el servicio una única vez en ARCA y llamar a los endpoints de comprobantes.

Para comprobar que la cadena completa funciona, podés llamar a `POST /bill/tax_info/verify-delegation/` con el CUIT a verificar. Hace una consulta real de solo lectura a WSFEv1 y devuelve `delegation_verified` en `true`, `false` o `null`. El `null` significa que ARCA no contestó en ese momento: no confirma ni desmiente nada y no apaga una delegación que ya estaba verificada. El endpoint requiere el scope `accounting:write`, y sus rutas son relativas a `https://api.yo-facturo.com/api/v1`.

Si estás evaluando el producto, la visión general está en la página de la [API de facturación electrónica](https://yo-facturo.com/api-facturacion/), y el detalle de cada operación en la referencia de la API.

## Seguí leyendo

- [Certificado digital para web services de ARCA](https://yo-facturo.com/dev/arca/certificado-web-service/)
- [Cómo delegar el web service de facturación](https://yo-facturo.com/dev/arca/delegar-web-service-facturacion/)
- [API de facturación electrónica de YoFacturo](https://yo-facturo.com/api-facturacion/)

Fuente: https://yo-facturo.com/dev/arca/wsaa-explicado/