Webhooks

Overview

Webhooks are automated messages sent from our system to your application when specific events occur in your registered application. These events include successful payment processing, subscription creation, and subscription revocation.

Additionally, you can now retrieve subscription information using our new API endpoints (see API Reference documentation for details). When blockchain events occur for applications without a configured webhook URL, the system will still process the events (such as deactivating subscriptions when streams are revoked) but will not send webhook notifications.

How Webhooks Work

1

Register your app and configure webhook

You register your application with our system and configure a webhook URL.

2

Events trigger HTTP POST

When specific blockchain events occur (like payments or subscription changes), our system sends an HTTP POST request to your configured webhook URL.

3

Request contains event and signature

The request contains event data and a security signature for verification.

4

Process the payload

Your application processes the webhook payload and takes appropriate action.

Event Types

The following events trigger webhook calls:

  • stream_created: Triggered when a new subscription payment stream is created (i.e., a user successfully pays for a subscription)

  • stream_revoked: Triggered when a subscription is revoked or canceled

Webhooks are only sent for events related to registered applications that have a webhook URL configured. Events for applications without a configured webhook URL will still be processed (e.g., subscriptions will be deactivated when streams are revoked), but no webhook will be sent.

Webhook Configuration

Setting Up Your Webhook URL

1

Register your application through the Telegram bot.

2

Navigate to your app details in the bot menu.

3

Select "Изменить Webhook URL" (Change Webhook URL).

4

Enter your webhook endpoint URL.

5

For production apps, HTTPS is required.

Webhook URL Requirements

  • Protocol: HTTP or HTTPS (HTTPS required for Production mode)

  • Format: Must be a valid URL (e.g., https://yourdomain.com/webhook)

  • Availability: Must be publicly accessible from the internet

  • Security: Should validate the HMAC signature in the request header

Note: Webhooks are only sent for blockchain events related to applications that have a webhook URL configured. Events for applications without a configured webhook URL will still be processed (e.g., subscriptions will be deactivated when streams are revoked), but no webhook notification will be sent.

Webhook Payload Structure

Each webhook request contains a JSON payload with the following structure:

Payload Fields

  • updateId: The blockchain transaction hash that triggered the event

  • updateType: The type of event (stream_created or stream_revoked)

  • requestDate: ISO 8601 formatted timestamp of when the webhook was sent

  • payload: Complete invoice object containing payment details

Security: Verifying Webhook Signatures

All webhook requests include an HMAC signature in the X-Pay-Signature header for security verification.

Signature Generation

The signature is generated using the invoice's transaction hash as the data and your API key as the secret:

Where:

  • transaction_hash is the updateId field from the webhook payload

  • api_key is your application's API key

Signature Verification Process

1

Receive the webhook request body as a raw string.

2

Extract the updateId field from the JSON payload.

3

Use your API key as the secret to generate an HMAC-SHA256 hash of the updateId.

4

Compare the generated signature with the one in the X-Pay-Signature header.

Examples Verification Code

.Net (C#)

Node.js

FastAPI (Python)

Django (Python)

Java (Spring Boot)

Example Webhook Payloads

Stream Created Event

Stream Revoked Event

Error Handling and Retries

Our system implements retry logic for webhook delivery:

  • If your webhook endpoint returns a non-successful HTTP status code (not 2xx), the system will retry the request

  • Retry attempts: 3 attempts with 1-minute intervals between attempts

  • If all retries fail, the webhook will not be resent

When a stream_revoked event is received but no webhook URL is configured for the application, the system will automatically deactivate the corresponding subscription in the database without sending a webhook.

Testing Webhooks

Test Mode vs Production Mode

  • Test Mode: Webhook URLs can use HTTP or HTTPS protocols

  • Production Mode: Webhook URLs must use HTTPS protocol

Testing Your Webhook

1

Register your application in the Telegram bot.

2

Set your webhook URL to a testing endpoint (like RequestBin or webhook.site).

3

Perform a test transaction.

4

Monitor your testing endpoint to see the webhook payload.

Troubleshooting

Common Issues

1

Webhook not being received:

  • Verify your URL is publicly accessible

  • Check that your server is properly configured to handle POST requests

  • Ensure your webhook URL is correctly set in the bot

2

Signature verification failing:

  • Confirm you're using the correct API key

  • Ensure you're hashing the raw request body, not a parsed version

  • Check that your HMAC implementation matches the expected format

3

Webhook returning 404:

  • Verify your endpoint path is correct

  • Ensure your server is running and accessible

Debugging Tips

  • Use logging to capture incoming webhook requests and their headers

  • Verify that your endpoint accepts POST requests

  • Check that your server handles JSON content type properly

  • Monitor your server logs for any errors during webhook processing

Best Practices

1

Always verify signatures to ensure webhook authenticity.

2

Respond quickly to webhook requests (within 10 seconds).

3

Use HTTPS endpoints in production environments.

4

Log webhook events for debugging and monitoring.

5

Handle duplicate events gracefully (the same event might be sent multiple times).

6

Validate payload data before processing.

7

Implement idempotency to prevent duplicate processing of the same event.