Transição do Beta

Suas chaves de API existentes não são revogadas ou reemitidas. Suas credenciais, permissões e mapeamento de conta são todos transferidos. O que muda é como seu código aborda as solicitações e lê as respostas.

Selecione uma conta em cada solicitação

Uma chave de API da Organização abrange uma ou mais Contas e não tem padrão, então cada solicitação privada deve indicar a qual Conta ela se aplica. Passe account_id como um parâmetro de consulta na URL, não no corpo da solicitação:

Isso se aplica a negociação, consultas de saldo e razão contábil, histórico de ordens e negociações, exportações e movimentação de fundos.

Leia a nova resposta de saque

WithdrawFunds retorna approval_request_id juntamente com refid:

• Um refid não significa mais que o saque foi concluído. O valor é bloqueado na Conta de origem quando a solicitação é enviada, e só é liquidado após a aprovação da solicitação.
• approval_request_id é o identificador para a aprovação que o saque está aguardando. Armazene-o em seu próprio registro.
• Saques aguardando aprovação não aparecem em WithdrawStatus. Uma solicitação rejeitada ou expirada não cria nenhum registro de saque, portanto, a ausência em WithdrawStatus nunca significa que um saque não foi enviado.

A automação que trata um refid como prova de conclusão relatará os saques como liquidados enquanto ainda estão na fila de aprovação. Consulte Chaves de API para o modelo completo.

Sua Organização sai da conversão com dois conjuntos de blocos de construção padrão.

Perfis de Fluxo de Trabalho

Um Perfil de Fluxo de Trabalho define o que um Membro pode fazer em cada fluxo de trabalho governado. Cada Membro possui exatamente um.

Funções de Conta

Uma Função de Conta define o que um Membro pode fazer em suas Contas. As funções padrão cobrem todas as Contas atuais e futuras, então um Membro com acesso a 'Negociar tudo' pode negociar em uma Conta que você criar amanhã.

Os perfis e funções padrão acompanham o produto: quando um novo fluxo de trabalho é adicionado, os Membros que possuem um deles obtêm o nível apropriado automaticamente. Consulte Funções, perfis e permissões para o modelo completo.

Quando as permissões de um Membro não correspondem a nenhum perfil padrão, ele é atribuído a uma função que contém exatamente o que ele tinha. Membros com permissões idênticas compartilham uma única função, então sua Organização terá muito menos funções do que Membros.

Essas funções recebem o nome do rótulo que você havia escrito ao lado do Membro, então um Membro rotulado como “Trader” é atribuído a uma função chamada trader. Membros sem rótulo são atribuídos a migrated-role. Cada um possui um selo migrado, o que significa que o nome foi gerado e está disponível para ser alterado por você.

Por que seus Membros “Admin” não estão no perfil Admin

O rótulo “Admin” do Beta permitia que alguém visualizasse, iniciasse e aprovasse, mas não concluísse suas próprias solicitações sem uma segunda aprovação. O perfil Admin inclui essa capacidade, que é o nível Executar.

Em vez de conceder automaticamente, os Membros com o rótulo antigo são atribuídos a uma função chamada beta-admin contendo exatamente as permissões que já possuíam. Movê-los para Admin é uma única atribuição sempre que você decidir fazê-lo.

O Proprietário é colocado no perfil Admin, mantém tudo o que tinha e recebe novos fluxos de trabalho automaticamente. O Proprietário também possui a permissão 'Ler tudo', que não pode ser removida.

Se você havia reduzido deliberadamente as permissões do Proprietário, essa decisão é preservada: o Proprietário é convertido em uma função que contém suas permissões reais, como qualquer outro Membro.

• Cada permissão que cada Membro detinha é mantida.
• Credenciais de chave API, permissões e mapeamento de Conta são preservados.
• Saldos, Contas e titularidade da Conta não são alterados.
• Solicitações de aprovação já em andamento continuam, e suas políticas, limites de aprovação e configurações de “sempre exigir aprovação” permanecem inalterados.
• A verificação de identidade não é afetada, e ninguém precisa fazer login novamente ou ser convidado novamente.
• Apenas Contas pertencentes à sua Organização são convertidas. Uma permissão em qualquer Conta fora dela permanece como está.

A solicitação está quase certamente sem o account_id. Sem ele, uma chamada privada não se resolve para uma das Contas da chave e pode responder com um resultado vazio em vez de um erro. Adicione o account_id ao URL e verifique novamente cada endpoint que sua integração chama, não apenas aqueles que falharam visivelmente. Consulte Chaves de API.

A chamada criou uma solicitação e bloqueou o valor na Conta de origem. A liquidação segue a aprovação. Rastreie a solicitação com o approval_request_id retornado pela chamada, ou encontre-a na página de Solicitações. Consulte Transferências e saques.

Membros cujas permissões não correspondiam a um perfil padrão precisam de uma função que preserve seu acesso, e dois Membros são mesclados em uma única função apenas quando suas permissões são idênticas. Membros aos quais você havia atribuído rótulos diferentes permanecem em funções separadas, mesmo quando suas permissões correspondem, porque os rótulos sugerem que a distinção foi intencional. As funções de que você não precisa podem ser consolidadas reatribuindo seus Membros e excluindo a função vazia.

Membros que administram a Organização, gerenciando o acesso da equipe, Contas ou chaves de API, são colocados em Read all, porque administrar uma Conta implica ser capaz de vê-la. Se isso for mais amplo do que você deseja, substitua Read all por uma Função de Conta com escopo para as Contas específicas de que eles precisam.

Não. A conversão é unidirecional. Tudo o que ela produz é editável depois, então qualquer arranjo de acesso que você tinha pode ser reconstruído usando perfis e funções.