Renovar la clave por defecto y ver actividad

Solo la sesión JWT del dueño puede renovar la clave predeterminada y consultar el detalle de actividad. No se permite con sesión de empleado, cliente ni appKey.

POST /v1/api-keys/default/rotate
Authorization: Bearer TOKEN_DEL_DUENO
Content-Type: application/json

{}

Devuelve api_key con el registro actualizado. Cambia únicamente api_key y updated_at: conserva ID, fecha de creación, permisos, límites y consumo. La credencial anterior deja de autenticar nuevas solicitudes. No se crea ni se elimina ninguna clave.

GET /v1/api-keys/API_KEY_ID/activity?month=2026-09&page=1
Authorization: Bearer TOKEN_DEL_DUENO

Devuelve credits, requests, credit_total y request_total. Cada lista pagina 25 registros, ordenados del más reciente al más antiguo. El mes usa America/Caracas. credits contiene fecha, créditos, origen, descripción y movement_type; requests contiene fecha, request_type, provider, bank_account_id y error_code. El historial corresponde a operaciones bancarias atribuidas a la clave; no es un registro completo de todas las rutas HTTP y no guarda sus URLs. La ausencia de error_code no prueba por sí sola que un pago fue confirmado.

Para el total mensual y el límite usa GET /v1/api-keys/API_KEY_ID/credit-limit?month=2026-09. En Integraciones encontrarás los botones de consumo y límite y de detalle de consumos y peticiones.

Cliente y cuentas bancarias · B2B2B

En Integraciones puedes vincular una clave a un cliente y seleccionar cuentas. Sin selección, accede a todas las cuentas de su alcance; con selección, únicamente a esas cuentas. Siempre se valida el dueño.

Una clave vinculada hereda los permisos fijos y el cupo mensual del cliente. No puede consultar el plan ni el saldo del dueño. Sus cuentas nuevas se vinculan automáticamente al cliente, aunque el request intente indicar otro. Si la clave tiene una selección explícita, el dueño debe añadir las cuentas nuevas a esa selección para acceder a ellas.

POST /auth/api-key
Authorization: Bearer TOKEN_DEL_DUENO
Content-Type: application/json

{"name":"Sucursal Centro","client_owner_id":"CLIENT_ID","user_banks":["BANK_ID"]}

Con un token de cliente, omite client_owner_id: el servidor usa el cliente autenticado. Omitir user_banks, enviarlo como null o [] significa todas las cuentas de ese alcance.

PUT /v1/api-keys/API_KEY_ID/scope
Authorization: Bearer TOKEN_DEL_DUENO
Content-Type: application/json

{"client_owner_id":"CLIENT_ID","user_banks":["BANK_ID"]}

Esta operación reemplaza el alcance y solo admite la sesión del dueño: no empleados, clientes ni otras API keys. La clave predeterminada no admite cambios. Si cambia el cliente, se reinician los permisos; al desvincularlo quedan desactivados hasta configurarlos. Para desvincular y quitar la selección envía:

{
  "client_owner_id": null,
  "user_banks": []
}

GET /me/usersbank
appKey: CLAVE_DE_LA_INTEGRACION

GET /me/api-keys y GET /api-keys/API_KEY_ID incluyen client_owner_id y user_banks. Un cliente solo puede listar sus claves. Una clave limitada a cuentas no puede emitir otras claves ni usar reportes globales; usa rutas por cuenta como GET /movements/BANK_ID o POST /userbankpayment/BANK_ID/betaserio, siempre que sus permisos lo permitan. Las claves de cliente mantienen los permisos de cuentas y notificaciones, sin heredar verificación de pagos del dueño.

GET /v1/bank-pay-notifications aplica el alcance antes de paginar, incluyendo la app de marca blanca. Las cuentas ajenas o fuera de la selección se rechazan; al editar el alcance, una cuenta que no pertenece al cliente se rechaza con 400.

El consumo se consulta con GET /v1/api-keys/API_KEY_ID/credit-limit?month=2026-09. Para una clave de cliente, el dueño ajusta el cupo compartido en PUT /v1/clients/CLIENT_ID/credit-limit; la clave no puede ampliar su propio cupo.