Factuarea APIDevelopers
Contratov1.13.0

v1.13.0 — Paridad de contrato

Semántica de escritura de producto, consentimiento OAuth ampliado, capacidad API derivada del plan y notas multilínea en PDF.

23 de agosto de 2026 — esta versión cambia comportamiento y documentación sin añadir endpoints públicos ni tools MCP; su superficie pública no cambia respecto a la versión anterior.

Escrituras de producto

  • Las peticiones de creación/actualización de producto documentan specifications como un objeto completo de pares nombre/valor. Al actualizar, null la vacía y omitirla conserva su valor.
  • PUT /v1/products/{product} sigue siendo una actualización parcial. stock es un objetivo absoluto: la API registra solo la diferencia como movimiento; repetir el mismo valor no hace nada y null significa cero. stock y low_stock_threshold conservan cuatro decimales.
  • Crear con un external_id existente actualiza ese producto de forma idempotente. El metadata de producto mantiene la compatibilidad heredada: admite listas y convierte valores escalares a strings.
  • El contrato OpenAPI también alinea los campos actualizables series_id nullable y el alias iban aceptado en cuentas bancarias de proveedor.

OAuth y MCP

El consentimiento OAuth suma seis scopes: price_lists.read, price_lists.write, facturae.read, facturae.write, tax_reports.read y tax_reports.write. Así, 24 tools existentes pasan a estar disponibles para apps OAuth: 343 alcanzables por OAuth y 81 exclusivas de API key.

El catálogo asignable a API keys sigue siendo deliberadamente más estrecho que el registro de solo adición: los cuatro scopes reservados de autofacturación GoCardless y MONEI todavía no se pueden asignar.

Capacidad de Developer API derivada del plan

La capacidad API sigue directamente el plan activo de Factuarea: Trial/Free, Emprendedor/Starter, Empresario/Pro y Enterprise/Scale. No hay un add-on Developer API ni un boost de capacidad que contratar. Una migración histórica grandfathered_addon puede conservar un tier superior mientras siga activo un plan válido.

Los errores de capacidad de webhooks reflejan este modelo: addon_required significa que el plan actual concede cero endpoints; addon_not_active, que no hay un plan activo válido; y superar un tope positivo devuelve business_rule_violation con subcode: max_webhook_endpoints_reached.

PDFs de documentos

Las notas y condiciones multilínea conservan ahora sus saltos y se apilan línea a línea en los PDFs generados.

Endpoints actualizados2

EndpointDescripción
POST/v1/productsCrear un producto
PUT/v1/products/{product}Actualizar un producto

En esta página

¿Te echamos una mano?Contactar con soporte