El trading mediante la API de Polymarket conecta una decisión de negociación con una secuencia de solicitudes, estados de órdenes, registros de operaciones y cambios en la cuenta. La unidad útil para comprenderlo es el ciclo de vida de una orden autenticada. Un programa que envía correctamente una solicitud solo ha completado una parte del trabajo; todavía necesita determinar qué ocurrió y qué exposición permanece.
Esta guía se refiere al contexto de la API de Polymarket International. Polymarket US tiene un contexto de plataforma y cuenta separado, por lo que sus interfaces y permisos deben revisarse por separado. La documentación actual también importa: los sistemas de carteras, las bibliotecas cliente y los detalles de las garantías pueden cambiar, de modo que un ejemplo antiguo sea una especificación poco fiable para una integración nueva.
El escenario siguiente utiliza precios, cantidades y comisiones inventados para explicar un ciclo de vida. No ejecuta ninguna operación ni prescribe una inversión. Los principios de diseño se aplican a la revisión manual, las herramientas supervisadas y los flujos automatizados autorizados, y el titular de la cuenta conserva el control sobre las acciones que puede realizar un programa.
Comienza el trading mediante la API de Polymarket con un registro del contrato
El primer registro debe identificar el instrumento real. Conserva el mercado, el token de resultado, el lado seleccionado, las reglas completas y los plazos relevantes. Un título por sí solo no permite distinguir de forma fiable contratos con nombres similares, y un identificador de token sin su significado es difícil de verificar para un revisor humano.
Imagina un mercado binario inventado sobre si se emite un permiso antes de una fecha especificada. La compra prevista es el resultado Yes para esa pregunta exacta. Un mercado relacionado sobre el comienzo posterior de la construcción es un instrumento diferente, aunque ambos titulares compartan la mayoría de sus palabras.
La guía anterior de la API de trading de Polymarket separa los datos del mercado, las órdenes y la información de la cuenta. La búsqueda de contratos pertenece a la primera parte de esa estructura. Antes de cualquier solicitud privada, la integración debe poder mostrar al lector qué resultado pretende negociar y por qué ese identificador corresponde a la decisión de investigación.
Utiliza la interfaz de integración vigente
Un cliente de API debe estar vinculado a una versión documentada y a un conjunto conocido de operaciones compatibles. No supongas que un nombre de paquete antiguo, un ejemplo de cartera o una estructura de solicitud siguen vigentes porque aparezcan en un tutorial. Verifica conjuntamente la documentación oficial y la biblioteca instalada.
La descripción general actual del trading de Polymarket describe una liquidación en la que intervienen pUSD y tokens de resultado. Por tanto, una integración debe evitar fijar en el código una suposición antigua sobre las garantías para todas las operaciones de la cuenta. La financiación, las aprobaciones, la negociación y el canje pueden implicar registros diferentes que merecen sus propias comprobaciones actualizadas.
Registra la fecha de revisión de la documentación y la versión del cliente utilizada por la aplicación. Cuando cambie cualquiera de ellas, repite los casos de aceptación que dependan de firmas, codificación de importes e interpretación de estados. Una solicitud satisfactoria de datos de mercado no demuestra que la vía de trading autenticado sea compatible con la misma versión.
Identifica al firmante y la cartera de la cuenta
La dirección que firma una solicitud y la cartera de la cuenta que mantiene fondos o posiciones no tienen por qué ser intercambiables en todas las configuraciones de cartera. La integración debe establecer su relación utilizando la configuración actual de la cuenta. Deducirla a partir de un formato de dirección conocido puede producir fallos de autorización o confusión de cuentas.
Muestra el contexto de cuenta esperado antes de habilitar la negociación. Una revisión útil incluye la plataforma, la identidad de la cartera, los permisos compatibles y si las lecturas privadas actuales corresponden a la cuenta prevista. Esto permite al operador detectar una configuración técnicamente válida pero vinculada a la cuenta equivocada.
La guía oficial de carteras y autenticación es el punto de partida adecuado para la configuración actual específica de cada cartera. Mantén el material secreto fuera de los registros ordinarios y de los registros visibles para el usuario. El diario del ciclo de vida necesita identificadores y pruebas de autorización, no copias de claves privadas ni credenciales reutilizables.
Separa la autenticación de solicitudes de la autorización de órdenes
La autenticación establece qué cuenta o credencial realiza una solicitud privada. La autorización de la orden establece la instrucción de negociación firmada en sí. La distinción importa porque un envoltorio válido de solicitud no justifica cambiar las condiciones económicas dentro de una orden.
La documentación de la API de Polymarket describe la configuración de credenciales basada en la cartera y las solicitudes CLOB autenticadas, con una firma separada de la cartera que autoriza una orden. Una integración debe seguir los requisitos actuales de firma en lugar de tratar todas las firmas como un único token genérico.
En el nivel de la aplicación, conserva el precio, la cantidad, el lado y la duración aprobados antes de firmar. Si cambia cualquiera de esas condiciones, el programa debe tratar el resultado como una instrucción modificada que requiere las comprobaciones de autorización aplicables. Una función auxiliar que reintenta el transporte no debe ampliar silenciosamente el límite de precio ni aumentar la cantidad para obtener una respuesta satisfactoria.
Lee las restricciones del mercado antes de construir la orden
Una orden válida debe ajustarse a las restricciones actuales del mercado, incluidos los incrementos de precio y los requisitos de cantidad. Son propiedades que se deben leer y verificar, no valores que se deban copiar permanentemente de un ejemplo no relacionado. Un cambio en una restricción puede invalidar una instrucción que, por lo demás, sea sensata.
Utiliza aritmética decimal y unidades explícitas al convertir una decisión humana en importes de solicitud. El precio por participación, el número de participaciones y el coste total en garantías son cantidades diferentes. Un campo que contiene una de ellas nunca debe aceptarse en otro que espera una distinta solo porque ambos se representen como números o cadenas.
La guía oficial de colocación de órdenes documenta la vía actual de construcción. En un flujo general, la comprobación esencial de aceptación consiste en que la orden codificada pueda descodificarse hasta recuperar las condiciones económicas exactas aprobadas por el usuario, después de que cualquier redondeo necesario se haya hecho visible y se haya revisado.
Inspecciona el libro para el tamaño previsto
Un límite de precio define lo que la cuenta está dispuesta a pagar o recibir. No promete que se negocie la cantidad deseada. Antes de construir una orden inmediata, inspecciona la profundidad disponible dentro de ese límite y conserva la hora de observación utilizada por la decisión.
Supongamos que el libro inventado ofrece diez participaciones a $0.41 y veinte a $0.44. Comprar treinta costaría $4.10 más $8.80, es decir, $12.90 antes de comisiones si esas cotizaciones siguen disponibles. Una orden limitada de compra de treinta participaciones a $0.44 permite como máximo $13.20 de precio de compra, sin incluir las comisiones aplicables.
La diferencia entre el coste esperado según el libro y el coste máximo autorizado es útil. El primero describe la oportunidad observada; el segundo acota la orden. Ninguno garantiza la ejecución final. Las cotizaciones pueden cambiar después de la inspección, y una orden puede ser rechazada o ejecutarse parcialmente según su tipo y las condiciones actuales del mercado.
Elige deliberadamente la política para la cantidad restante
El tipo de orden determina qué ocurre cuando no puede ejecutarse inmediatamente toda la cantidad solicitada. Una orden que permanece en el libro puede dejar un compromiso sin ejecutar. Una instrucción inmediata con ejecución parcial puede terminar con una posición y sin cantidad restante activa. Son estados diferentes de la cuenta.
La documentación actual de Polymarket distingue FOK, que requiere una ejecución inmediata completa o la cancelación, de FAK, que ejecuta la cantidad disponible y cancela el resto. Por tanto, una ejecución parcial FAK no deja la parte sin ejecutar en el libro. GTC y GTD tienen sus propios comportamientos de permanencia o vencimiento.
La guía anterior de automatización de órdenes limitadas en Polymarket explica por qué la duración y las ejecuciones deben considerarse conjuntamente. Indica la política prevista para el resto en el registro de intención de la orden, de modo que la conciliación posterior pueda comparar el comportamiento real con la instrucción aprobada.
Reserva capacidad antes del envío
La cuenta debe reservar la capacidad requerida por una orden autorizada antes de enviarla. Esto impide que dos decisiones simultáneas dependan cada una de los mismos fondos disponibles o del mismo límite de evento. La reserva es un control de la aplicación y debe conciliarse con la semántica real de la cuenta en la plataforma.
Para la orden limitada de treinta participaciones a $0.44, una política local hipotética podría reservar $13.20 más una provisión de $0.30 para comisiones, un total de $13.50. Esa provisión es inventada para este ejemplo y no debe tratarse como una cotización actual de comisiones de la plataforma. La gestión real de comisiones debe utilizar la información vigente aplicable.
Reserva una sola vez para la intención económica, no de nuevo por cada intento de transporte. Si la respuesta pasa a ser desconocida, conservar la reserva ayuda a impedir que la cuenta gaste capacidad que la solicitud original quizá ya haya comprometido. Libérala o ajústala solo después de que las pruebas de órdenes y operaciones respalden el nuevo estado.
Guarda de forma persistente el registro de intención de la orden
Un registro de intención de la orden conecta la decisión de investigación, la aprobación de riesgo y la solicitud final. Debe contener un identificador local estable, el contexto de la cuenta, el contrato, el lado, la cantidad, el límite, la duración y las versiones de los datos utilizadas para la aprobación. Guárdalo de forma persistente antes de que la acción pueda salir del proceso.
Este registro permite recuperarse después de un fallo. Sin él, el programa puede observar una orden activa desconocida al reiniciarse y no vincularla con su propia acción anterior. También respalda una revisión humana cuando se transmitió una solicitud pero se perdió la respuesta.
La guía de un bot de API de Polymarket se centra en el comportamiento acotado ante esos envíos inciertos. Incluso una herramienta de API operada manualmente se beneficia del mismo diario. La finalidad es conservar el significado de la acción independientemente de que el intercambio de red haya terminado sin problemas.
Recomienda y gana USDC
Recomienda y gana USDCNuestro programa de afiliados paga en tiempo real.
Trata la respuesta al envío como una prueba
Una respuesta satisfactoria al envío aporta pruebas de que la plataforma aceptó la solicitud en un estado concreto. No es una afirmación universal de que cada participación solicitada se haya convertido en una posición final liquidada. Lee el estado y los identificadores devueltos según su significado documentado.
Guarda la respuesta junto con la intención original y la hora de la solicitud. Conserva los motivos de rechazo en lugar de sustituirlos por una etiqueta genérica de fallo. Un rechazo por la cuadrícula de precios, una autorización de gasto insuficiente y un tiempo de espera agotado en el transporte requieren acciones de seguimiento distintas. Solo el último puede dejar desconocido el resultado de ejecución desde la perspectiva local.
Una confirmación de recepción nunca debe utilizarse como única base para mostrar una posición final. La aplicación debe poder indicar enviada, activa, parcialmente ejecutada, cancelada, pendiente de confirmación o sin resolver, según corresponda. Los estados intermedios claros son más informativos que un único indicador verde de éxito.
Sigue las órdenes y las operaciones por separado
Una orden es una instrucción que puede producir una o varias operaciones. Su cantidad restante y los registros de operaciones asociados responden a preguntas relacionadas pero diferentes. Una orden totalmente cruzada todavía puede tener información de liquidación de operaciones que deba seguirse, mientras que una orden parcialmente cruzada que permanece en el libro puede conservar cantidad activa.
El ciclo de vida de las órdenes de Polymarket distingue el cruce de la confirmación final. Una implementación del ciclo de vida debe conservar esa distinción al actualizar la vista de la cuenta. No debe reducir todos los estados de operación al mismo estado completado.
Para una ejecución parcial inventada, supongamos que se cruzan doce de treinta participaciones. El diario de la cuenta debe identificar esas doce y el estado de sus operaciones, y después determinar qué ocurrió con las dieciocho restantes según el tipo de orden. El cálculo de cantidad solicitada menos cantidad cruzada es útil, pero por sí solo no establece si el resto sigue activo.
Concilia una ejecución parcial con la cantidad restante
Continúa con la orden hipotética de treinta participaciones, pero supón que solo se ejecutan doce a $0.44. Su precio de compra es $5.28. Si la orden era FAK y su respuesta terminal confirma la cancelación del resto, la cuenta tiene doce participaciones adquiridas y ningún compromiso de orden restante por las otras dieciocho.
Si era una orden que permanece en el libro y dieciocho siguen activas a $0.44, esas participaciones representan hasta otros $7.92 de compromiso de precio de compra. Añade cualquier tratamiento de comisiones aplicable según la política real de la cuenta. Ambos casos tienen la misma cantidad ejecutada, pero distinta capacidad restante.
Una solicitud posterior de cancelación afecta únicamente a la parte que sigue siendo cancelable. No deshace las participaciones ejecutadas. Por tanto, el registro final de la cuenta debe conectar las operaciones ejecutadas, el estado final del resto y las comisiones, en lugar de tratar la cancelación como si toda la orden original nunca hubiera existido.
Gestiona la cancelación como una carrera con la ejecución
Entre decidir cancelar y recibir el resultado, una orden puede ejecutarse más. El programa debe conciliar tanto la respuesta de cancelación como las ejecuciones asociadas. Pulsar un botón local no demuestra que se haya retirado la cantidad restante antes de otro cruce.
Supongamos que la cuenta creía que quedaban dieciocho participaciones, pero se ejecutaron cinco más mientras se procesaba la cancelación. La posición final es de diecisiete participaciones, con trece retiradas si la cancelación tiene éxito para el resto. El diario debe explicar la ejecución adicional en lugar de señalarla como imposible porque ya se había solicitado la cancelación.
Evita sustituir inmediatamente toda la cantidad original después de un intento de cancelación. Determina primero la exposición restante real. La sustitución es una decisión económica nueva que debe utilizar precios actuales, el estado actual de la cuenta y los límites de la estrategia original, incluido cualquier plazo que pueda haber vencido durante el proceso de cancelación.
Recupérate de un envío con resultado desconocido
Si una conexión falla después de la transmisión, la orden original puede haber sido aceptada. El siguiente paso es investigar esa intención mediante las pruebas disponibles de órdenes, operaciones y cuenta. Crear una orden nueva sin relación puede duplicar la exposición incluso cuando el primer intento parecía fallido localmente.
Conserva los identificadores originales y la reserva mientras avanza la investigación. Utiliza consultas acotadas y el comportamiento de recuperación documentado. Si no puede establecerse el estado de la cuenta, pausa los nuevos envíos relacionados y presenta la incertidumbre al operador responsable. Un tiempo de espera agotado debe convertirse en un estado explícito sin resolver, no en un rechazo inventado.
La comparación con el trading mediante la API de Kalshi ayuda a separar este problema general de sistemas distribuidos de las interfaces específicas de cada plataforma. Ambos contextos requieren conciliación, pero los identificadores, la autenticación, los esquemas y la semántica de las órdenes deben gestionarse según la documentación actual de cada plataforma, en lugar de copiarse de un adaptador a otro.
Reconstruye el estado después de una desconexión
Las actualizaciones en streaming sirven para observar con prontitud, pero un cliente desconectado necesita un plan de recuperación. Obtén información actual de la cuenta, concilia las órdenes abiertas y recupera las operaciones relevantes mediante las interfaces documentadas. Después compara el estado recuperado con el diario local antes de permitir exposición nueva.
No supongas que los mensajes repetidos son eventos económicos nuevos. Una operación observada antes y después de volver a conectar debe contribuir una sola vez al registro de posiciones. Los identificadores estables y la gestión de revisiones lo hacen posible. Un evento de transporte duplicado no debe duplicar la cantidad ejecutada ni las comisiones.
Registra el intervalo de incertidumbre y las pruebas utilizadas para cerrarlo. Si la integración no puede establecer una cobertura completa, conserva esa limitación. La pantalla de la cuenta puede mostrar tenencias verificadas junto con un problema de conciliación sin resolver, en lugar de presentar un total falsamente preciso construido a partir de flujos incompletos.
Distingue la liquidación de operaciones de la resolución del evento
La liquidación de una operación transfiere los activos asociados con la compra o la venta. La resolución del evento determina el resultado del contrato de predicción según sus reglas. Son fases separadas. Una compra confirmada no significa que el evento se haya resuelto, y un resultado aparente del evento no demuestra que la cuenta haya recibido su pago final.
Mantén registros separados de las posiciones adquiridas, la resolución del mercado y cualquier proceso de canje o pago aplicable a la cuenta. Los identificadores y las pruebas relevantes pueden ser distintos. Esta separación es especialmente útil cuando la posición permanece abierta mucho tiempo después de la orden inicial.
La guía de automatización de Polymarket sitúa estas fases en flujos manuales, supervisados y delegados. Decide qué fases puede realizar la aplicación y cuáles requieren revisión. Un permiso para enviar una operación acotada no debe interpretarse como una autorización ilimitada sobre todas las operaciones posteriores de la cartera.
Haz que la conciliación de la cuenta de Polymarket sea explicable
La conciliación de la cuenta de Polymarket compara los registros de la aplicación con las pruebas oficiales de la cuenta. El resultado debe explicar las posiciones, los compromisos abiertos, las cantidades ejecutadas, las comisiones y los elementos sin resolver. Una diferencia de saldo es un síntoma que se debe investigar, no una cifra que se deba ocultar con un ajuste sin explicación.
En el ejemplo de ejecución parcial, un revisor debe poder seguir la intención original de treinta participaciones hasta la ejecución de doce y el estado final del resto. Si operaciones posteriores cambiaron la posición, deben aparecer como registros separados con sus propios orígenes. El total final debe poder reproducirse a partir de esos componentes.
Mantén la conciliación lo bastante independiente para detectar errores en la vía de envío. Si simplemente confía en los mismos supuestos locales que produjeron la orden, puede repetir el error en lugar de encontrarlo. Las explicaciones legibles son valiosas porque un operador a menudo puede identificar una asociación incorrecta de contrato o cuenta más rápidamente de lo que un código genérico de discrepancia la revela.
Verifica el trading mediante la API de Polymarket con casos completos
La aceptación debe abarcar una ejecución completa, una ejecución parcial con resto activo, una ejecución inmediata parcial con resto cancelado, un rechazo, una carrera entre cancelación y ejecución y un envío con resultado desconocido. Cada caso debe terminar con un estado explicable de la cuenta o una condición explícita sin resolver que bloquee una continuación inadecuada.
La guía anterior del bot de trading mediante la API de Polymarket aporta una perspectiva más amplia de cliente auditable. Utiliza el registro del ciclo de vida para evaluar el comportamiento de la implementación, incluidos el reinicio y la recuperación, en lugar de probar únicamente si un endpoint de órdenes devuelve éxito.
Una integración completa hace visible cada transición importante: qué se pretendía, qué se autorizó, qué se envió, qué se ejecutó y qué mantiene ahora la cuenta. Ese registro respalda una operación cuidadosa a medida que evoluciona la documentación y permite diagnosticar fallos sin confundir una respuesta de red, una operación cruzada y una posición final conciliada.