Migração do modelo Beta

As chaves de API existentes não são revogadas nem reemitidas. As respetivas credenciais, permissões e mapeamento de Contas são preservados. As chamadas existentes que não passem account_id continuam a operar na Conta principal da Organização. Reveja como a sua integração seleciona outra Conta e lê as respostas de levantamento.

Selecionar uma Conta específica quando necessário

Quando account_id é omitido, um pedido privado opera na Conta principal:

Para operar numa Conta específica, passe account_id como parâmetro de consulta no URL:

Passe-o no URL, não no corpo do pedido. Um account_id explícito tem precedência sobre a conta principal por defeito. Não expande o mapeamento de Contas nem as permissões da chave.

Leia a nova resposta de levantamento

WithdrawFunds devolve approval_request_id juntamente com refid:

• Um refid já não indica que o levantamento foi concluído. O montante é bloqueado na Conta de origem quando o pedido é submetido e só é liquidado após aprovação.
• O approval_request_id é o identificador da aprovação que o levantamento aguarda. Guarde-o juntamente com o seu próprio registo.
• Os levantamentos a aguardar aprovação não aparecem em WithdrawStatus. Um pedido rejeitado ou expirado não gera qualquer registo de levantamento, pelo que a ausência de WithdrawStatus nunca significa que o levantamento não foi submetido.

Qualquer automatização que trate um refid como prova de conclusão reportará levantamentos como liquidados enquanto ainda estão na fila de aprovação. Consulte Chaves de API para o modelo completo.

Após a conversão, a sua Organização fica com dois conjuntos de componentes padrão.

Workflow Profiles

Um Workflow Profile define o que um Membro pode fazer em cada fluxo de trabalho gerido. Cada Membro possui exatamente um.

Funções de conta

Uma Função de conta define o que um Membro pode fazer nas suas Contas. As funções padrão abrangem todas as Contas atuais e futuras, pelo que um Membro com a função «Trade all» pode negociar em qualquer Conta criada amanhã.

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

Quando as permissões de um Membro não correspondem a nenhum perfil padrão, é-lhe atribuída uma função com exatamente as permissões que já tinha. Membros com permissões idênticas partilham uma única função, pelo que a sua Organização terá muito menos funções do que Membros.

Estas funções recebem o nome da etiqueta associada ao Membro — por exemplo, um Membro com a etiqueta «Trader» fica numa função chamada trader. Os Membros sem etiqueta ficam em migrated-role. Cada uma tem um distintivo migrated, o que significa que o nome foi gerado automaticamente e pode ser alterado.

Por que razão os seus Membros «Admin» não estão no perfil Admin

A etiqueta «Admin» do Beta permitia visualizar, iniciar e aprovar pedidos, mas não concluir os seus próprios pedidos sem uma segunda aprovação. O perfil Admin inclui essa capacidade, que corresponde ao nível Executar.

Em vez de a conceder automaticamente, os Membros com a etiqueta antiga são colocados numa função denominada beta-admin com exatamente as permissões que já tinham. A passagem para Admin é uma atribuição única, a fazer quando entender.

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

Se tiver reduzido deliberadamente as permissões do Proprietário, essa decisão é preservada: o Proprietário passa a deter uma função com as suas permissões reais, como qualquer outro Membro.

• Todas as permissões de cada Membro são preservadas.
• As credenciais das chaves de API, as permissões e o mapeamento de Contas são mantidos.
• Os saldos, as Contas e a respetiva titularidade não são alterados.
• Os pedidos de aprovação já em curso continuam, e as suas políticas, limites de aprovação e definições de «exigir sempre aprovação» mantêm-se inalterados.
• A verificação de identidade não é afetada, e ninguém precisa de iniciar sessão novamente nem de ser reconvidado.
• Apenas as Contas da sua Organização são convertidas. As permissões em Contas externas à Organização são mantidas sem alterações.

As chamadas sem account_id utilizam a Conta principal da Organização. Para consultar outra Conta no mapeamento de Contas da chave, passe o account_id dessa Conta no URL. Consulte «Selecionar uma conta específica quando necessário».

A chamada criou um pedido e bloqueou o montante na Conta de origem. A liquidação ocorre após aprovação. Acompanhe o pedido com o approval_request_id devolvido pela chamada ou localize-o na página de Pedidos. Consulte Transferências e levantamentos.

Os membros cujas permissões não correspondem a um perfil padrão necessitam cada um de uma função que preserve os seus acessos; dois membros só são agrupados numa única função quando as suas permissões são idênticas. Os membros a quem foram atribuídas etiquetas diferentes permanecem em funções separadas mesmo quando as permissões coincidem, pois as etiquetas sugerem que a distinção foi intencional. As funções de que não necessita podem ser consolidadas reatribuindo os respetivos membros e eliminando a função vazia.

Os membros que administram a Organização – gerindo o acesso da equipa, Contas ou chaves de API – são colocados em Ler tudo, porque administrar uma Conta implica poder vê-la. Se isso for mais abrangente do que pretende, substitua Ler tudo por uma Função de Conta com âmbito restrito às Contas específicas de que necessitam.

Não. A conversão é irreversível. Todos os resultados da conversão são editáveis posteriormente, pelo que qualquer configuração de acesso existente pode ser recriada com perfis e funções.