Skip to main content

Overview

Webhooks allow Ant Media Server to notify your application about stream events in real-time via HTTP POST requests. Use webhooks to:
  • Track stream lifecycle (started, ended, status updates)
  • Trigger custom workflows when events occur
  • Integrate with external systems (analytics, billing, notifications)
  • Implement authentication and authorization
  • Monitor stream health and performance
Webhook event flow

How Webhooks Work

1

Event Occurs

An event happens in AMS (e.g., stream starts, recording completes)
2

Webhook Triggered

AMS sends an HTTP POST request to your configured webhook URL
3

Your Server Processes

Your endpoint receives the event data and processes it
4

Response Sent

Your server responds with HTTP 200 to acknowledge receipt

Configuration

Application-Level Webhook

Set a global webhook URL for all streams in your application:

Stream-Level Webhook

Set a webhook URL for a specific stream:
Stream-level webhooks override application-level webhooks for that specific stream.

Webhook Settings

Webhook Events

Ant Media Server sends webhooks for various stream lifecycle events:

Stream Events

Playback Events

Error Events

Conference Events

Webhook Payload

Standard Fields

Every webhook includes these fields:

Event-Specific Fields

liveStreamStarted

liveStreamEnded

vodReady

publishTimeoutError

Webhook Implementation

The webhook notification logic is in AntMediaApplicationAdapter.java:

Building a Webhook Endpoint

Node.js / Express

Python / Flask

PHP

Authentication Webhook

Use webhooks to authenticate publishers and players:

Configuration

Authentication Flow

When enabled, AMS calls your auth webhook before allowing publish/play:

Auth Webhook Payload

Auth Endpoint Example

Your auth webhook must respond quickly (< 2 seconds) or the connection will timeout. Keep authentication logic simple and fast.

Stream Status Updates

Get periodic webhook updates about stream status:
Every 10 seconds, AMS will send:
Set to -1 to disable periodic status updates (only send on start/end events).

Retry Logic

Configure retry behavior for failed webhook calls:
If your endpoint fails (non-200 response or timeout):
  • AMS retries up to webhookRetryCount times
  • Waits webhookRetryDelay milliseconds between attempts
  • Logs failures for debugging

Security

Verify Webhook Source

Validate that webhooks come from your AMS instance:

IP Whitelisting

Restrict webhook access to your AMS server IP:

HTTPS Only

Always use HTTPS for webhook URLs in production:

Best Practices

Respond Quickly

Always return HTTP 200 immediately. Process webhook data asynchronously to avoid timeouts.

Idempotency

Design endpoints to handle duplicate webhooks gracefully. Use event IDs to track processed events.

Error Handling

Log all webhook failures. Implement dead letter queues for failed events that need manual review.

Monitor Performance

Track webhook processing times. Set up alerts for failed webhook deliveries.

Troubleshooting

Check:
  • Webhook URL is publicly accessible
  • Firewall allows incoming connections
  • SSL certificate is valid (for HTTPS)
  • Endpoint returns 200 status code
Debug:
Causes:
  • Slow endpoint response time
  • Network latency
  • Retry attempts after failures
Solutions:
  • Optimize endpoint to respond in < 200ms
  • Use async processing for heavy operations
  • Monitor network connectivity
Issue: Webhook payload missing expected fieldsReasons:
  • Field not set in stream metadata
  • Using older AMS version
  • Event type doesn’t include that field
Solution: Check event-specific payload format and ensure required data is set in stream configuration