Use the right identifier for each stage
An event groups markets; a market describes a specific question; an outcome has its own token identifier. Preserve that mapping explicitly. A title can be shortened, localized or reused, so it is a poor execution identifier. Resolve the exact outcome before requesting its order book or preparing an action.
Use current official documentation for discovery, market details, pricing and authenticated trading. API and SDK conventions change. This guide deliberately provides an implementation design rather than a copied signing recipe that may target an older client.
Five stages with explicit boundaries
Store a durable identifier for each intended action before sending it. The identifier should connect the rule version and triggering observation to the resulting order. This is an application-side duplicate-prevention design, not a claim that every API endpoint accepts an idempotency key.
- Discover: collect the exact market, outcome, rules, status and applicable trading constraints.
- Observe: obtain a fresh snapshot, then process updates while tracking their timestamps and connection health.
- Decide: evaluate a versioned user rule against the same recorded inputs; produce an action proposal or a reason to abstain.
- Authorize: verify eligibility, signing authority, approvals, available budget and order constraints before submission.
- Reconcile: compare the intended action with actual open orders, fills and positions; update the remaining budget.
What to do when a request times out
A timeout is an unknown result. Stop automatic retries for that intent until you have checked the appropriate order and trade records. If the first request was accepted, resubmitting an equivalent order can double exposure. Persist the uncertainty across process restarts instead of clearing it from memory.
For a hypothetical ten-share order with three shares filled, account for the three-share position and the seven-share open remainder. Canceling the remainder does not reverse the fill. Confirm the cancellation result and then refresh state before another decision.
A recovery checklist for developers
Test these cases against a mocked service and recorded inputs without credentials. A read-only prototype can validate market mapping. Any live integration needs separate verification of the current API contract and its supported authorization model.
- Rejected order: retain the rejection reason; change the underlying condition rather than looping blindly.
- Connection loss: suspend decisions requiring fresh data, reconnect and rebuild a current snapshot.
- Rate limit: respect the current documented policy, back off and avoid a retry storm across workers.
- Unknown submission: reconcile before retrying; preserve an explicit unresolved state.
- Process restart: recover open orders, positions, permissions and budget reservations before enabling actions.
- Permission revocation: stop new signing attempts and review any still-open orders separately.
Keep secrets out of the observation layer
Market-data code should not acquire signing authority merely for convenience. Separate the component that reads data from the component allowed to act. Do not include secrets in logs, browser bundles, source control or diagnostic screenshots. Verify revocation and expiry behavior instead of relying on a label such as non-custodial.
SharkRule offers a software approach centered on the user's rules and permissions; it is independent from Polymarket. This guide is not SharkRule API documentation and does not promise an exposed developer API, SDK or integration. Register for early access to learn about supported product capabilities.
Custody, permissions and eligibility
Non-custodial means funds remain in a user-controlled wallet; it does not remove trading permissions, smart-contract risk or the possibility of loss. SharkRule is independent from Polymarket, with no affiliation or endorsement implied. This is software education, not financial or investment advice. Trading eligibility follows current Polymarket geographic restrictions.
Check current geographic restrictionsFrequently asked questions
Do I need trading credentials to explore market data?
Observation and authenticated trading are different workflows. Consult the current official endpoint documentation and give a read-only prototype no order-signing authority.
Can I retry every failed request?
No. A timeout may conceal a successful submission. Reconcile the order state before retrying a request that could create another order.
Does a submitted order mean a completed trade?
No. Submission, acceptance, partial or complete fills, and settlement are distinct states. Your application must track the state relevant to its next decision.