Skip to main content
Use the Create Market API when you want to create events and markets outside the admin UI. The API prepares metadata, images, on-chain calldata, and final registration, while your integration signs and sends the wallet transactions from the creator EOA.
Create Market API lifecycle from runtime configuration and creator authorization through transactions and final registration
Production base URL: https://create-market.kuest.com. Self-hosted deployments can point the app to another worker with CREATE_MARKET_URL.

API prepares

Validates the request, processes images and metadata, and returns the transaction plan.

Creator signs

Authorizes the exact payload and sends every transaction from the creator EOA.

API finalizes

Validates confirmed transactions and registers the completed markets.

​
Prerequisites

Creator EOA

The same EOA address must be used in the payload, EIP-712 signature, transaction sender, and finalize calls.
The prediction-market admin and scheduler can enforce your allowed creator policy before calling this API. The create-market worker itself requires the creator to have an on-chain proposer whitelist registered before preparation can complete.
The creator needs POL for gas and the required USDC funding shown by GET /market-config. The transaction plan may include USDC approvals and fee or reward payments.
POST /prepare requires an event image. Optional option images and sports team logos can also be uploaded in the same multipart request.

​
Creation Sequence

1

Fetch runtime config

Call GET /market-config to read the default chain, supported chains, contract addresses, funding requirements, and image limits.
2

Build the prepare payload

Create the JSON payload for the event and markets. Serialize it once, then compute payloadHash = keccak256(stringToHex(payloadJson)).
3

Request an auth challenge

Call POST /prepare-auth with creator, chainId, and payloadHash.
4

Sign EIP-712

Sign the returned challenge from the creator EOA. The signed message binds requestId, creator, payloadHash, nonce, expiresAt, and chainId.
5

Prepare the request

Call POST /prepare as multipart/form-data with the exact payloadJson, the signed auth envelope, and image files. The API returns prepare_in_progress.
6

Poll until prepared

Call GET /pending?requestId=...&creator=...&chainId=... until request.prepared.txPlan is present.
7

Execute the transaction plan

Send every item in txPlan from the creator wallet using the returned to, value, and data.
8

Persist transaction hashes

Call POST /tx-confirm after each transaction or once with the full list. This makes the flow resumable.
9

Finalize

Call POST /finalize with the confirmed hashes. If the response is metadata_update_pending, execute metadataUpdateTxPlan, confirm those hashes, and call POST /finalize again.
Persist requestId, the serialized payload, and every confirmed transaction hash. These values let the integration resume after a timeout or process restart.

​
Request Statuses

​
Security Model

Preparation requires creator consent

The worker validates creator signatures and on-chain proposer whitelist state. If you expose direct automation to third parties, enforce any site-specific allowed creator policy in your integration layer before calling POST /prepare-auth and POST /prepare.
POST /finalize validates submitted hashes against the saved transaction plan. It checks transaction sender, target, calldata, value, and successful receipt before advancing.
GET /pending can return operational details for a known requestId or creator address, including transaction plan, hashes, status, and error messages. Treat request IDs as operational identifiers and avoid posting them publicly.
POST /prepare-auth creates resumable request rows, and POST /prepare processes uploads. Public deployments should configure allowed origins and edge rate limits according to the audience they intend to support.
Scheduled or recurring automation should sign from a server-side wallet store. Never expose private keys in browser code or public environment variables.