A negociação pela API da Polymarket liga uma decisão de negociação a uma sequência de pedidos, estados de ordens, registos de negociações e mudanças da conta. A unidade útil de compreensão é um ciclo de vida autenticado da ordem. Um programa que submete com sucesso um pedido concluiu apenas uma parte do trabalho; ainda precisa de estabelecer o que aconteceu e que exposição resta.
Este guia diz respeito ao contexto da API da Polymarket International. A Polymarket US tem um contexto separado de plataforma e conta, pelo que as suas interfaces e permissões devem ser revistas separadamente. A documentação atual também importa: mecanismos de carteiras, bibliotecas de clientes e pormenores das garantias podem mudar, tornando um exemplo antigo uma especificação pouco fiável para uma nova integração.
O cenário abaixo utiliza preços, quantidades e comissões inventados para explicar um ciclo de vida. Não executa uma negociação nem prescreve um investimento. Os princípios de conceção aplicam-se a revisão manual, ferramentas supervisionadas e processos automatizados autorizados, com o titular da conta a manter controlo sobre as ações que um programa pode realizar.
Comece a negociação pela API da Polymarket com um registo do contrato
O primeiro registo deve identificar o instrumento efetivo. Preserve o mercado, o token de resultado, o lado selecionado, as regras completas e os prazos relevantes. Um título, por si só, não consegue distinguir de forma fiável contratos com nomes semelhantes, e um identificador de token sem o seu significado é difícil de verificar por um revisor humano.
Imagine um mercado binário inventado sobre se uma licença é emitida até uma data especificada. A compra pretendida é o resultado Sim dessa pergunta exata. Um mercado relacionado sobre a construção começar mais tarde é um instrumento diferente, mesmo que os dois títulos partilhem a maioria das palavras.
O guia anterior de API de negociação da Polymarket separa dados de mercado, ordens e informação da conta. A descoberta de contratos pertence à primeira parte dessa estrutura. Antes de qualquer pedido privado, a integração deve conseguir mostrar ao leitor que resultado pretende negociar e por que esse identificador corresponde à decisão de investigação.
Utilize a interface atual de integração
Um cliente de API deve estar ligado a uma versão documentada e a um conjunto conhecido de operações suportadas. Não pressuponha que um nome antigo de pacote, exemplo de carteira ou formato de pedido continua atual por aparecer num tutorial. Verifique em conjunto a documentação oficial e a biblioteca instalada.
A visão geral atual da negociação da Polymarket descreve liquidação que envolve pUSD e tokens de resultados. Uma integração deve, por isso, evitar fixar no código um pressuposto antigo de garantias para todas as operações da conta. Financiamento, autorizações, negociação e resgate podem envolver registos diferentes que merecem as suas próprias verificações atuais.
Registe a data de revisão da documentação e a versão do cliente utilizada pela aplicação. Quando qualquer uma mudar, repita os casos de aceitação que dependem de assinaturas, codificação de montantes e interpretação de estados. Um pedido bem-sucedido de dados de mercado não estabelece que o percurso autenticado de negociação é compatível com a mesma versão.
Identifique o signatário e a carteira da conta
O endereço que assina um pedido e a carteira da conta que detém fundos ou posições não são necessariamente intercambiáveis em todos os mecanismos de carteiras. A integração tem de estabelecer a sua relação utilizando a configuração atual da conta. Inferi-la de um formato familiar de endereço pode produzir falhas de autorização ou confusão de contas.
Apresente o contexto esperado da conta antes de ativar a negociação. Uma revisão útil inclui a plataforma, a identidade da carteira, as permissões suportadas e se as leituras privadas atuais correspondem à conta pretendida. Isto dá ao operador uma forma de detetar uma configuração tecnicamente válida, mas ligada à conta errada.
O guia oficial de carteiras e autenticação é o ponto de partida apropriado para a configuração atual específica da carteira. Mantenha material secreto fora dos registos comuns e dos registos apresentados ao utilizador. O diário do ciclo de vida precisa de identificadores e provas de autorização, não de cópias de chaves privadas ou credenciais reutilizáveis.
Separe autenticação do pedido de autorização da ordem
A autenticação estabelece que conta ou credencial está a fazer um pedido privado. A autorização da ordem estabelece a própria instrução assinada de negociação. A distinção importa porque um invólucro válido do pedido não justifica mudar as condições económicas dentro de uma ordem.
A documentação da API da Polymarket descreve configuração de credenciais baseada em carteira e pedidos autenticados ao CLOB, com uma assinatura separada da carteira a autorizar uma ordem. Uma integração deve seguir os requisitos atuais de assinatura, em vez de tratar todas as assinaturas como um token genérico.
Ao nível da aplicação, preserve o preço, a quantidade, o lado e o tempo de vida aprovados antes de assinar. Se alguma dessas condições mudar, o programa deve tratar o resultado como uma instrução alterada que exige as verificações aplicáveis de autorização. Uma função auxiliar que repete o transporte não pode alargar silenciosamente o limite de preço ou aumentar a quantidade para obter uma resposta bem-sucedida.
Leia as restrições do mercado antes de construir a ordem
Uma ordem válida tem de caber nas restrições atuais do mercado, incluindo incrementos de preço e requisitos de quantidade. São propriedades para ler e verificar, não valores para copiar permanentemente de um exemplo sem relação. Uma mudança das restrições pode invalidar uma instrução que, de outra forma, faria sentido.
Utilize aritmética decimal e unidades explícitas ao traduzir uma decisão humana em montantes do pedido. Preço por unidade, número de unidades e custo total em garantias são quantidades diferentes. Um campo que contém uma nunca deve ser aceite num campo que espera outra apenas porque ambas são representadas como números ou cadeias de texto.
O guia oficial de colocação de ordens documenta o percurso atual de construção. Para um processo geral, a verificação essencial de aceitação é que a ordem codificada pode ser descodificada de volta para as condições económicas exatas que o utilizador aprovou, depois de qualquer arredondamento necessário ter sido tornado visível e revisto.
Inspecione o livro para a dimensão pretendida
Um limite de preço define o que a conta está disposta a pagar ou receber. Não promete que a quantidade pretendida será negociada. Antes de construir uma ordem imediata, inspecione a profundidade disponível dentro desse limite e preserve a hora de observação utilizada pela decisão.
Suponha que o livro inventado oferece dez unidades a 0,41 $ e vinte a 0,44 $. Comprar trinta custaria 4,10 $ mais 8,80 $, ou 12,90 $ antes de comissões se essas cotações continuarem disponíveis. Uma ordem limitada de compra de trinta unidades a 0,44 $ permite no máximo 13,20 $ de preço de compra, excluindo comissões aplicáveis.
A diferença entre custo esperado do livro e custo máximo autorizado é útil. O primeiro descreve a oportunidade observada; o segundo delimita a ordem. Nenhum garante a execução final. As cotações podem mudar depois da inspeção, e uma ordem pode ser rejeitada ou parcialmente executada segundo o seu tipo e as condições atuais do mercado.
Escolha deliberadamente a política do remanescente
O tipo de ordem determina o que acontece quando a quantidade pedida completa não consegue ser executada imediatamente. Uma ordem em espera pode deixar um compromisso não executado no livro. Uma instrução de execução parcial imediata pode terminar com uma posição e sem remanescente ativo. São estados diferentes da conta.
A documentação atual da Polymarket distingue FOK, que exige execução imediata completa ou cancelamento, de FAK, que executa a quantidade disponível e cancela o resto. Uma execução parcial FAK não deixa, portanto, a parte não executada em espera. GTC e GTD têm os seus próprios comportamentos de persistência ou expiração.
O guia anterior de automação de ordens limitadas da Polymarket explica por que tempo de vida e execuções têm de ser considerados em conjunto. Declare a política pretendida do remanescente no registo da intenção da ordem para que a conciliação posterior possa comparar o comportamento efetivo com a instrução aprovada.
Reserve capacidade antes da submissão
A conta deve reservar a capacidade necessária para uma ordem autorizada antes de a enviar. Isto impede que duas decisões simultâneas dependam cada uma dos mesmos fundos disponíveis ou limite de evento. A reserva é um controlo da aplicação e deve ser conciliada com a semântica efetiva da conta na plataforma.
Para a ordem limitada de trinta unidades a 0,44 $, uma política local hipotética pode reservar 13,20 $ mais uma margem de comissões de 0,30 $, totalizando 13,50 $. Essa margem é inventada para este exemplo e não pode ser tratada como uma cotação atual de comissão da plataforma. O tratamento efetivo das comissões deve utilizar a informação atual aplicável.
Reserve uma vez para a intenção económica, não novamente para cada tentativa de transporte. Se a resposta se tornar desconhecida, conservar a reserva ajuda a impedir a conta de gastar capacidade que o pedido original pode já ter comprometido. Liberte-a ou ajuste-a apenas depois de as provas da ordem e das negociações sustentarem o novo estado.
Guarde de forma persistente o registo da intenção da ordem
Um registo da intenção da ordem liga a decisão de investigação, a aprovação de risco e o pedido eventual. Deve conter um identificador local estável, contexto da conta, contrato, lado, quantidade, limite, tempo de vida e as versões dos dados utilizadas para aprovação. Guarde-o de forma persistente antes de a ação poder sair do processo.
Este registo permite recuperação depois de uma falha. Sem ele, o programa pode observar uma ordem ativa desconhecida no reinício e não conseguir ligá-la à sua própria ação anterior. Também apoia revisão humana quando um pedido foi transmitido, mas a resposta se perdeu.
O guia de bots de API da Polymarket centra-se em comportamento delimitado perante essas submissões incertas. Mesmo uma ferramenta de API operada manualmente beneficia do mesmo diário. O objetivo é conservar o significado da ação independentemente de a troca de rede ter terminado sem problemas.
Recomende e ganhe USDC
Recomende e ganhe USDCO nosso programa de afiliados paga em tempo real.
Trate a resposta de submissão como prova
Uma resposta bem-sucedida de submissão fornece provas de que a plataforma aceitou o pedido num estado específico. Não é uma declaração universal de que todas as unidades pedidas se tornaram uma posição final liquidada. Leia o estado e os identificadores devolvidos segundo o seu significado documentado.
Guarde a resposta com a intenção original e a hora do pedido. Preserve motivos de rejeição, em vez de os substituir por um rótulo genérico de falhou. Uma rejeição da grelha de preços, uma autorização de gasto insuficiente e um tempo de espera de transporte excedido exigem ações diferentes de acompanhamento. Só o último pode deixar desconhecido o resultado da execução na perspetiva local.
Uma confirmação de receção nunca deve ser utilizada como única base para uma apresentação final da posição. A aplicação deve conseguir dizer submetida, ativa, parcialmente executada, cancelada, à espera de confirmação ou por resolver, conforme apropriado. Estados intermédios claros são mais informativos do que um único indicador verde de sucesso.
Acompanhe ordens e negociações separadamente
Uma ordem é uma instrução que pode produzir uma ou mais negociações. A sua quantidade restante e os seus registos associados de negociações respondem a perguntas relacionadas, mas diferentes. Uma ordem totalmente correspondida pode ainda ter informação de liquidação das negociações que tem de ser acompanhada, enquanto uma ordem em espera parcialmente correspondida pode conservar quantidade ativa.
O ciclo de vida das ordens da Polymarket distingue correspondência de confirmação final. Uma implementação do ciclo de vida deve preservar essa distinção quando atualiza a perspetiva da conta. Não deve reduzir cada estado de negociação ao mesmo estado concluído.
Para uma execução parcial inventada, suponha que doze de trinta unidades são correspondidas. O diário da conta deve identificar essas doze e o estado das suas negociações e depois determinar o que aconteceu às dezoito restantes segundo o tipo de ordem. A aritmética de quantidade pedida menos correspondida é útil, mas não estabelece, por si só, se o remanescente continua ativo.
Concilie uma execução parcial com o remanescente
Continue a ordem hipotética de trinta unidades, mas pressuponha que apenas doze são executadas a 0,44 $. O seu preço de compra é de 5,28 $. Se a ordem era FAK e a sua resposta terminal confirma o cancelamento do resto, a conta tem doze unidades adquiridas e nenhum compromisso restante de ordem das outras dezoito.
Se era uma ordem em espera e dezoito continuam ativas a 0,44 $, essas unidades representam até mais 7,92 $ de compromisso de preço de compra. Acrescente qualquer tratamento aplicável de comissões segundo a política efetiva da conta. Os dois casos têm a mesma quantidade executada, mas capacidade restante diferente.
Um pedido posterior de cancelamento afeta apenas a parte que continua cancelável. Não desfaz unidades executadas. O registo final da conta deve, por isso, ligar negociações executadas, estado final do remanescente e quaisquer comissões, em vez de tratar cancelamento como se toda a ordem original nunca tivesse existido.
Trate o cancelamento como uma corrida com a execução
Entre decidir cancelar e receber o resultado, uma ordem pode ser executada adicionalmente. O programa tem de conciliar tanto a resposta de cancelamento como quaisquer execuções associadas. Um clique local num botão não estabelece que a quantidade restante foi removida antes de outra correspondência.
Suponha que a conta acreditava restarem dezoito unidades, mas outras cinco foram executadas enquanto o cancelamento era processado. A posição final é de dezassete unidades, com treze removidas se o cancelamento tiver sucesso para o resto. O diário deve explicar a execução adicional, em vez de a assinalar como impossível porque já tinha sido pedido um cancelamento.
Evite substituir imediatamente toda a quantidade original depois de uma tentativa de cancelamento. Determine primeiro a exposição restante efetiva. A substituição é uma nova decisão económica que deve utilizar preços atuais, estado atual da conta e os limites da estratégia original, incluindo qualquer prazo que possa ter expirado durante o processo de cancelamento.
Recupere de uma submissão de resultado desconhecido
Se uma ligação falhar depois da transmissão, a ordem original pode ter sido aceite. O passo seguinte é investigar essa intenção através das provas disponíveis de ordens, negociações e conta. Criar uma nova ordem sem relação pode duplicar exposição mesmo quando a primeira tentativa parecia localmente sem sucesso.
Conserve os identificadores originais e a reserva enquanto a investigação prossegue. Utilize consultas delimitadas e comportamento documentado de recuperação. Se o estado da conta não puder ser estabelecido, suspenda novas submissões relacionadas e apresente a incerteza ao operador responsável. Um tempo de espera excedido deve tornar-se um estado explícito por resolver, não uma rejeição inventada.
A comparação com negociação pela API da Kalshi ajuda a separar este problema geral de sistemas distribuídos de interfaces específicas da plataforma. Ambos os contextos exigem conciliação, mas identificadores, autenticação, esquemas e semântica de ordens têm de ser tratados segundo a documentação atual de cada plataforma, não copiados entre adaptadores.
Reconstrua o estado depois de uma desconexão
Atualizações em fluxo são úteis para observação rápida, mas um cliente desligado precisa de um plano de recuperação. Obtenha informação atual da conta, concilie ordens abertas e obtenha negociações relevantes utilizando as interfaces documentadas. Depois compare o estado recuperado com o diário local antes de permitir nova exposição.
Não pressuponha que mensagens reproduzidas são novos eventos económicos. Uma negociação observada antes e depois de reconectar deve contribuir uma vez para o registo da posição. Identificadores estáveis e tratamento de revisões tornam isso possível. Um evento duplicado de transporte não deve duplicar a quantidade executada ou as comissões.
Registe o intervalo incerto e as provas utilizadas para o encerrar. Se a integração não conseguir estabelecer cobertura completa, preserve essa limitação. A apresentação da conta pode mostrar posições verificadas juntamente com uma questão de conciliação por resolver, em vez de apresentar um total falsamente preciso montado a partir de fluxos incompletos.
Distinga liquidação da negociação de resolução do evento
A liquidação de uma negociação transfere ativos associados à compra ou venda. A resolução do evento determina o resultado do contrato de previsão segundo as suas regras. São etapas separadas. Uma compra confirmada não significa que o evento foi resolvido, e um resultado aparente do evento não prova que a conta recebeu o seu pagamento final.
Mantenha registos separados para posições adquiridas, resolução do mercado e qualquer processo de resgate ou pagamento aplicável à conta. Os identificadores e provas relevantes podem diferir. Esta separação é especialmente útil quando a posição continua aberta durante muito tempo depois da ordem inicial.
O guia de automação da Polymarket coloca estas etapas em processos manuais, supervisionados e delegados. Decida que etapas a aplicação pode realizar e quais exigem revisão. Uma permissão para submeter uma negociação delimitada não deve ser interpretada como autoridade ilimitada sobre cada operação posterior da carteira.
Torne explicável a conciliação da conta Polymarket
A conciliação da conta Polymarket compara os registos da aplicação com provas fidedignas da conta. O resultado deve explicar posições, compromissos abertos, quantidades executadas, comissões e elementos por resolver. Uma diferença de saldo é um sintoma a investigar, não um número para esconder com um ajuste sem explicação.
Para o exemplo de execução parcial, um revisor deve conseguir seguir a intenção original de trinta unidades até à execução de doze e ao estado final do remanescente. Se negociações posteriores mudaram a posição, devem aparecer como registos separados com as suas próprias origens. O total final deve ser reproduzível a partir desses componentes.
Mantenha a conciliação suficientemente independente para detetar erros no percurso de submissão. Se confiar simplesmente nos mesmos pressupostos locais que produziram a ordem, pode repetir o erro, em vez de o encontrar. Explicações legíveis são valiosas porque um operador consegue frequentemente identificar uma associação errada de contrato ou conta mais depressa do que um código genérico de incompatibilidade a revela.
Verifique a negociação pela API da Polymarket através de casos completos
A aceitação deve abranger uma execução completa, uma execução parcial com remanescente ativo, uma execução parcial imediata com remanescente cancelado, uma rejeição, uma corrida de cancelamento e uma submissão de resultado desconhecido. Cada caso deve terminar com um estado explicável da conta ou uma condição explícita por resolver que bloqueia continuação inadequada.
O guia anterior de bots de negociação pela API da Polymarket fornece uma perspetiva mais ampla de cliente auditável. Utilize o registo do ciclo de vida para avaliar o comportamento da implementação, incluindo reinício e recuperação, em vez de testar apenas se um ponto de acesso de ordens devolve sucesso.
Uma integração completa torna visível cada transição importante: o que era pretendido, o que foi autorizado, o que foi submetido, o que foi executado e o que a conta detém agora. Esse registo apoia uma operação cuidadosa à medida que a documentação evolui e torna as falhas diagnosticáveis sem confundir uma resposta de rede, uma negociação correspondida e uma posição final conciliada.