Equipo, claves y logs en el eje de cuenta

11 de octubre de 2026

El eje de cuenta (/v1/accounts/{account}/…) ahora dice quién hizo qué y cuándo, para que una integración pueda mostrar la misma imagen que la app en Equipo y Desarrolladores. Todo lo de esta página es aditivo: no se ha retirado nada y ningún campo existente cambia de significado.

Uso diario de una API key

getAccountApiKeyUsage (GET /v1/accounts/{account}/api-keys/{api_key}/usage, scope account:read) devuelve el uso de una clave en los últimos 7, 30 (por defecto) o 90 días con el parámetro de consulta days. Cualquier otro valor responde 422.

data.daily tiene un elemento por día, del más antiguo al más reciente, con requests_count, successful_count, client_error_count, rate_limited_count y error_count; los días sin peticiones aparecen con todos los contadores a 0. data.total suma el periodo, y last_used_at y last_used_ip indican cuándo y desde dónde se usó la clave por última vez (null si nunca se usó). Solo devuelve contadores, nunca cuota, límites de tramo ni precios. Una clave que no existe, que es de otra cuenta o que llega a un NIF fuera de tu credencial responde el mismo 404 api_key_not_found. La tool MCP es get_api_key_usage.

API keys: restricciones, autoría y rotación

Las operaciones de claves (listar, consultar, crear, revocar, rotar el secreto y cambiar los NIF) ahora devuelven:

• ip_allowlist y allowed_origins: las direcciones IP o rangos y los orígenes de navegador a los que está restringida la clave, o null.
• last_used_ip, junto a last_used_at.
• nif_scope: los NIF a los que llega la clave, cada uno como {id, tax_id, name, access_level} con access_level view u operate.
• created_by, revoked_by y revoke_reason: quién creó y quién revocó la clave, y por qué.
• secret_rotated_at, secret_rotated_by y previous_secret_valid_until: cuándo se rotó el secreto por última vez, quién lo hizo y hasta cuándo sigue autenticando el secreto anterior.

Crear y rotar siguen devolviendo el secreto una sola vez, y solo entonces. Una rotación hecha con una credencial de API o con el servidor MCP nunca nombra a una persona: secret_rotated_by queda en null. Las tools MCP get_api_key y list_api_keys devuelven los mismos campos.

Miembros e invitaciones: cuándo

Los miembros ahora llevan joined_at y last_access_at. El segundo es una cota inferior: la suplantación de soporte y los accesos OAuth o MCP no cuentan, así que un miembro puede estar activo sin que se mueva.

Las invitaciones ahora llevan created_at, sent_at (la creación o el último reenvío) e invited_by, un objeto {id, name} que es null cuando esa persona ya no pertenece a la cuenta. Las tools de miembros e invitaciones en MCP también los devuelven.

Logs de peticiones: empresa, eje y filtros

Los logs de peticiones de la cuenta y de una empresa ahora dicen sobre qué NIF actuó cada petición y en qué eje:

• company: {id, tax_id, name}, o null cuando la petición no actuó sobre una empresa.
• axis: company o account, derivado del prefijo de la ruta.

Los dos listados aceptan el filtro nuevo company=<uuid>, que limita los logs a una empresa; una empresa fuera de tu ámbito responde 422 invalid_param_value con param company. El listado de la cuenta acepta además relationship=own|client, que limita los logs a tus propios NIF o a los de cuentas cliente. Las cuatro tools de logs en MCP devuelven los campos nuevos y aceptan los filtros de su operación.

Dominios de retorno de Stripe Connect

La lista de dominios de retorno ahora lleva meta.max (20), el máximo de dominios que una cuenta puede registrar. La lista está completa cuando has_more es false, así que data frente a max indica cuántas plazas quedan.

Corrección: un endpoint de webhook desactivado se puede reactivar

La guía de webhooks de cuenta decía que un endpoint desactivado no se podía volver a activar. Sí se puede: envía PATCH con status: active y el endpoint vuelve a recibir eventos. La guía y las descripciones de MCP ya lo dicen.

KeyRound

API keys

UsersRound

Cuentas y NIF

Webhook

Webhooks de cuenta