Estos endpoints permiten preparar ventas y compras sin copiar configuración
interna desde el dashboard:
GET /api/v1/organization identifica la organización de la credencial.GET /api/v1/tax-rates lista los códigos de alícuota aceptados.GET /api/v1/voucher-types calcula los comprobantes válidos para una venta o
compra concreta.
Los tres requieren settings:read. El scope permite leer estas referencias,
pero no modificar la configuración de la organización.
Organización autenticada
GET /api/v1/organization devuelve una proyección segura con identidad,
domicilio fiscal, contacto, moneda por defecto y zona horaria operativa.
La respuesta no expone settings, CBU, billing o suscripciones, plan y límites,
estado de onboarding, IDs internos de usuarios, roles, permisos, credenciales de
ARCA ni metadata de cuentas conectadas. default_currency es PES y timezone
es UTC-3: son defaults operativos documentados, no una copia del objeto de
configuración interno.
Códigos de referencia e IDs
Los recursos propios de tu organización usan un id UUID, por ejemplo
customer_id, supplier_id y point_of_sale_id. Las referencias estatutarias
usan code, porque el valor lo define ARCA y no pertenece a una organización.
En particular, el code devuelto por /tax-rates es el mismo valor que los
payloads históricos llaman tax_rate_id:
No reemplaces ese código por un UUID ni calcules el código a partir del
porcentaje.
Tipos de comprobante para ventas
Enviá operation=sale, customer_id y point_of_sale_id. La API resuelve la
condición fiscal, configuración de comprobantes A, habilitación de ARCA y acceso
al punto de venta dentro de la organización autenticada.
total_amount es opcional. Si lo enviás, currency es obligatorio. Para
currency=DOL, también tenés que enviar exchange_rate como pesos argentinos
por dólar. Todos los importes monetarios usan unidades menores: centavos de PES
o centavos de DOL. El equivalente en PES se redondea al centavo antes de evaluar
el mínimo de una Factura de Crédito Electrónica (FCE).
Sin contexto de monto completo, sin un CBU válido o por debajo del mínimo legal,
las FCE no aparecen. Un punto de venta no fiscal o una organización todavía no
confirmada en ARCA recibe solamente las opciones no fiscales elegibles.
Tipos de comprobante para compras
Para compras, enviá solamente operation=purchase y supplier_id:
La API aplica la compatibilidad fiscal con el proveedor y las habilitaciones
reales de compra. No podés activar comprobantes de importación con un parámetro
del request. Los campos exclusivos de venta se rechazan para compras, y
viceversa.
El resultado es una ayuda de descubrimiento. La escritura posterior vuelve a
validar el comprobante dentro de la transacción porque la configuración, el
monto o el estado fiscal pueden haber cambiado.
Scopes canónicos y compatibilidad
Las integraciones nuevas deberían pedir los scopes más específicos:
orders:*, payments:*, inventory:*, accounting:read y settings:read.
Algunas operaciones siguen aceptando scopes anteriores de forma compatible,
por ejemplo sales:read para leer pedidos o reports:read para lecturas
contables. Esa alternativa aparece como
x-accepted-legacy-scope-sets en OpenAPI y está deprecada para credenciales
nuevas; no convierte un scope anterior en permiso global para otras familias.
Por qué no hay /currencies ni /capabilities
La API V1 acepta las monedas contractuales estables PES y DOL; no son una
colección administrable que necesite un endpoint. Tampoco se publica un objeto
genérico de capabilities, porque sus booleanos quedarían rápidamente ambiguos.
Consultá la referencia contextual correspondiente y tratá la respuesta de cada
escritura como la validación definitiva. 
