Pasando de la Beta

Tus claves API existentes no se revocan ni se vuelven a emitir. Sus credenciales, permisos y mapeo de cuentas se transfieren. Lo que cambia es cómo tu código gestiona las solicitudes y lee las respuestas.

Selecciona una cuenta en cada solicitud

Una clave API de Organización cubre una o más Cuentas y no tiene un valor predeterminado, por lo que cada solicitud privada debe indicar a qué Cuenta se aplica. Pasa account_id como parámetro de consulta en la URL, no en el cuerpo de la solicitud:

Esto se aplica por igual a las consultas de trading, saldo y libro mayor, historial de órdenes y operaciones, exportaciones y movimiento de fondos.

Lee la nueva respuesta de retirada

WithdrawFunds devuelve approval_request_id junto con refid:

• Un refid ya no significa que la retirada se haya completado. El importe se bloquea en la Cuenta de origen cuando se envía la solicitud, y solo se liquida después de que la solicitud sea aprobada.
• approval_request_id es el identificador de la aprobación que la retirada está esperando. Guárdalo en tus propios registros.
• Las retiradas pendientes de aprobación no aparecen en WithdrawStatus. Una solicitud que es rechazada o expira no crea ningún registro de retirada, por lo que la ausencia en WithdrawStatus nunca significa que una retirada no fue enviada.

La automatización que trata un refid como prueba de finalización informará las retiradas como liquidadas mientras aún están en la cola de aprobación. Consulta claves API para el modelo completo.

Tu Organización sale de la conversión con dos conjuntos de bloques de construcción estándar.

Perfiles de Flujo de Trabajo

Un Perfil de Flujo de Trabajo establece lo que un Miembro puede hacer en cada flujo de trabajo gobernado. Cada Miembro tiene exactamente uno.

Roles de Cuenta

Un Rol de Cuenta establece lo que un Miembro puede hacer en tus Cuentas. Los roles estándar cubren todas las Cuentas actuales y futuras, por lo que un Miembro en Comercio total puede operar en una Cuenta que crees mañana.

Los perfiles y roles estándar siguen el ritmo del producto: cuando se añade un nuevo flujo de trabajo, los Miembros que tienen uno adquieren automáticamente el nivel apropiado. Consulta Roles, perfiles y permisos para ver el modelo completo.

Cuando los permisos de un Miembro no coinciden con ningún perfil estándar, se le asigna un rol con exactamente los permisos que tenía. Los Miembros con permisos idénticos comparten un único rol, por lo que tu Organización tendrá muchos menos roles que Miembros.

Estos roles toman su nombre de la etiqueta que habías escrito junto al Miembro, por lo que un Miembro etiquetado como «Trader» adquiere un rol llamado trader. Los Miembros sin etiqueta adquieren el rol migrated-role. Cada uno lleva una insignia de migrado, lo que significa que el nombre fue generado y tú puedes cambiarlo.

Por qué tus Miembros «Administrador» no están en el perfil de Administrador

La etiqueta «Administrador» de la Beta permitía a alguien ver, iniciar y aprobar, pero no completar sus propias solicitudes sin una segunda aprobación. El perfil de Administrador sí incluye esa capacidad, que es el nivel de Ejecución.

En lugar de concederlo automáticamente, los Miembros con la etiqueta antigua se colocan en un rol llamado beta-admin que contiene exactamente los permisos que ya tenían. Moverlos a Administrador es una única asignación cuando tú decidas hacerlo.

El Propietario se asigna al perfil de Administrador, conserva todo lo que tenía y adquiere automáticamente nuevos flujos de trabajo. El Propietario también tiene «Leer todo», que no se puede eliminar.

Si habías reducido deliberadamente los permisos del Propietario, esa decisión se conserva: el Propietario se convierte en un rol que contiene sus permisos reales, como cualquier otro Miembro.

• Se mantienen todos los permisos que tenía cada Miembro.
• Las credenciales, permisos y la asignación de Cuentas de la clave API se conservan.
• Los saldos, las Cuentas y la titularidad de las Cuentas no se modifican.
• Las solicitudes de aprobación ya en curso continúan, y tus políticas, umbrales de aprobación y configuraciones de «requerir siempre aprobación» no cambian.
• La verificación de identidad no se ve afectada, y nadie necesita iniciar sesión de nuevo ni ser invitado de nuevo.
• Solo las Cuentas que pertenecen a tu Organización se convierten. Un permiso en cualquier Cuenta fuera de ella se mantiene tal cual.

Es casi seguro que a la solicitud le falta account_id. Sin este, una llamada privada no se resuelve en una de las Cuentas de la clave y puede responder con un resultado vacío en lugar de un error. Añade account_id a la URL y vuelve a comprobar cada endpoint al que llama tu integración, no solo los que fallaron visiblemente. Consulta Claves de API.

La llamada creó una solicitud y bloqueó el importe en la Cuenta de origen. La liquidación se produce después de la aprobación. Realiza un seguimiento de la solicitud con el approval_request_id devuelto por la llamada, o encuéntrala en la página Solicitudes. Consulta Transferencias y retiradas.

Los Miembros cuyos permisos no coincidían con un perfil estándar necesitan cada uno un rol que preserve su acceso, y dos Miembros solo se fusionan en un rol cuando sus permisos son idénticos. Los Miembros a los que les habías dado etiquetas diferentes permanecen en roles separados incluso cuando sus permisos coinciden, porque las etiquetas sugieren que la distinción fue intencionada. Los roles que no necesitas se pueden consolidar reasignando a sus Miembros y eliminando el rol vacío.

Los Miembros que administran la Organización, gestionan el acceso del equipo, las Cuentas o las claves de API, se colocan en Leer todo, porque administrar una Cuenta implica poder verla. Si eso es más amplio de lo que quieres, reemplaza Leer todo por un Rol de cuenta limitado a las Cuentas específicas que necesitan.

No. La conversión es unidireccional. Todo lo que produce es editable después, por lo que cualquier acuerdo de acceso que tenías se puede reconstruir utilizando perfiles y roles.