Migración desde Beta

Tus claves de API existentes no se revocan ni se reemiten. Sus credenciales, permisos y asignación de cuentas se transfieren íntegramente. Las llamadas existentes que no incluyan account_id siguen operando en la cuenta principal de la Organización. Revisa cómo tu integración selecciona otra cuenta y procesa las respuestas de retiro.

Selecciona una cuenta específica cuando sea necesario

Cuando se omite account_id, una solicitud privada opera en la cuenta principal:

Para operar en una cuenta específica, incluye 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.

Lee la nueva respuesta de retiro

WithdrawFunds devuelve approval_request_id junto con refid:

• Un refid ya no indica que el retiro se haya completado. El importe queda bloqueado en la cuenta de origen cuando se envía la solicitud, y solo se liquida tras su aprobación.
• approval_request_id es el identificador de la aprobación que aguarda el retiro. Guárdalo junto a tu propio registro.
• 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 trate un refid como confirmación de finalización notificará los retiros como liquidados mientras siguen en la cola de aprobación. Consulta claves de API para ver el modelo completo.

Tras la conversión, tu organización contará con dos conjuntos de elementos estándar.

Workflow Profiles

Un Workflow Profile define qué puede hacer un miembro en cada flujo de trabajo gestionado. Cada miembro tiene exactamente uno.

Account Roles

Un Account Role define lo que un miembro puede hacer en tus cuentas. Los roles estándar cubren todas las cuentas, actuales y futuras, de modo que un miembro con Trade all podrá operar en cualquier cuenta que crees mañana.

Los perfiles y roles estándar evolucionan con el producto: cuando se añade un nuevo flujo de trabajo, los miembros que tengan uno asignado obtienen automáticamente el nivel correspondiente. 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 que recoge exactamente lo 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 el nombre de la etiqueta que tenías junto al miembro, de modo que un miembro etiquetado como "Trader" pasa a un rol llamado trader. Los miembros sin etiqueta pasan al rol migrated-role. Cada uno lleva una insignia migrated, lo que indica que el nombre fue generado automáticamente y puedes cambiarlo.

Por qué tus miembros "Admin" no están en el perfil Admin

La etiqueta "Admin" de Beta permitía ver, iniciar y aprobar, pero no completar las propias solicitudes sin una segunda aprobación. El perfil Admin sí incluye esa capacidad, que corresponde al nivel Execute.

En lugar de concederla automáticamente, los miembros con la etiqueta antigua pasan a un rol llamado beta-admin con exactamente los permisos que ya tenían. Puedes moverlos a Admin con una simple reasignación cuando lo decidas.

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

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

• Todos los permisos que tenía cada Miembro se transfieren íntegramente.
• Las credenciales de las claves de API, los permisos y la asignación de cuentas se conservan.
• Los balances, las cuentas y la titularidad de las cuentas no se modifican.
• Las solicitudes de aprobación en curso continúan, y tus políticas, umbrales de aprobación y el ajuste "requerir siempre aprobación" no cambian.
• La verificación de identidad no se ve afectada, y nadie tiene que volver a iniciar sesión ni a ser reinvitado.
• Solo se convierten las cuentas pertenecientes a tu Organización. Cualquier permiso sobre una cuenta externa a ella se mantiene tal como estaba.

Las llamadas sin account_id usan la cuenta principal de la Organización. Para consultar otra cuenta incluida en la asignación de cuentas de la clave, pasa el account_id de esa cuenta en la URL. Consulta "Elegir una cuenta específica cuando sea necesario".

La llamada creó una solicitud y bloqueó el importe en la cuenta de origen. La liquidación se produce tras la aprobación. Haz el seguimiento de la solicitud con el approval_request_id devuelto por la llamada, o búscala en la página Solicitudes. Consulta Transferencias y retiros.

Los Miembros cuyos permisos no coinciden con ningún perfil estándar necesitan un rol que preserve su acceso, y dos Miembros solo se fusionan en un único rol cuando sus permisos son idénticos. Los Miembros a los que habías asignado etiquetas distintas permanecen en roles separados aunque sus permisos coincidan, porque las etiquetas indican que la distinción era intencionada. Los roles innecesarios se pueden consolidar reasignando sus miembros y eliminando el rol vacío.

Los miembros que administran la organización (acceso del equipo, cuentas o claves API) se asignan a Leer todo, ya que administrar una cuenta implica poder verla. Si eso es más amplio de lo que necesitas, sustituye Leer todo por un rol de cuenta limitado a las cuentas concretas que requieran.

No. La conversión es unidireccional. Todo lo que genera es editable posteriormente, por lo que cualquier configuración de acceso anterior puede reconstruirse mediante perfiles y roles.