Skip to main content
This document describes the webhook payloads that are sent when subscription alerts are triggered for the /subscriptions endpoint.

Overview

When you create a subscription with webhook channels configured, Nevua Markets will send HTTP POST requests to your configured webhook URLs when the subscription conditions are met. There are two types of notifications:
  1. Price Notifications - Sent when price-based alert conditions are met (e.g., crossing thresholds)
  2. Event Status Notifications - Sent when event or market status changes occur (e.g., new events created, markets closed)

Price Notification Schema

This schema is used for all price-based alert notifications.

Properties

Changelog:
  • [30/09/2025]: subscriptionTypeConfig will soon be migrated to a rules object, which will also contain trigger context.

Example Price Notification

Event Status Notification Schema

This schema is used for event and market status change notifications. There are three types of event notifications:
  • Open Markets, with eventStatusScope: Market and triggerType: Open
  • Closed Markets, with eventStatusScope: Market and triggerType: Closed
  • Closed Events, with eventStatusScope: Event and triggerType: Closed
If a closed event has only one market, then the webhook call will include that singular market context, i.e. its id, question and outcome. For new events with multiple markets, then a separate webhook call will be made for each market of that event.

Properties

Example Event Status Notifications

New Market Created
Market Closed
Event Closed - single market
Event Closed - multiple markets
**

Webhook Delivery

HTTP Request Format

All webhook notifications are delivered as HTTP POST requests with the following characteristics:
  • Content-Type: application/json
  • User-Agent: NevuaMarkets-Webhook/1.0
  • Body: JSON payload matching one of the schemas above

Response Requirements

Your webhook endpoint should:
  • Respond with a 2xx HTTP status code to indicate successful receipt
  • Respond within 5 seconds to avoid timeout
  • Handle duplicate notifications gracefully (notifications may be retried)

Retry Policy

Failed webhook deliveries will be retried 2 times:
  • Retry delay: 1 second
  • Maximum retries: 2 retries, 3 attempts in total including the first.

Security Considerations

  • Use HTTPS endpoints for webhook URLs
  • Implement signature verification if needed (contact support for details)
  • Validate the notification structure before processing
  • Consider implementing idempotency based on subscriptionId + detectedAtMs

Troubleshooting

Common Issues

  1. Missing notifications: Check that your webhook URL is accessible and responding with 2xx status codes
  2. Duplicate notifications: Implement idempotency handling based on notification IDs
  3. Timeout errors: Ensure your webhook endpoint responds within 30 seconds

Testing Your Webhook

You can test your webhook endpoint by creating a test subscription and triggering conditions manually, or by using tools like ngrok for local development.