As chaves de API concedem acesso programático às contas da Organização a sistemas automatizados, bots de negociação, scripts operacionais, pipelines de relatórios e sessões de negociação FIX. Este artigo aborda o modelo de permissões das chaves de API, a forma como as chaves se mapeiam para contas, a aplicação da governação da Organização às operações iniciadas por chaves e a própria administração das chaves.
As chaves de API não são Membros com credenciais. Têm o seu próprio modelo de permissões, mais simples:
Membro | Chave de API | |
|---|---|---|
Autenticação | Início de sessão individual com 2FA | Credenciais da chave de API |
Acesso à interface | Sim | Não, apenas via API |
Modelo de permissões | Perfil de fluxo de trabalho + Funções de Conta | Permissões da chave de API aplicadas às contas selecionadas |
Variação por conta | Sim, as funções podem conceder permissões diferentes em contas diferentes | Não, as permissões da chave aplicam-se de forma uniforme a todas as contas selecionadas |
Pode iniciar pedidos de levantamento e transferência | Sim, quando permitido | Sim, quando permitido |
Pode aprovar pedidos | Sim, exceto os próprios | Nunca |
Fluxos de trabalho administrativos | Sim, conforme o respetivo Perfil de Fluxo de Trabalho | Nunca |
Os dois modelos são deliberadamente distintos. Os Membros têm funções, perfis e granularidade por conta porque os humanos acumulam responsabilidades variadas. As Chaves seguem um modelo simples de âmbito e contas porque a automatização deve ser restrita, uniforme e fácil de auditar.
Uma chave de API combina duas seleções: o que pode fazer (as suas permissões) e onde (as suas contas).
Permissões
Agrupar | Permissão | O que permite |
|---|---|---|
Fundos | Consultar fundos | Ver saldos e estado do financiamento |
Depositar | Gerar endereços de depósito e consultar o histórico de depósitos | |
Levantar | Iniciar pedidos de levantamento (consulte «Governação e chaves de API») | |
Ganhos | Alocar e desalocar produtos Earn | |
Ordens | Consultar ordens em aberto | Ver ordens em aberto e negociações ativas |
Consultar ordens fechadas | Ver histórico de ordens e negociações concluídas | |
Criar e modificar ordens | Colocar e modificar ordens | |
Cancelar e fechar ordens | Cancelar ordens em aberto e fechar posições | |
Endereços | Adicionar endereço de levantamento | Iniciar pedidos para adicionar endereços na lista de permissões |
Atualizar o endereço de levantamento | Iniciar pedidos para alterar endereços na lista de permissões | |
Dados | Consultar livro-razão | Ver histórico de transações e do livro-razão |
Exportar dados | Exportar dados da conta para reporte e reconciliação |
Mapeamento de contas
Cada chave é mapeada para uma ou mais contas, definidas no momento da criação e editáveis posteriormente. As permissões da chave aplicam-se de forma uniforme a todas as contas selecionadas:
Conectividade FIX
As chaves com permissões de ordens suportam conectividade FIX para negociação à vista, em conjunto com as APIs REST e WebSocket. Uma sessão FIX herda as permissões e o mapeamento de contas da chave associada: negoceia apenas nas contas selecionadas, dentro das permissões definidas. As empresas com fluxo de ordens FIX dedicam normalmente uma chave por sessão, circunscrita às contas da mesa de negociação correspondente.
A negociação via WebSocket em contas que não a conta principal ainda não está disponível para chaves de API — por enquanto, é uma funcionalidade exclusiva do Proprietário. O fluxo automatizado de ordens em contas adicionais deve utilizar REST ou FIX. Consulte Disponibilidade e limitações.
Definições de segurança
Configuração | Descrição |
|---|---|
Validade da chave | Data opcional a partir da qual a chave deixa de funcionar |
Data de início/fim das consultas | Limitar consultas de dados a um intervalo de datas |
Ligações WebSocket | Ativar ou desativar a transmissão em tempo real |
Janela de valor aleatório personalizada | Ajuste da proteção contra repetição de pedidos para utilização de alta frequência |
Restrições de IP | Limitar a utilização da chave a endereços IP ou intervalos CIDR específicos |
Atribua a cada chave as permissões mínimas, o menor número de contas e as restrições de IP mais estritas que lhe permitam cumprir a sua função. Atribua uma chave por sistema — uma para o bot de negociação, outra para relatórios — e mantenha a revogação precisa e direcionada.
A governação da Organização aplica-se ao que as chaves fazem e à forma como são geridas.
O que as chaves fazem
A regra das duas categorias para os Membros aplica-se igualmente às chaves:
Uma chave só pode iniciar pedidos governados. As chaves nunca detêm permissão de aprovação: a segregação de funções exige um Membro humano para cada aprovação, e um script não pode substituir esse critério. Quando a política de Pedido de Levantamento exige duas aprovações, um levantamento iniciado por uma chave aguarda dois Membros, exatamente como um iniciado por um Membro.
Construa a automação em torno dessa assincronicidade: uma chamada de API bem-sucedida significa que o pedido foi criado, não que os fundos foram transferidos. Monitorize o pedido até à sua conclusão e considere a limitação atual de que um pedido pendente não reserva fundos: se o saldo se alterar durante a revisão, o pedido aprovado falha e terá de ser submetido novamente. Consulte Manter os fundos disponíveis até à aprovação.
As chaves também não têm acesso aos fluxos de trabalho administrativos. A gestão do acesso da equipa, de chaves API, de contas, de endereços (para além de iniciar pedidos de endereço) e de políticas é exclusiva dos Membros.
Como as chaves são geridas
Criar, editar e revogar chaves API é uma operação governada no âmbito do fluxo de trabalho dedicado Gerir Chaves API, separado de Gerir Equipa e Acesso. Esta separação tem duas implicações:
O segredo da chave é apresentado uma única vez, no momento da criação. Guarde-o em segurança antes de sair do ecrã; não será possível recuperá-lo posteriormente.
A edição das permissões ou contas de uma chave, bem como a sua revogação, seguem o mesmo processo de governação.
A chamada criou um pedido de levantamento que a política de Pedidos de Levantamento está a reter para aprovação. Consulte a página de Pedidos — o pedido aparece aí com a chave como iniciador, a aguardar as aprovações necessárias dos Membros. É o modelo de governação a funcionar como previsto: a automação propõe, os humanos aprovam.
Se o pedido foi aprovado e os fundos não foram movimentados, verifique se o saldo de origem cobria o montante no momento da conclusão. Um pedido pendente não reserva fundos, pelo que atividade durante a revisão pode fazer com que um pedido aprovado falhe. Resubmeta assim que o saldo estiver disponível.
A conta em falha não está incluída no mapeamento de contas da chave. Uma chave opera apenas nas contas selecionadas. Edite a chave para adicionar a conta, tendo em atenção que o conjunto completo de permissões da chave passará a aplicar-se nessa conta, uma vez que as chaves não permitem variação por conta. Se for demasiado abrangente, crie uma segunda chave limitada à nova conta.
Uma única chave não pode ter permissões diferentes por conta. Crie duas chaves: uma chave de negociação associada à conta A e uma chave só de leitura associada à conta B. Chaves com âmbito mais restrito são também mais fáceis de auditar e mais seguras de revogar.
O fluxo de trabalho Gerir Chaves de API provavelmente requer aprovação, e o pedido ainda está pendente. A chave é emitida, e o seu segredo apresentado, apenas após a recolha das aprovações necessárias. Verifique o estado do pedido na página Pedidos.
Não. A aprovação exige sempre um membro humano. Esta é uma regra do sistema, não uma política configurável – é o que torna a aprovação multi-partes significativa quando a automatização inicia movimentos de fundos.