Receive prediction markets from wrangle.win.
wrangle.win delivers structured prediction markets directly to the Market URL configured in your merchant account.
Your Market URL belongs to your own platform. It can be any HTTPS endpoint in your backend that is able to receive POST requests from wrangle.win.
When a market is delivered, your platform receives a market.published event containing the market content, available outcomes, translations, sources and classification data.
When a prediction market is ready for delivery, wrangle.win sends a POST request to the Market URL configured for your merchant account.
wrangle.win initiates the market delivery request.
Your backend receives and processes the market.
This is only an example. You can use any HTTPS route supported by your backend.
wrangle.win pushes markets to your backend.
Market delivery is initiated by wrangle.win. Your platform does not need to continuously poll wrangle.win for new content.
market.published payload
The request body contains the event type and the prediction market object.
The values below are illustrative. The JSON structure represents the market delivery format used by wrangle.win.
{
"event": "market.published",
"market": {
"id": 572,
"status": "published",
"source_locale": "en",
"finish_at": "2026-10-15T18:00:00+00:00",
"published_at": "2026-09-30T10:00:00+00:00",
"resolved_at": null,
"winning_answer_id": null,
"translations": [
{
"locale": "en",
"title": "Will Bitcoin be above $120,000 on October 15?",
"description": "This market resolves according to the defined resolution conditions."
},
{
"locale": "es",
"title": "ВїBitcoin estarГЎ por encima de $120,000 el 15 de octubre?",
"description": "Este mercado se resolverГЎ segГєn las condiciones de resoluciГіn definidas."
}
],
"answers": [
{
"id": 1141,
"sort_order": 1,
"translations": [
{
"locale": "en",
"title": "Yes"
},
{
"locale": "es",
"title": "SГ"
}
]
},
{
"id": 1142,
"sort_order": 2,
"translations": [
{
"locale": "en",
"title": "No"
},
{
"locale": "es",
"title": "No"
}
]
}
],
"sources": [
{
"url": "https://example.com/source",
"sort_order": 1
}
],
"categories": [
{
"id": 3,
"name": "Crypto",
"slug": "crypto"
}
],
"countries": [],
"country_groups": [
{
"id": 1,
"name": "Global",
"slug": "global"
}
]
}
}Request structure
| Field | Type | Description |
|---|---|---|
| event | string | Event type. Initial market delivery uses market.published. |
| market | object | Prediction market data delivered to your platform. |
Core market fields
| Field | Type | Description |
|---|---|---|
| id | integer | Unique wrangle.win market identifier. |
| status | string | Current lifecycle status of the market. |
| source_locale | string / null | Original language or locale of the market. |
| finish_at | ISO 8601 / null | Scheduled market finish time. |
| published_at | ISO 8601 / null | Time the market was published by wrangle.win. |
| resolved_at | ISO 8601 / null | Resolution time. Normally null during initial delivery. |
| winning_answer_id | integer / null | Winning answer identifier. Normally null until the market is resolved. |
Localized market content
A market can contain multiple translations so your platform can display the same prediction market in different languages.
"translations": [
{
"locale": "en",
"title": "Will Bitcoin be above $120,000 on October 15?",
"description": "This market resolves according to the defined resolution conditions."
}
]Language or locale identifier.
Localized prediction market title.
Localized description and market information.
Available market outcomes
Each possible outcome has a stable wrangle.win answer ID, display order and localized titles.
"answers": [
{
"id": 1141,
"sort_order": 1,
"translations": [
{
"locale": "en",
"title": "Yes"
}
]
},
{
"id": 1142,
"sort_order": 2,
"translations": [
{
"locale": "en",
"title": "No"
}
]
}
]Store each answers[].id value together with your own internal outcome identifier. The answer IDs are reused by later lifecycle callbacks so your platform can match the final wrangle.win result to the same internal outcomes.
Market sources
Source URLs associated with the market can be included in the delivery payload.
"sources": [
{
"url": "https://example.com/source",
"sort_order": 1
}
]Categories and geography
Classification data can be used by your platform to automatically filter, organize and route incoming markets.
- id
- name
- slug
- id
- code
- name
- id
- name
- slug
Keep your IDs. Store ours.
You do not need to change the internal identifiers already used by your platform.
Store wrangle.win market and answer IDs as external references. These identifiers connect the original market delivery with future lifecycle events.
Map this value to your internal market record.
Map each wrangle.win answer ID to your internal outcome record.
Receive each delivery safely.
Your Market URL should process deliveries idempotently. Receiving the same market more than once must not create duplicate markets or duplicate business actions.
Validate the event and required market fields.
Search for an existing market using the wrangle.win market ID.
Store or update the market and its external identifiers.
Return a successful response after accepting the delivery.
Laravel receiver example
The following example demonstrates one possible way to receive a market. Your implementation can use any framework or internal data structure.
Route::post('/markets', [MarketController::class, 'receive']);public function receive(Request $request)
{
$payload = $request->validate([
'event' => ['required', 'string'],
'market' => ['required', 'array'],
'market.id' => ['required', 'integer'],
]);
if ($payload['event'] !== 'market.published') {
return response()->json([
'message' => 'Unsupported event',
], 422);
}
$market = $payload['market'];
$localMarket = Market::updateOrCreate(
[
'wrangle_market_id' => $market['id'],
],
[
'status' => $market['status'],
'source_locale' => $market['source_locale'] ?? null,
'finish_at' => $market['finish_at'] ?? null,
'published_at' => $market['published_at'] ?? null,
]
);
ProcessMarket::dispatch(
$localMarket->id,
$market
);
return response()->json([
'accepted' => true,
]);
}This example does not define a required database schema. The only important requirement is that your platform can reliably associate the wrangle.win market ID with the corresponding market in your own system.
Confirm that the market was accepted.
wrangle.win treats a successful HTTP response as confirmation that your platform accepted the delivery.
{
"accepted": true
}Any successful 2xx response indicates that the delivery was accepted by your platform.
A non-successful HTTP response is treated as a failed delivery attempt.
Your endpoint should therefore return a successful response only after the incoming market has been safely accepted.
Accept quickly. Process asynchronously.
wrangle.win waits up to 20 seconds for the Market URL request to complete.
For production integrations, we recommend validating and persisting the incoming event quickly, returning a successful HTTP response and performing expensive internal processing through your own queue or background workers.
Receiving a market does not require you to publish it.
wrangle.win delivers prediction market content to your backend. Your platform remains in control of what becomes available to your users.
Choose which delivered markets to use.
Decide when a market becomes visible.
Control placement and presentation.
Apply your own participation and commercial model.
Market delivery starts the lifecycle.
After a market has been delivered, wrangle.win continues tracking its lifecycle. Subsequent lifecycle notifications are sent to the separate Callback URL configured for your merchant account.
Outcome determination has started. This event is non-terminal: do not infer a winner or settle the market yet.
The final winner has been confirmed. Use the supplied result with your platform's existing settlement workflow.
The market has been cancelled without a winner. Apply your platform's existing cancellation or void rules.
The Callback URL receives market.resolving, market.resolved and market.cancelled.