Errores frecuentes

Esta es la página canónica de errores: cada error se explica una sola vez, acá. Las tablas de errores de los endpoints enlazan a la sección correspondiente.

Un 403 nunca significa "ARCA está caído", y un 502 nunca significa "tu certificado está mal". Si dudás, mirá el status: es la única señal que necesitás para saber de qué lado está el problema.

Buscá tu error

Si llegaste con un número —el status HTTP que devolvió la API, o el código que ARCA metió dentro del mensaje— empezá por acá.

Certificados y entornos

La mayoría de los errores que parecen "arca.api está roto" viven acá, y ninguno se arregla escribiendo código: se arreglan en el sitio de ARCA o en el dashboard.

El certificado no está autorizado en ARCA

Status: 403 · Error de ARCA: coe.notAuthorized, wsaa.LoginFault (a veces con el texto Computador no autorizado a acceder al servicio).

ARCA aceptó tu certificado, pero no lo tenés delegado al web service que estás llamando.

Cada operación de arca.api usa un web service de ARCA distinto:

Cómo resolverlo, en el sitio de ARCA (no en arca.api):

1. Entrá a arca.gob.ar con Clave Fiscal, con el CUIT dueño del certificado.
2. Abrí Administrador de Relaciones de Clave Fiscal.
3. Nueva Relación → Buscar el servicio de la tabla de arriba (por ejemplo, ws_sr_padron_a13).
4. En Representante, elegí el alias del certificado —el mismo que cargaste en la sección Certificados del dashboard, que es el CN del DN con el que generamos el CSR—, no una persona.
5. Confirmá y repetí el procedimiento por cada servicio que vayas a usar.

El mensaje de error de arca.api ya te nombra el servicio exacto que falta delegar y el entorno. Los cambios en ARCA impactan de inmediato: apenas delegás, el siguiente request funciona.

Mezclaste homologación y producción

Status: 403 · Error de ARCA: 600 (error al verificar el hash), Certificado no emitido por AC de confianza.

Los certificados de homologación (testing) y producción los emiten autoridades certificantes distintas y no son intercambiables. Este error significa que el certificado que subiste no fue emitido para el entorno contra el que estás llamando.

Casi siempre es una de estas dos:

• Subiste un certificado de homologación al CUIT de producción (o al revés).
• Estás mandando "environment": "produccion" en el request, pero el CUIT solo tiene cargado el certificado de homologación.

Cómo resolverlo: en el dashboard, sección Certificados, verificá que el CUIT tenga cargado el certificado del entorno que estás usando. En arca.api cada CUIT se registra por entorno: el mismo CUIT en homologación y en producción son dos entradas separadas, cada una con su certificado. Si te falta uno, generá el CSR de esa entrada, tramitalo en ARCA para ese entorno y subí el .crt que te devuelvan.

El CUIT no aparece en la lista de relaciones

Status: 403 · Error de ARCA: 600 (El CUIT no aparece en la lista de relaciones).

El certificado es válido y está autorizado, pero el CUIT que mandaste como representada no le delegó el servicio. Pasa típicamente cuando facturás para terceros: el certificado es tuyo, pero cada cliente tiene que autorizarte.

Cómo resolverlo: el CUIT representado (no vos) tiene que entrar al Administrador de Relaciones de Clave Fiscal de ARCA y delegarle el servicio a tu certificado, con el mismo procedimiento de la sección anterior. Es una delegación por CUIT y por servicio.

Subiste el CSR en lugar del certificado

Dónde aparece: en el dashboard, al cargar el certificado. No es un error de la API.

Son dos archivos distintos y se confunden fácil, porque los dos son texto PEM:

1. El CSR (el pedido de certificado) es el que te damos nosotros al dar de alta el CUIT. Empieza con -----BEGIN CERTIFICATE REQUEST-----. Va hacia ARCA.
2. El certificado (.crt / .pem) es el que te devuelve ARCA después de pegar el CSR. Empieza con -----BEGIN CERTIFICATE-----. Va hacia arca.api.

Si al subir el certificado adjuntás el CSR que te dimos nosotros, el dashboard lo detecta y te lo dice: es el archivo que va en la otra dirección.

Cómo resolverlo: pegá el CSR en ARCA (Administración de Certificados Digitales, o el WSASS en homologación), descargá el .crt que ARCA emite a partir de él, y subí ese archivo. No te va a pedir la clave privada: la generamos nosotros junto con el CSR y la guardamos cifrada.

Si ya tenías tu propio certificado, generado por fuera de arca.api, no uses el CSR que te dimos: el .crt que ya tenés no salió de él y lo vamos a rechazar. En el diálogo de subida elegí "Subí el par" y cargá tu .crt junto con tu .key. El CSR pendiente se cancela solo.

La representada no tiene certificado en ese entorno

Status: 403 · Mensaje: La representada no existe, no pertenece a tu cuenta o no está registrada en ese entorno, o La representada no tiene certificado activo en ese entorno.

Este error es nuestro, no de ARCA: ni siquiera llegamos a llamarlo. El CUIT que mandaste en representada no está dado de alta en tu cuenta para el environment del request, o está dado de alta pero sin certificado activo.

Cómo resolverlo: en el dashboard, sección Certificados, confirmá que el CUIT exista para ese entorno y tenga su certificado cargado. Recordá que homologación y producción se registran por separado.

Autenticación con arca.api

Estos errores son de nuestra capa de autenticación, no de ARCA. Se resuelven en tu request o en el dashboard, y no consumen cuota.

La API key no es válida

Status: 401 · Respuesta: { "error": "No autorizado" }.

La API key está ausente, es inválida o fue revocada. Repasá:

• El header va como Authorization: Bearer ak_TuSecretoAqui. Sin el prefijo Bearer no autentica.
• La key no está revocada (miralo en el dashboard, sección API keys).
• No estás mandando el prefijo visible de la key en lugar del secreto completo. El secreto se muestra una sola vez, al crearla; si lo perdiste, revocá esa key y creá una nueva.

Ver API keys.

La API key es de solo lectura

Status: 403 · Todos los mensajes empiezan con "Esta API key es de solo lectura" y siguen según qué intentaste:

Estás llamando a un endpoint de escritura con una key de scope read_only. El request se rechaza antes de tocar ARCA y sin consumir cuota.

Es la única variante de 403 que no viene de ARCA ni de tus certificados: si el mensaje empieza con "Esta API key es de solo lectura", el problema es el scope de la credencial, no la delegación del web service.

Cómo resolverlo: usá una key read_write, o creá una nueva con ese scope en el dashboard. El scope no se puede cambiar sobre una key existente. Ver Scopes de API key para la lista completa de qué habilita cada uno.

Te quedaste sin cuota

Status: 402 · Mensaje: Cuota de facturas del período agotada / Cuota de padrones del período agotada.

Agotaste la cuota de tu plan para el período en curso. La cuota se cuenta solo sobre producción: las llamadas a homologación no consumen nada.

Tampoco consumen cuota las llamadas que ni siquiera llegaron a ARCA (400, 401, 402, 403, 429 y 502). Dicho al revés: lo único que descuenta de tu plan es un 200.

Cómo resolverlo: subí de plan desde el dashboard, o esperá al próximo período. En Consumo podés ver cuánto llevás usado y contra qué límite; cada llamada del historial dice si fue facturable y, si no lo fue, por qué.

El request no pasó la validación

Status: 400 · El mensaje del error nombra el campo concreto.

El request no llegó a salir de arca.api. No consume cuota. Las causas habituales:

• Body JSON inválido — el cuerpo no parsea. Revisá el Content-Type: application/json y las comillas.
• Falta un campo o está mal formado — representada tiene que ser un CUIT de 11 dígitos sin guiones; environment solo acepta "homologacion" o "produccion".
• cbteTipo no soportado — los tipos aceptados vienen listados en el propio mensaje de error.

Si el request es sintácticamente válido pero los números no cierran, el error es un 422: ver Los importes o las alícuotas no cierran.

Clientes y productos

Errores de los recursos de tu cuenta (clientes y productos) y de las referencias que los usan al emitir. Ninguno llega a ARCA, así que ninguno consume cuota.

Ya tenés un cliente con ese documento

Status: 409 · Mensaje: Ya tenés un cliente con ese documento.

Intentaste crear (o renombrar el documento de) un cliente con un docTipo + docNro que ya existe en tu agenda. El par es único por cuenta: no se puede tener dos veces al mismo receptor.

Cómo resolverlo: buscá el cliente existente con GET /api/clientes y actualizá ese con PATCH /api/clientes/{id} en lugar de crear uno nuevo. Un cliente que diste de baja no bloquea el documento: podés volver a crearlo.

Productos no tiene esta restricción: podés tener dos ítems con la misma descripción.

El cliente o el producto no existe

Status: 404 · Mensaje: Cliente no encontrado / Producto no encontrado.

El id que mandaste no corresponde a ningún recurso vivo de tu cuenta. El 404 es deliberadamente uniforme: no distingue entre "no existe", "es de otra cuenta" y "lo diste de baja", para no filtrar la existencia de recursos ajenos.

Lo más común es lo tercero: la baja es lógica, así que el id sigue siendo un id válido pero deja de responder. No hay forma de restaurarlo por API — creá el recurso de nuevo.

No pudimos resolver una referencia

Status: 400 · Mensajes: No se encontró el cliente <id> en tu cuenta, El cliente <id> no tiene condición frente al IVA cargada, El producto <id> no tiene alícuota de IVA cargada, y sus equivalentes por producto.

Estás emitiendo por referencia —con clienteId o productoId— y la referencia no se pudo resolver. Es un 400 y no un 404 porque el recurso que estás creando es el comprobante: lo que falla es un campo dentro del body.

Dos causas distintas:

1. La referencia no existe en tu cuenta (o la diste de baja). Igual que arriba, el mensaje no distingue los casos.
2. La referencia existe pero le falta un dato obligatorio para emitir. El modelo guardado es más laxo que el de emisión: condicionIvaReceptorId en un cliente y alicuotaIva en un producto son opcionales al guardar, pero obligatorios al emitir. Nunca los inferimos: un comprobante con la alícuota equivocada sale con CAE y ya no se puede corregir.

Cómo resolverlo: completá el dato en el recurso guardado (PATCH /api/clientes/{id} o PATCH /api/productos/{id}), o mandalo explícito en el body de la emisión — el valor explícito siempre gana sobre el de la referencia.

El request se rechaza antes de llamar a ARCA: no consume cuota y no avanza la numeración. Podés corregirlo y reintentar sin ningún costo.

Emisión de comprobantes

ARCA rechazó el comprobante

Status: 422 · Respuesta: "resultado": "R", con el detalle en observaciones y errores.

El comprobante llegó a ARCA, ARCA lo procesó y lo rechazó: no hay CAE. No es un fallo de comunicación ni de configuración, es una regla de negocio del organismo.

El código que ARCA devuelve en observaciones[].code es la clave para saber qué hacer. Los más frecuentes tienen sección propia: 10016, 11002, importes.

Un 422 no consume cuota: llegó a ARCA, pero no obtuvo CAE. Corregí el motivo del rechazo y reintentá sin costo — es lo habitual mientras terminás de configurar el punto de venta. Lo único que sí tiene tope es insistir con el mismo error: ver Demasiados rechazos seguidos.

Demasiados rechazos seguidos

Status: 429 · Mensaje: Demasiados comprobantes rechazados por ARCA en la última hora…

Como los rechazos no se cobran, ponemos un tope alto de rechazos por hora para que una integración con un bug no quede reintentando el mismo error contra ARCA indefinidamente. Un uso normal no lo alcanza nunca: configurar un punto de venta o acomodar la numeración produce unos pocos rechazos, no decenas.

Si lo viste, casi seguro estás reintentando en loop. El límite:

• Se cuenta por cuenta y por entorno, sobre la última hora móvil. Probar en homologación no te corta la facturación de producción.
• Sólo cuenta los rechazos de emisión (422). Las emisiones con CAE no acercan al tope.
• Se libera solo: no hay nada que hacer en el dashboard ni que pedirnos.

Cómo resolverlo: frená los reintentos y mirá el observaciones[].code del último rechazo — el problema está ahí y no se arregla insistiendo. Cuando lo tengas resuelto, esperá a que la ventana se vacíe y reintentá. El request se rechaza antes de llegar a ARCA, así que no consume cuota ni avanza la numeración.

La numeración o la fecha no corresponden

Status: 422 · Código de ARCA: 10016 (El número o fecha del comprobante no se corresponde con el próximo a autorizar).

Es el rechazo más común. Los comprobantes de un punto de venta y tipo tienen que ser correlativos y con fechas no decrecientes. ARCA rechaza el comprobante si:

• El número que mandás no es el siguiente al último autorizado (te salteaste uno, o repetiste).
• La cbteFch es anterior a la del último comprobante autorizado para ese punto de venta y tipo.
• La cbteFch está fuera de la ventana que ARCA acepta (±5 días para productos, ±10 para servicios).

Cómo resolverlo: consultá el último comprobante autorizado con /api/wsfe/ultimo-comprobante (o /api/wsfex/ultimo-comprobante) para ese ptoVta y cbteTipo, y emití el siguiente. Si no mandás cbteFch, arca.api usa la fecha de hoy, que es lo correcto en el caso normal.

El punto de venta no está habilitado

Status: 422 · Código de ARCA: 11002 (El punto de venta no se encuentra habilitado para operar con este web service).

El punto de venta existe, pero no está habilitado para facturación electrónica por web service. Un punto de venta habilitado para el portal Comprobantes en línea no sirve para la API: son modalidades distintas y se declaran por separado.

Cómo resolverlo, en el sitio de ARCA:

1. Entrá con Clave Fiscal al servicio Administración de Puntos de Venta y Domicilios.
2. Dale de alta un punto de venta con modalidad Web Services (o Factura Electrónica - Web Services).
3. Usá ese número de punto de venta en el campo ptoVta.

Podés verificar qué puntos de venta ve ARCA con la tabla puntos-de-venta de parámetros. Si el que estás usando no aparece ahí, no está habilitado para web services.

En homologación, los puntos de venta también hay que declararlos: el punto de venta 1 no viene habilitado por default.

Los importes o las alícuotas no cierran

Status: 422 (validación nuestra o rechazo de ARCA, p. ej. 10048).

Los totales del comprobante tienen que ser coherentes entre sí, y las alícuotas de IVA tienen que ser las que ARCA reconoce. Los casos habituales:

• Alícuota de IVA no válida — solo se aceptan las alícuotas oficiales (0, 2.5, 5, 10.5, 21, 27). El mensaje de error lista los valores aceptados.
• Alícuota en un comprobante tipo C — las facturas C (tipos 11, 12, 13) no llevan IVA discriminado. Mandá alicuotaIva: 0.
• Los importes no son coherentes — ImpNeto + ImpIVA + ImpTrib tiene que dar ImpTotal. arca.api calcula los totales a partir de los items; si mandás tributos, revisá que sus importes estén bien.
• Falta un ítem — el comprobante necesita al menos uno.
• Faltan las fechas de servicio — con concepto 2 (servicios) o 3 (productos y servicios) son obligatorios fchServDesde, fchServHasta y fchVtoPago.
• Faltan los comprobantes asociados — las notas de crédito y débito requieren al menos un elemento en comprobantesAsociados.

El comprobante no existe

Status: 404.

Pediste el PDF de un comprobante que no existe o que no pertenece a tu cuenta. El comprobante se identifica por la tupla completa —environment, representada, ptoVta, cbteTipo y cbteNro—: si cualquiera de los cinco no coincide con lo que emitiste, no lo encontramos. Solo podés acceder a los comprobantes emitidos desde tu propia cuenta.

Si el comprobante existe pero fue rechazado (resultado: "R", sin CAE), el PDF devuelve 422: un comprobante sin CAE no es un comprobante válido y no tiene representación impresa. Ver ARCA rechazó el comprobante.

Reintentar sin duplicar el comprobante

Un 502 o un timeout no significan que el comprobante no se haya emitido: puede que ARCA lo haya autorizado y la respuesta se haya perdido en el camino. Reintentar a ciegas es la forma más común de emitir dos veces el mismo comprobante.

Para eso está el header Idempotency-Key: mandá un identificador único por comprobante (un UUID, o tu propio número de orden) en el request de emisión.

curl -X POST https://arca.api.com.ar/api/wsfe/facturas \
  -H "Authorization: Bearer ak_TuSecretoAqui" \
  -H "Idempotency-Key: 7f3a1c9e-4b2d-4f8a-9c1e-2b6d8a4e7f11" \
  -H "Content-Type: application/json" \
  -d '{ ... }'

Si reintentás con la misma Idempotency-Key, arca.api te devuelve el comprobante que ya emitió en lugar de emitir uno nuevo. Es la única forma segura de reintentar una emisión.

Si ya reintentaste sin Idempotency-Key y no sabés en qué quedaste, consultá el último comprobante autorizado con /api/wsfe/ultimo-comprobante antes de volver a emitir.

ARCA no responde

Status: 502 · Errores de ARCA: 501 (error interno de la base de datos), timeouts, WSAA caído.

El problema es del organismo, no de tu configuración. Los web services de ARCA se caen con cierta regularidad, sobre todo cerca de los vencimientos.

Qué hacer: reintentá en unos minutos. No cambies el certificado, no toques la delegación, no reemitas con otro número: no hay nada roto de tu lado.

• Un 502 no consume cuota.
• Si estás emitiendo, reintentá con el header Idempotency-Key, porque el comprobante puede haberse emitido igual.
• Si el 502 persiste por horas y afecta a todos tus CUITs, es una caída del organismo. Si te pasa en un solo CUIT o en un solo servicio, revisá primero Certificados y entornos: un error de auth que no sabemos clasificar cae por defecto en 502.

En los endpoints de PDF el 502 no viene de ARCA sino de nuestro generador o del almacenamiento. Vale lo mismo: es transitorio, reintentá. El comprobante ya está emitido y su CAE no se pierde — el PDF se genera cuando lo volvés a pedir.

No encontraste tu error

Si el error que recibiste no está acá, escribinos desde Soporte en el dashboard e incluí:

• El endpoint que llamaste y el environment.
• El status HTTP y el mensaje completo que devolvió la API.
• El CUIT representado (no hace falta el certificado, y nunca nos mandes tu clave privada).

En la sección Consumo del dashboard tenés el historial de llamadas con su status: es la forma más rápida de ver qué está fallando y desde cuándo.