Migrar do Beta

As suas chaves API existentes não são revogadas nem reemitidas. As suas credenciais, permissões e mapeamento de contas são todos transferidos. O que muda é a forma como o seu código aborda os pedidos e lê as respostas.

Selecione uma conta em cada pedido

Uma chave API de Organização abrange uma ou mais Contas e não tem predefinição, pelo que cada pedido privado deve indicar a que Conta se aplica. Passe account_id como um parâmetro de consulta no URL, e não no corpo do pedido:

Isto aplica-se a negociações, consultas de saldo e extratos, histórico de ordens e negociações, exportações e movimentação de fundos.

Leia a nova resposta de levantamento

WithdrawFunds devolve approval_request_id juntamente com refid:

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

A automação que trata um refid como prova de conclusão irá reportar os levantamentos como liquidados enquanto estes ainda estiverem na fila de aprovação. Consulte chaves API para o modelo completo.

A 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 nas suas Contas. As funções padrão cobrem todas as Contas atuais e futuras, pelo que um Membro em Negociar tudo pode negociar numa Conta que criar amanhã.

Os perfis e funções padrão acompanham o produto: quando um novo fluxo de trabalho é adicionado, os Membros que possuem um adquirem 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 é colocado numa função que possui exatamente o que tinha. Os 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 que tinha escrito ao lado do Membro, por isso, um Membro rotulado como “Trader” entra numa função chamada trader. Os Membros sem etiqueta entram em migrated-role. Cada um possui um selo migrado, o que significa que o nome foi gerado e pode ser alterado por si.

Porque os seus Membros “Admin” não estão no perfil Admin

A etiqueta “Admin” da Beta permitia a alguém visualizar, iniciar e aprovar, mas não concluir os seus próprios pedidos sem uma segunda aprovação. O perfil Admin inclui essa capacidade, que é o nível Execute.

Em vez de conceder automaticamente, os Membros com a etiqueta antiga são colocados numa função chamada beta-admin que possui exatamente as permissões que já tinham. Movê-los para Admin é uma única atribuição sempre que decidir fazê-lo.

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

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

• Todas as permissões que cada Membro possuía são mantidas.
• As credenciais da chave API, permissões e mapeamento da Conta são preservados.
• Saldos, Contas e titularidade da Conta permanecem intocados.
• Os pedidos de aprovação já em curso continuam, e as suas políticas, limites de aprovação e definições de “sempre exigir aprovação” permanecem inalterados.
• A verificação de identidade não é afetada, e ninguém precisa de iniciar sessão novamente ou ser convidado de novo.
• Apenas as Contas pertencentes à sua Organização são convertidas. Uma permissão em qualquer Conta fora dela é mantida como está.

O pedido está quase certamente a faltar ao 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 account_id ao URL e verifique novamente todos os endpoints que a sua integração chama, não apenas aqueles que falharam visivelmente. Consulte Chaves de API.

A chamada criou um pedido e bloqueou o montante na Conta de origem. A liquidação segue a aprovação. Monitorize o pedido com o approval_request_id devolvido pela chamada, ou encontre-o na página Pedidos. Consulte Transferências e levantamentos.

Os Membros cujas permissões não correspondiam a um perfil padrão precisam cada um de uma função que preserve o seu acesso, e dois Membros são apenas combinados numa única função quando as suas permissões são idênticas. Os Membros a quem você tinha dado diferentes rótulos permanecem em funções separadas mesmo onde as 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 os seus 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 Read all, porque administrar uma Conta implica ser capaz de a ver. Se isso for mais abrangente do que você quer, substitua Read all por um Account Role com âmbito para as Contas específicas de que precisam.

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