Migrando do Beta

Última atualização: 20 de agosto de 2026

Este artigo é destinado a Organizações criadas no modelo de acesso Beta, em que um administrador concedia permissões a cada Membro individualmente. O acesso agora é configurado a partir de Perfis de Workflow e Funções de Conta, e a Kraken converte sua Organização automaticamente.

Dois pontos precisam da sua atenção antes da conversão:

  • Se você usa chaves de API, revise o comportamento delas na Organização. As chamadas existentes continuam operando na Conta primária. Use account_id para selecionar outra Conta e trate um saque bem-sucedido como uma solicitação, não como confirmação de que os fundos foram movimentados. Consulte «Revise o comportamento da sua API» abaixo.
  • Vamos pedir que você confirme que está pronto. Sua Organização não é convertida até que você aceite a mudança.

A conversão não remove nenhum acesso. Todas as permissões de cada Membro são mantidas.

Suas chaves de API existentes não são revogadas nem reemitidas. As credenciais, permissões e o mapeamento de Contas são todos preservados. As chamadas existentes que não informam account_id continuam operando na Conta primária da Organização. Revise como sua integração seleciona outra Conta e lê as respostas de saque.

Selecione uma Conta específica quando necessário

Quando account_id é omitido, uma solicitação privada opera na Conta primária:

bash

Bash

POST /0/private/AddOrder

Para operar em uma Conta específica, passe account_id como parâmetro de consulta na URL:

bash

Bash

POST /0/private/AddOrder?account_id=W5PB62NTPNYT6TYH

Passe-o na URL, não no corpo da solicitação. Um account_id explícito tem precedência sobre o fallback da conta principal. Isso não expande o mapeamento de Contas nem as permissões da chave.

Leia a nova resposta de Saque

WithdrawFunds retorna approval_request_id junto com refid:

bash

Bash

{
  "error": [],
  "result": {
    "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
    "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
  }
}
  • 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.
  • O approval_request_id é o identificador da aprovação que o saque aguarda. Guarde o identificador vinculado ao seu próprio registro.
  • Saques aguardando aprovação não aparecem em WithdrawStatus. Uma solicitação rejeitada ou que expira não gera nenhum registro de saque, portanto a ausência em WithdrawStatus nunca significa que o saque não foi enviado.

Automações que tratam um refid como confirmação de conclusão vão reportar saques como liquidados enquanto ainda estão na fila de aprovação. Consulte Chaves de API para o modelo completo.

Após a conversão, sua Organização passa a contar com dois conjuntos de blocos de configuração padrão.

Workflow Profiles

Um Workflow Profile define o que um Membro pode fazer em cada workflow gerenciado. Cada Membro possui exatamente um.

Perfil

O que inclui

Administrador

Todos os níveis em todos os workflows, incluindo Executar

Iniciador

Visualizar e Iniciar em todos os workflows. Não pode aprovar

Aprovador

Visualizar e Aprovar em todos os workflows. Não pode iniciar

Auditor

Visualizar em todos os workflows. Não pode agir

Gerente de Fundos

Visualizar, Iniciar e Aprovar em Solicitação de Saque e Solicitação de Transferência. Visualizar e Iniciar em Gerenciar Endereços

Account Roles

Um Account Role define o que um Membro pode fazer nas suas Contas. Os perfis padrão abrangem todas as Contas, atuais e futuras, de forma que um Membro com Trade all pode negociar em uma Conta criada amanhã.

Função

O que concede em todas as Contas

Ler tudo

Leia

Negociar tudo

Negociação

Fundos total

Transferência, Sacar, Earn Alocar, Earn Desalocar

Acesso total

Todas as permissões da Conta

Os perfis e funções padrão acompanham o produto: quando um novo fluxo de trabalho é adicionado, os Membros que possuem um deles recebem o nível adequado automaticamente. Consulte Funções, perfis e permissões para ver 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 com exatamente o que já tinha. Membros com permissões idênticas compartilham uma única função, portanto sua Organização terá muito menos funções do que Membros.

Essas funções recebem o nome do rótulo escrito ao lado do Membro; por isso, 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 recebe um badge migrated, o que significa que o nome foi gerado automaticamente e você pode alterá-lo.

Dica:

Renomear essas funções para refletir como você realmente chama essas pessoas é a melhor primeira tarefa após a conversão. Editar uma função remove o badge migrated.

Por que seus Membros "Admin" não estão no perfil Admin

O rótulo "Admin" do Beta permitia visualizar, iniciar e aprovar, mas não concluir solicitações próprias sem uma segunda aprovação. O perfil Admin inclui essa capacidade, que corresponde ao nível Execute.

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

Observação:

beta-admin é uma das suas próprias funções, portanto os Membros que a possuem não receberão novos fluxos de trabalho automaticamente como acontece com os perfis padrão. Esse é mais um motivo para revisar essas funções logo após a conversão.

O Proprietário é atribuído ao perfil Admin, mantém todas as permissões anteriores e passa a receber novos fluxos de trabalho automaticamente. O Proprietário também possui a função Ler tudo, que não pode ser removida.

Se você tiver reduzido deliberadamente as permissões do Proprietário, essa decisão é preservada: o Proprietário é convertido em uma função com as permissões que ele realmente tinha, como qualquer outro Membro.

  • Todas as permissões de cada Membro são mantidas.
  • As credenciais das chaves de API, as permissões e o mapeamento de Contas são preservados.
  • Saldos, Contas e propriedade de Contas permanecem intactos.
  • Solicitações de aprovação em andamento continuam, e suas políticas, limites de aprovação e configurações de «sempre exigir aprovação» permanecem inalteradas.
  • A verificação de identidade não é afetada, e ninguém precisa entrar novamente nem ser reconvidado.
  • Apenas as Contas pertencentes à sua Organização são convertidas. Qualquer permissão em uma Conta fora dela permanece como está.

Solução de problemas

Chamadas sem account_id usam a Conta principal da Organização. Para consultar outra Conta no mapeamento de Contas da chave, passe o account_id dessa Conta na URL. Consulte «Escolher uma Conta específica quando necessário».

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

Membros cujas permissões não correspondem a um perfil padrão precisam, cada um, de uma função que preserve seus acessos. Dois Membros só são agrupados em uma única função quando suas permissões são idênticas. Membros com rótulos diferentes permanecem em funções separadas mesmo quando suas permissões coincidem, pois os rótulos indicam que a distinção foi intencional. Funções desnecessárias podem ser consolidadas reatribuindo os Membros e excluindo a função vazia.

Os membros que administram a Organização, gerenciando o acesso da equipe, Contas ou chaves de API, são colocados em Ler tudo, pois administrar uma Conta implica poder visualizá-la. Se isso for mais amplo do que você deseja, substitua Ler tudo por um Cargo de Conta limitado às Contas específicas de que precisam.

Não. A conversão é unidirecional. Tudo o que ela produz pode ser editado posteriormente, portanto qualquer configuração de acesso que você tinha pode ser recriada usando perfis e cargos.

Artigos relacionados