Secure your wrangle.win integration.
wrangle.win integrations are designed for server-to-server communication between our infrastructure and your backend.
API credentials, Market URLs and Callback URLs should be treated as production infrastructure and protected accordingly.
Protect your API credentials.
Merchant API tokens are secret credentials and should only be accessible to trusted server-side applications.
Protect your receiving endpoints.
Your Market URL and Callback URL receive server-to-server events that can affect market content and internal settlement workflows.
Use HTTPS in production.
Production endpoints should use HTTPS to protect data while it travels between wrangle.win and your infrastructure.
Treat API tokens like passwords.
A merchant API token should never be embedded in public frontend code, committed to a public repository or shared through unsecured communication channels.
- Server environment variables
- Secret management systems
- Encrypted deployment configuration
- Protected backend infrastructure
- Browser JavaScript
- Public Git repositories
- HTML source code
- Public documentation
- Unprotected log files
Keep receiving endpoints focused.
We recommend using dedicated backend routes for wrangle.win market deliveries and lifecycle callbacks instead of mixing them with browser-facing application routes.
POST /api/markets
POST /api/wrangle/callbackThese are example routes only. Your platform can use any HTTPS endpoint structure supported by your backend.
Validate events according to the endpoint that receives them.
The Market URL receives initial market delivery. The Callback URL receives subsequent lifecycle events. Reject unexpected event types instead of passing them into your market or financial workflows.
Validate every incoming event.
Do not pass an incoming payload directly into your market or settlement logic without validating the expected event type and required identifiers.
Validate before processing.
$payload = $request->validate([
'event' => ['required', 'string', 'in:market.resolving,market.resolved,market.cancelled'],
'market' => ['required', 'array'],
'market.id' => ['required', 'integer'],
'market.status' => ['required', 'string'],
'market.winning_answer_id' => ['nullable', 'integer'],
'market.resolved_at' => ['nullable'],
]);
switch ($payload['event']) {
case 'market.resolving':
// Non-terminal. Do not settle or infer a winner.
break;
case 'market.resolved':
// Validate the supplied winner before settlement.
break;
case 'market.cancelled':
// Terminal without a winner. Apply your cancellation rules.
break;
}Never trust a market ID alone.
A lifecycle event should only be applied to a market that your platform previously received and mapped to the same wrangle.win market identifier.
For market.resolved, the winning_answer_id should correspond to an answer previously stored for that market. For market.cancelled, no winning answer should be inferred.
Verify the event, market and final outcome before processing.
Locate the market using its stored wrangle.win ID.
For resolved events, verify that the winning answer belongs to that market.
Confirm that the lifecycle event has not already been processed.
Run the appropriate existing settlement or cancellation workflow.
Duplicate events must be harmless.
Your integration should assume that the same event may be received more than once.
Repeated market deliveries should not create duplicate markets, and repeated lifecycle callbacks must never trigger duplicate settlement or balance operations.
if ($market->settled_at) {
return response()->json([
'accepted' => true,
'already_processed' => true,
]);
}Protect critical operations with database transactions.
If processing a terminal lifecycle event changes multiple records, use transactional database operations where appropriate so that partial settlement, cancellation or refund processing does not leave your system in an inconsistent state.
DB::transaction(function () use ($market, $winningAnswer) {
if ($market->settled_at) {
return;
}
// Apply your internal settlement logic.
$market->update([
'settled_at' => now(),
]);
});Enforce unique external identifiers.
Database constraints provide additional protection against duplicate market records when multiple requests are processed concurrently.
Schema::table('markets', function (Blueprint $table) {
$table->unsignedBigInteger('wrangle_market_id')
->unique();
});Log events without leaking secrets.
Integration logs are useful for troubleshooting, but secret credentials should never be written to application logs.
- Event type
- Market ID
- Received timestamp
- Processing status
- HTTP result
- Internal error reference
- Full API tokens
- Passwords
- Private infrastructure credentials
- Unnecessary user financial information
Expose only what the integration needs.
Your Market and Resolution Callback endpoints must be reachable by the delivery infrastructure, but that does not mean the rest of your internal application needs to be publicly accessible.
Keep databases, queues, internal administration services and settlement infrastructure behind your normal network security controls.
Do not accidentally block legitimate deliveries.
You can apply normal abuse protection to public endpoints, but configure rate limits with enough capacity for your expected market delivery volume.
If your endpoint returns HTTP 429, the delivery is not considered successfully accepted.
Separate development and production.
Keep production credentials and callback configuration separate from local development and staging environments.
Local integration development and testing.
Pre-production integration verification.
Live credentials and merchant endpoints.
Replace compromised credentials.
If a merchant API token is exposed through source code, logs, screenshots or another unauthorized location, stop treating that credential as trusted.
Disable the affected token and use a replacement credential for future API access.
wrangle.win does not require access to player accounts.
Market delivery and lifecycle callbacks do not require wrangle.win to access your player passwords, wallet credentials, deposits, withdrawals or individual account balances.
Your customer accounts, financial infrastructure and settlement systems remain under your platform's control.
Build the integration with AI.
Use ready-made AI prompts to generate the receiving endpoints, database mappings, queues and lifecycle processing required for your technology stack.
AI Integration Prompts в†’