Claves API

Las claves API no son Miembros con credenciales. Tienen su propio modelo de permisos, más sencillo:

Los dos modelos están separados de forma deliberada. Los Miembros tienen roles, perfiles y granularidad por cuenta porque las personas acumulan responsabilidades diversas. Las claves siguen un modelo plano de alcance y cuentas porque la automatización debe ser concreta, uniforme y fácil de auditar de un vistazo.

Una clave API combina dos selecciones: qué puede hacer (sus permisos) y dónde (sus cuentas).

Permisos

Asignación de cuentas

Cada clave se asigna a una o varias cuentas, seleccionadas al crearla y modificables posteriormente. Los permisos de la clave se aplican de forma uniforme a todas las cuentas seleccionadas:

• Una clave con los permisos Consultar fondos y Crear y modificar órdenes sobre dos cuentas seleccionadas puede leer balances y operar en ambas, y nada más.
• Dentro de una clave no existe variación por cuenta. Si tu automatización necesita operar en una cuenta pero solo leer otra, utiliza dos claves. Así el alcance potencial de cada clave resulta evidente de un vistazo.

Selecciona una cuenta específica cuando sea necesario

Las solicitudes de API privadas usan la cuenta principal de la organización cuando se omite account_id:

Para operar en una cuenta específica, pasa account_id como parámetro de consulta en la URL:

Pásalo en la URL, no en el cuerpo de la solicitud. Un account_id explícito tiene prioridad sobre la cuenta principal predeterminada. No amplía la asignación de cuentas ni los permisos de la clave. Si la clave no puede operar en la cuenta seleccionada, la solicitud se rechaza.

Conectividad FIX

Las claves con permisos de órdenes admiten conectividad FIX para trading spot, junto con las API REST y WebSocket. Una sesión FIX hereda los permisos y la asignación de cuentas de la clave asociada: opera únicamente en las cuentas seleccionadas por la clave y dentro de sus permisos. Las empresas con flujo de órdenes FIX suelen asignar una clave por sesión, limitada a las cuentas que opera el escritorio.

Configuración de seguridad

La gobernanza de la organización se aplica tanto a lo que hacen las claves como a cómo se gestionan.

Lo que hacen las claves

La regla de dos categorías para los miembros se aplica a las claves del mismo modo:

• Las operaciones directas se ejecutan de inmediato. El trading, Earn, las consultas de balance, las consultas al libro mayor y las exportaciones de datos se completan al instante, dentro de los permisos y las cuentas de la clave.
• Las operaciones gobernadas crean solicitudes. Un retiro o un cambio de dirección iniciado por una clave sigue el mismo proceso que uno iniciado por un miembro: la política del flujo de trabajo decide si se completa de inmediato o queda en cola de aprobación para revisión humana.

Una clave solo puede iniciar solicitudes gobernadas. Las claves nunca tienen permiso de aprobación: la separación de funciones exige un miembro humano para cada aprobación, y un script no puede sustituir ese criterio. Cuando la política de solicitudes de retiro exige dos aprobaciones, un retiro iniciado por una clave espera a dos miembros, exactamente igual que uno iniciado por un miembro.

Una llamada exitosa no es un retiro completado

Diseña tu automatización teniendo en cuenta esa asincronía. WithdrawFunds devuelve approval_request_id junto con refid:

• refid confirma que la solicitud existe, no que los fondos se hayan movido. El importe queda bloqueado en la cuenta de origen al enviarse y solo se liquida una vez aprobada la solicitud. Consulta Los fondos se bloquean al enviar.
• approval_request_id es el identificador de la aprobación que aguarda el retiro. Guárdalo junto a tu propio registro del retiro.
• Los retiros pendientes de aprobación no aparecen en WithdrawStatus. Una solicitud rechazada o que vence no genera ningún registro de retiro, por lo que su ausencia en WithdrawStatus no significa que no se haya enviado.

Cualquier automatización que tome un refid como prueba de que la operación se ha completado informará de retiros como liquidados mientras permanecen en la cola de aprobación, y cualquier conciliación que deduzca "no aparece en WithdrawStatus, por lo tanto nunca se envió" será incorrecta tanto para las solicitudes pendientes como para las rechazadas.

Las claves tampoco tienen acceso a los flujos de trabajo administrativos. La gestión del acceso del equipo, las claves API, las cuentas, las direcciones (salvo el inicio de solicitudes de dirección) y las políticas es exclusiva de los Miembros.

Cómo se gestionan las claves

Crear, editar y revocar claves API es una operación gobernada dentro del flujo de trabajo específico Manage API Keys, independiente de Manage Team & Access. Esta separación es relevante por dos motivos:

• Administradores distintos. Puedes permitir que un ingeniero de operaciones gestione las claves sin que tenga capacidad para modificar el acceso de los Miembros, y viceversa.
• Políticas distintas. La gestión de claves puede tener sus propios requisitos de aprobación. Muchas Organizaciones exigen aprobación independiente para crear o modificar una clave, ya que una nueva credencial supone una nueva vía de acceso a las cuentas, sin por ello ralentizar la revocación.

1. Ve a Claves API y selecciona Crear clave.
2. Asigna un nombre a la clave según su función: el sistema al que sirve y lo que hace, para que sea fácil identificarla en revisiones y eventos de seguridad.
3. Selecciona los permisos de la clave.
4. Selecciona las cuentas en las que operará la clave. Los permisos se aplican de forma uniforme a todas ellas.
5. Configura los ajustes de seguridad: fecha de vencimiento, restricciones de IP y ventana nonce.
6. Revisa y confirma. Si la política de Gestión de Claves API requiere aprobación, la solicitud queda en espera hasta recibir las aprobaciones necesarias y entonces se emite la clave.

La edición de permisos o cuentas de una clave, así como su revocación, siguen el mismo proceso de gobernanza.

La llamada ha generado una solicitud de retiro que la política de solicitudes de retiro retiene pendiente de aprobación. Consulta la página de Solicitudes; la solicitud aparece allí con la clave como iniciadora, pendiente de las aprobaciones de Miembros requeridas. Así funciona el modelo de gobernanza según lo previsto: la automatización propone, las personas aprueban.

El importe queda bloqueado en la cuenta de origen mientras la solicitud está pendiente, por lo que ya está reservado para el retiro. Haz el seguimiento de la solicitud con el approval_request_id devuelto con la llamada.

La cuenta con errores no está incluida en el mapeo de cuentas de la clave. Una clave solo actúa sobre las cuentas que tiene asignadas. Edita la clave para añadir la cuenta. Ten en cuenta que todos los permisos de la clave se aplicarán también allí, ya que las claves no admiten variación por cuenta. Si ese alcance es demasiado amplio, crea una segunda clave limitada a la nueva cuenta.

Una sola clave no puede tener permisos distintos según la cuenta. Crea dos claves: una de trading asignada a la cuenta A y una de solo lectura asignada a la cuenta B. Las claves con alcance reducido son también más fáciles de auditar y más seguras de revocar.

El flujo de trabajo Manage API Keys probablemente requiere aprobación y la solicitud sigue pendiente. La clave se emite, y su secreto se muestra, solo después de recibir las aprobaciones necesarias. Comprueba el estado de la solicitud en la página Solicitudes.

No. La aprobación siempre requiere la intervención de un miembro humano. Esta es una regla del sistema, no una política configurable: es lo que garantiza que la aprobación multiparte sea significativa cuando la automatización inicia movimientos de fondos.