Moving from Beta

Your existing API keys are not revoked or reissued. Their credentials, permissions, and Account mapping all carry over. Existing calls that do not pass account_id continue on the Organization's primary Account. Review how your integration selects another Account and reads withdrawal responses.

Choose a specific Account when needed

When account_id is omitted, a private request operates on the primary Account:

To operate on a specific Account, pass account_id as a query parameter on the URL:

Pass it on the URL, not in the request body. An explicit account_id takes precedence over the primary-account fallback. It does not expand the key's Account mapping or permissions.

Read the new withdrawal response

WithdrawFunds returns approval_request_id alongside refid:

• A refid no longer means the withdrawal completed. The amount is locked on the source Account when the request is submitted, and it settles only after the request is approved.
• approval_request_id is the handle for the approval the withdrawal is waiting on. Store it against your own record.
• Withdrawals awaiting approval do not appear in WithdrawStatus. A request that is rejected or expires creates no withdrawal record at all, so absence from WithdrawStatus never means a withdrawal was not submitted.

Automation that treats a refid as proof of completion will report withdrawals as settled while they are still in the approval queue. See API keys for the full model.

Your Organization comes out of the conversion with two sets of standard building blocks.

Workflow Profiles

A Workflow Profile sets what a Member can do on each governed workflow. Each Member holds exactly one.

Account Roles

An Account Role sets what a Member can do on your Accounts. The standard roles cover all current and future Accounts, so a Member on Trade all can trade on an Account you create tomorrow.

Standard profiles and roles keep pace with the product: when a new workflow is added, Members holding one pick up the appropriate level automatically. See Roles, profiles, and permissions for the complete model.

Where a Member's permissions match no standard profile, they are placed on a role carrying exactly what they had. Members with identical permissions share a single role, so your Organization will have far fewer roles than Members.

These roles take their name from the label you had written beside the Member, so a Member labeled “Trader” lands on a role called trader. Members with no label land on migrated-role. Each one carries a migrated badge, which means the name was generated and is yours to change.

Why your “Admin” Members are not on the Admin profile

The Beta “Admin” label let someone view, initiate, and approve, but not complete their own requests without a second approval. The Admin profile does include that ability, which is the Execute level.

Rather than granting it automatically, Members with the old label are placed on a role named beta-admin holding exactly the permissions they already had. Moving them to Admin is a single assignment whenever you decide to.

The Owner is placed on the Admin profile, keeps everything they had, and picks up new workflows automatically. The Owner also holds Read all, which cannot be removed.

If you had deliberately reduced the Owner's permissions, that decision is preserved: the Owner converts into a role holding their actual permissions, like any other Member.

• Every permission each Member held is carried across.
• API key credentials, permissions, and Account mapping are preserved.
• Balances, Accounts, and Account ownership are untouched.
• Approval requests already in flight continue, and your policies, approval thresholds, and “always require approval” settings are unchanged.
• Identity verification is unaffected, and no one needs to sign in again or be re-invited.
• Only Accounts belonging to your Organization are converted. A permission on any Account outside it is left as it is.

Calls without account_id use the Organization's primary Account. To report on another Account in the key's Account mapping, pass that Account's account_id on the URL. See “Choose a specific account when needed.”

The call created a request and locked the amount on the source Account. Settlement follows approval. Track the request with the approval_request_id returned by the call, or find it on the Requests page. See Transfers and withdrawals.

Members whose permissions did not match a standard profile each need a role that preserves their access, and two Members are only merged onto one role when their permissions are identical. Members you had given different labels stay on separate roles even where their permissions match, because the labels suggest the distinction was intentional. Roles you do not need can be consolidated by reassigning their Members and deleting the empty role.

Members who administer the Organization, managing team access, Accounts, or API keys, are placed in Read all, because administering an Account implies being able to see it. If that is broader than you want, replace Read all with an Account Role scoped to the specific Accounts they need.

No. The conversion is one-way. Everything it produces is editable afterwards, so any access arrangement you had can be rebuilt using profiles and roles.