Ajustes del contrato de cuentas
Correcciones del contrato v1 tras la revisión del 6 de octubre, compras duraderas en el eje de empresa y la forma final de las cuentas gestionadas, el NIF adicional y el tope de usuarios.
7 de octubre de 2026
Hemos revisado el nuevo modelo de cuentas línea a línea antes de que llegue a vuestras integraciones y hemos ajustado algunas cosas. La mayoría hacen el contrato más estricto donde era demasiado generoso, así que conviene leer esta página si vuestra integración emite credenciales, reintenta escrituras o contrata asientos.
Lo que corrigió la revisión
idempotency_key_reused responde ahora siempre 422, sea cual sea la operación que reutiliza la clave. La huella de idempotencia ya no expone secretos: la repetición de una escritura que devolvió un secreto conserva la respuesta original, pero el secreto nunca queda legible en lo que guardamos.
El scope * no cubre la administración de cuenta (account:owner, members:*, invitations:* y nif_transfers:*), y api_keys:* queda reservado: pídelos por su nombre. Una credencial ya no puede crear, rotar, revocar ni cambiar el ámbito de NIF de otra que tenga más poder que ella; la respuesta es 403 insufficient_scope, o 403 live_credential_required cuando una clave de pruebas intenta tocar una de producción.
Las operaciones v1 de contactos respetan ahora la cabecera Factuarea-Version como el resto del contrato. Los webhooks de cuenta comprueban además, evento a evento, que cada endpoint puede seguir viendo lo que va a recibir.
Las compras duraderas pasan al eje de empresa
Todas las operaciones de los lotes de empleados (employee-batches), los canjes de ofertas de asientos de empleado (employee-seat-offer-redemptions) y los canjes de ofertas de NIF adicional (gestoria-seat-offer-redemptions) viven ahora bajo /v1/companies/{company}/…, sin alias plano. Es la misma retirada de rutas planas que ha seguido el resto del modelo de cuentas. Los nombres de operación y de tool MCP no cambian: si las llamáis con un SDK, la CLI o MCP, solo tenéis que actualizar la versión; si las llamáis por URL, añadid la empresa a la ruta.
Alta, activación y vista previa de NIF
El alta, la activación y la activación en lote de NIF, y la vista previa del cargo, pueden responder ahora 409 customer_offer_phase_incompatible cuando las condiciones que ya tenéis no se pueden conservar, y 503 gestoria_seat_preview_unavailable cuando no podemos calcular la vista previa en ese momento. En ninguno de los dos casos se crea, se activa ni se cobra nada, así que podéis reintentar con tranquilidad.
La vista previa también explica por qué un importe es cero, en zero_reason: trial, covered, enterprise_contract, negotiated_free_price o no_immediate_charge. Un motivo desconocido nunca significa contrato Enterprise.
Las operaciones de asientos, empleados, lotes y empresas que pueden toparse con una operación pendiente o con un cambio de condiciones declaran ahora su 409 con un ejemplo, y el 409 external_id_already_exists de los lotes de empleados añade row_ids, el row_id estable de cada fila cuyo external_id ya estaba ocupado, para que corrijáis esas filas y volváis a enviar el lote.
Cuentas gestionadas, NIF adicional y tope de usuarios
Como proveedor, ya podéis asignar Avanzado (integral) además de Esencial y Profesional a una cuenta gestionada, al precio normal del plan. managed_accounts_by_plan incluye siempre la clave integral. Enterprise sigue acordándose con nosotros por contrato.
Un NIF adicional cuesta 15 € al mes, IVA excluido. En una cuenta Profesional o Avanzado, cada NIF adicional tiene el plan Profesional; solo el NIF titular tiene el plan de la cuenta.
El tope de usuarios se cuenta por plazas de la cuenta, no de cada NIF. Aceptar una invitación con el tope lleno responde 422 business_rule_violation, con el mismo mensaje que veis en la aplicación, y no un 402.