API Kalshi: dados públicos, fluxos ou acesso à conta

Por PredictionToolkit · Publicado em 2026-11-03 · Atualizado em 2026-11-03

Um navegador de mercados e um mecanismo de ordens não precisam do mesmo acesso. Defina primeiro dados e ações e escolha a API nativa da Kalshi ou uma camada compatível com as credenciais, o ambiente e o modelo operacional adequados.

Escolha a API de contratos de eventos

A documentação da Kalshi separa as APIs Predictions para contratos de eventos das APIs Perps para futuros perpétuos. Para mercados de previsão, comece por Predictions. O guia REST público consulta séries, eventos, mercados e livros sem autenticação; isso não estabelece acesso anônimo a dados de conta nem ao envio de ordens.

Ajuste as credenciais à interface

• Consultas REST de mercados públicos: use os endpoints documentados de descoberta e snapshots do livro.
• WebSocket: autentique a conexão inicial mesmo ao assinar canais de dados públicos; esses canais não acrescentam outra verificação de autorização por canal.
• Operações de conta e negociação: use as solicitações assinadas exigidas e as capacidades permitidas da conta.

O guia atual de chaves aceita Ed25519 e RSA-PSS. Escolha um tipo compatível com a versão real do cliente, em vez de copiar um exemplo antigo limitado a RSA. O ID da chave identifica a chave registrada; a chave privada assina solicitações. Mantenha a chave privada fora dos pacotes enviados ao navegador, repositórios públicos e logs, e consulte o guia oficial para assinar o método e o caminho exatos.

Separe demo e produção

Os hosts REST recomendados são external-api.kalshi.com para produção e external-api.demo.kalshi.co para demo, com /trade-api/v2 como caminho base. As chaves de demo e produção não são intercambiáveis. Comece o desenvolvimento dependente de conta em demo e confira explicitamente o ambiente antes de ativar uma ação em produção. Um resultado de demo não valida liquidez nem execução reais.

Cliente direto, camada local ou serviço hospedado?

A integração direta mantém visíveis os identificadores e contratos de API próprios da Kalshi. O PMXT oferece uma interface SDK comum quando a plataforma implementa a capacidade. No modo auto-hospedado, o pmxt-core local se conecta à plataforma e usa suas credenciais nativas quando necessário. O PMXT hospedado usa sua própria chave e infraestrutura; as operações de escrita hospedadas documentadas usam custódia PreFundedEscrow. Compare métodos e custódia do modo escolhido, não apenas nomes de funções do SDK.

Construa primeiro um fluxo de dados delimitado

• Identifique a série, o evento e o ticker do mercado e preserve as regras exatas. O nome de um evento não é o identificador de um mercado executável.
• Consulte uma pequena amostra de mercados e livros e preserve horários, unidades de preço e quantidade disponível antes de criar um gráfico ou comparação.
• Nos fluxos, trate perda de conexão e recuperação do estado; uma conexão aberta, por si só, não comprova dados atuais utilizáveis.
• Confira os limites e custos de endpoints atuais da conta e aplique espera progressiva diante de respostas HTTP 429.
• Revise permissões e semântica de ordens separadamente de uma consulta pública bem-sucedida.

Separe capacidade e dinheiro no orçamento

A Kalshi documenta orçamentos de solicitações baseados em tokens, com orçamentos de leitura e escrita separados. Aqui os tokens medem capacidade da API; uma quantidade de solicitações por segundo de um exemplo antigo não é uma cota universal. Confira custos e níveis atuais. O plano de um provedor hospedado, sua infraestrutura e as taxas de negociação são categorias de custo distintas.

As fontes abaixo foram analisadas para as decisões de acesso deste guia. Não foi criada chave, conectada conta nem enviada ordem. Use os perfis vinculados para comparar interfaces e as referências oficiais para confirmar o endpoint e as permissões exatos antes de implementar.