Webhooks act as real-time messengers between Uscreen and another platform. When events like sign-ups, purchases, or video plays occur, they automatically send data to your chosen systems.
These digital notifications trigger actions without manual effort, enabling seamless workflows, data sync across platforms, and custom integrations that extend Uscreen's functionality to fit your business needs.
📝 NOTE: Webhooks are available on the App Essentials or Plus plan. If you're not currently on these plans, please get in touch with sales@uscreen.tv.
Setting Up your Webhooks
Navigate to Settings > Webhooks
Click Create Webhook
Enter the Callback URL and select an Event Type
Click Save
📝 NOTE: Webhooks are an advanced feature that requires technical knowledge of APIs and external data management. While our Support team can help with Uscreen-related issues (such as webhook triggers not firing), we are unable to assist with custom configurations or third-party integrations. If you're not familiar with webhooks, we recommend working with a qualified developer or technical expert.
Webhooks by Zapier
You can extend Zapier's functionality by using Uscreen's webhooks as triggers. Search for Webhooks by Zapier to generate a Custom Webhook URL (Callback URL).
💡 TIP: Be sure to double-check the Callback URL that you enter to ensure proper connection.
Event Types & Payloads
Subscription Assigned
Triggers when:
A member completes a checkout purchase
An admin manually assigns a subscription
A "try again for free" marketing automation fires
{
"user_id": "user.id",
"user_name": "user.name",
"display_name": "user.display_name",
"user_email": "user.email",
"subscription_id": "offer.id",
"subscription_title": "offer.title",
"transaction_id": "last_paid_invoice.payment_id",
"event": "subscription_assigned"
}Compatibility: ✅ Web | ✅ Admin | ✅ Apps | ✅ API
ℹ️ INFO: transaction_id will be null for plans with a free trial where no payment has been made yet. Use the Assigned Offer event for content and bundle access.
User Created
Triggers:
checkout account creation
admin manually creates a user
YouTube lead generator
giveaway funnel
landing page email capture
{
"id": "user.id",
"email": "user.email",
"name": "user.name",
"tags": ["tag1", "tag2"],
"utm_source": "string",
"utm_medium": "string",
"utm_term": "string",
"utm_content": "string",
"utm_campaign": "string",
"opted_in_for_news_and_updates": true,
"opted_in_for_community_updates": true,
"event": "user_created"
}Compatibility: ✅ Web | ✅ Admin | ✅ Apps | ✅ API
User Updated
Triggers when:
A member updates their profile information
A member updates their Display Name
A subscription status changes (trial ➤ active ➤ former ➤ etc.)
An admin deletes a member account
ℹ️ INFO: The legacy_id field is useful for creators migrating from other platforms who need to match records between systems.
{
"id": "user.id",
"email": "user.email",
"changes": {
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"subscription_status": "user.subscription_status",
"lifetime_spent": "user.lifetime_spent",
"bounced_email": "user.bounced_email",
"status": "user.status",
"field_1": "user.field_1",
"field_2": "user.field_2",
"field_3": "user.field_3",
"tags": ["tag1", "tag2"],
"opted_in_for_news_and_updates": true,
"opted_in_for_community_updates": true,
"legacy_id": "user.legacy_id"
},
"attributes": {
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"subscription_status": "user.subscription_status",
"lifetime_spent": "user.lifetime_spent",
"bounced_email": "user.bounced_email",
"segments": ["user.segments"],
"status": "user.status",
"origin": "user.creation_source",
"tags": ["tag1", "tag2"],
"opted_in_for_news_and_updates": true,
"opted_in_for_community_updates": true,
"legacy_id": "user.legacy_id"
},
"event": "user_updated"
}Compatibility: ✅ Web | ✅ Admin | ✅ Apps | ✅ API
ℹ️ INFO: The changes field includes only the modified data. The attributes field contains all current user data, regardless of what changed. This event also fires when an admin deletes a member's account. Segment data is available in the attributes field, but segment changes do not trigger this event on their own.
Order Paid
Triggers when:
An invoice is marked as paid (including $0 invoices)
{
"id": "invoice.id",
"title": "offer.title",
"total": "invoice.original_price",
"amount": "invoice.final_price",
"discount": "invoice.discount",
"offer_id": "offer.id",
"customer_name": "user.name",
"display_name": "user.display_name",
"customer_email": "user.email",
"user_id": "user.id",
"user_legacy_id": "user.legacy_id",
"country_code": "purchase_location.country_code",
"transaction_id": "invoice.payment_id",
"ip_address": "purchase_ip",
"origin": "order.provider_name",
"coupon": "coupon.title",
"localized_amounts": {
"currency": "invoice.localized_currency",
"total": "invoice.localized_original_price",
"amount": "invoice.localized_final_price",
"discount": "invoice.localized_discount"
},
"event": "order_paid"
}Compatibility: ✅ Web | ✅ Admin | ❌ Apps | ❌ API
Access Canceled
Triggers when:
A member cancels their subscription from the User Dashboard
An admin cancels a subscription from the People page
{
"id": "ownership.id",
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"user_id": "user.id",
"user_legacy_id": "user.legacy_id",
"offer_id": "offer.id",
"offer_title": "offer.title",
"ip_address": "purchase_ip",
"origin": "ownership.creation_source",
"currency": "ownership.currency",
"coupon": "coupon.title",
"transaction_id": "last_paid_invoice.payment_id",
"event": "subscription_canceled"
}Compatibility: ✅ Web | ✅ Admin | ✅ Apps | ✅ API
ℹ️ INFO: transaction_id will be null for plans with a free trial where no payment was made. This event does not fire if access is revoked using End Membership or due to an overdue invoice.
Recurring Payment Successful
Triggers when:
A recurring subscription payment is successfully processed (does not fire for the initial subscription charge)
{
"id": "ownership.id",
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"user_id": "user.id",
"user_legacy_id": "user.legacy_id",
"offer_id": "offer.id",
"offer_title": "offer.title",
"ip_address": "purchase_ip",
"origin": "ownership.creation_source",
"currency": "ownership.currency",
"coupon": "coupon.title",
"transaction_id": "last_paid_invoice.payment_id",
"amount": "last_paid_invoice.final_price",
"paid_at": "last_paid_invoice.paid_at",
"next_billing_date": "ownership.next_billing_date",
"event": "success_recurring"
}Compatibility: ✅ Web | ✅ Admin | ✅ Apps | ✅ API
ℹ️ INFO: transaction_id will be null for plans with a free trial. The three new fields: amount, paid_at, and next_billing_date, allow integrations to log what was charged and schedule follow-up workflows (such as loyalty emails before the next renewal) without needing a separate API call.
Began to Play Video
Triggers when:
A member clicks Play on a video (fires only once per video per user)
{
"title": "content.title",
"id": "content.id",
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"user_id": "user.id",
"chapter_id": "chapter.id",
"event": "video_play"
}Compatibility: ✅ Web | ❌ Admin | ✅ Apps | ❌ API
📝 NOTE: This event triggers only once per video per user and does not indicate whether the video was watched in full. As of March 2025, this webhook is also supported on Android TV, Fire TV, and Samsung TV apps.
User Signed In
Triggers when:
A member signs into Uscreen via web or app (does not trigger on website or app opens, only actual sign-ins)
{
"id": "user.id",
"email": "user.email",
"name": "user.name",
"display_name": "user.display_name",
"utm_source": "string",
"utm_medium": "string",
"utm_term": "string",
"utm_content": "string",
"utm_campaign": "string",
"opted_in_for_news_and_updates": true,
"opted_in_for_community_updates": true,
"event": "user_signed_in"
}Compatibility: ✅ Web | ✅ Admin | ✅ Apps | ❌ API
Added to Favorites
Triggers when:
A member adds a video to their default "Favorites" playlist
{
"title": "content.title",
"id": "content.id",
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"user_id": "user.id",
"collection_id": "collection.id",
"event": "added_to_favorites"
}Compatibility: ✅ Web | ❌ Admin | ✅ Apps | ❌ API
Invoice Overdue
Triggers when:
An invoice is marked as overdue due to a failed payment
💡 TIP: The origin field contains the invoice's payment provider.
🔗 Learn more about Payment Origins and Values
{
"invoice_id": "invoice.id",
"user_id": "user.id",
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"title": "offer.title",
"final_price": "invoice.final_price",
"offer_id": "offer.id",
"transaction_id": "invoice.payment_id",
"origin": "invoice.provider_name",
"localized_amounts": {
"currency": "invoice.localized_currency",
"amount": "invoice.localized_final_price"
},
"event": "invoice_overdue"
}Compatibility: ✅ Web | ✅ Admin | ❌ Apps | ❌ API
ℹ️ INFO: The name and email fields may be null for older records where user data was not captured at the time of the invoice.
Assigned Offer
Triggers when:
A member purchases an offer at checkout (content, subscriptions, bundles)
An admin manually assigns an offer
{
"id": "ownership.id",
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"user_id": "user.id",
"user_legacy_id": "user.legacy_id",
"offer_id": "offer.id",
"offer_title": "offer.title",
"ip_address": "purchase_ip",
"origin": "ownership.creation_source",
"currency": "ownership.currency",
"transaction_id": "last_paid_invoice.payment_id",
"event_date": "today",
"event": "ownership_created"
}Compatibility: ✅ Web | ✅ Admin | ✅ Apps | ✅ API
Payment Method Updated
Triggers when:
A member updates their payment method
{
"id": "user.id",
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"custom_fields": "user.custom_fields",
"origin": "user.creation_source",
"tags": ["tag1", "tag2"],
"opted_in_for_news_and_updates": true,
"opted_in_for_community_updates": true,
"event": "payment_method_updated"
}Compatibility: ✅ Web | ✅ Admin | ✅ Apps | ❌ API
Live Stream Pre-Registration
Triggers when:
A member registers for an upcoming live stream
{
"id": "live_event.id",
"name": "user.name",
"display_name": "user.display_name",
"email": "user.email",
"event": "live_event_preregistered"
}Field Values Reference
Origin
The origin field means different things depending on which webhook it appears in.
Here's a breakdown by context:
User Origin
Appears in: User Created, User Updated (Attributes), User Signed In, Payment Method Updated. Describes how the member's account was originally created.
Value | Description |
| Signed up via your website |
| Signed up via your mobile or TV app |
| Signed up using Google |
| Signed up using Apple |
| Invited individually by an admin |
| Added via bulk invite by an admin |
| Joined via a team subscription invite |
| Joined via a group subscription invite link |
| Created via Zapier |
| Created via the Publisher API |
| Imported via data migration |
| Joined via gift card redemption |
| Joined via a donation |
| Account created through an abandoned checkout flow |
| Registered for a live event before having an account |
Ownership Origin
Appears in: Access Canceled, Recurring Payment Successful, Assigned Offer. Describes how the member originally gained access to the subscription or offer.
Value | Description |
| Member purchased directly |
| Admin manually assigned access |
| Access granted via Zapier |
| Access granted via the Publisher API |
| Access imported via data migration |
| Access granted via gift card |
| Access granted via donation |
| Access via a group subscription |
| Access via a group subscription invite link |
| Mobile External Purchase via iOS app |
| Mobile External Purchase via Android app |
| Mobile External Purchase (legacy, for older records only) |
Payment Provider Origin
Appears in: Order Paid, Invoice Overdue. Describes the payment provider used for the transaction.
Value | Description |
| Paid via Stripe (most common) |
| Paid via PayPal (legacy) |
| Paid via native PayPal integration |
| Paid via Amazon Appstore |
| Paid via Google Play Store |
| Paid via Apple App Store |
| Paid via Authorize.Net |
| Paid via Braintree |
| Paid via Roku Channel Store |
| Internal Uscreen transaction |
| No payment provider recorded (legacy records only) |
Segment
Appears in: User Updated (Attributes only). Automatically assigned by Uscreen based on a member's subscription activity. A member can belong to multiple segments simultaneously.
Value | Description |
| Has an active subscription |
| Currently in a free trial period |
| Purchased a one-time offer (content or bundle) |
| Subscription is currently paused |
| Had a subscription but no longer active |
| Signed up but has not yet purchased |
| Provided their email only, with no purchase or account |
📝 NOTE: Segments are automatically calculated by the system and cannot be manually set by admins or members. Segment changes do not trigger the User Updated webhook on their own.
Subscription Status (legacy)
Appears in: User Updated (Changes, Attributes). Reflects the member's overall subscription state. Retained for backward compatibility.
Value | Description |
| Has never had a subscription |
| Currently in a free trial |
| Active, paid subscription |
| Subscription on hold due to unpaid invoices |
| Previously had a subscription, no longer active |
| Subscription is currently paused |
📝 NOTE: This is a legacy field retained for backward compatibility. pending_cancellation and pending_pausing have been removed from this field, and they now appear in Subscription Activity Status instead. For new integrations, we recommend using Subscription Activity Status for more accurate subscription change tracking.
Subscription Activity Status (new)
Appears in: User Updated (Changes Subscription Activity Status, Attributes Status). Describes the type of subscription change that just occurred, rather than the member's overall state. This field is transient, and it reflects a recent change, not a permanent status.
Value | Description |
| First-time subscriber who just started paying or converted from a trial |
| Former subscriber who has reactivated their subscription |
| Moved to a higher-priced plan or longer billing period |
| Moved to a lower-priced plan or shorter billing period |
| Subscription scheduled to cancel at the end of the current period |
| Subscription scheduled to pause at the end of the current period |
| Subscription is on hold due to unpaid invoices |
| Subscription is currently paused |
ℹ️ INFO: In the webhook payload, this field appears as status inside the changes and attributes blocks of the User Updated event. The subscription_activity_status label is the current standard status is kept as a backward-compatible alias.
Management and Best Practices
Response Handling
Your server must return a 200 HTTP status code within 5 seconds to acknowledge receipt
Any other response, including redirects (3xx), is considered a failure
Response body and headers are ignored
Retry System
If no valid response is received, the webhook will retry up to 3 times within a maximum interval of 15 minutes
If all retries fail, admin users will receive an email notification about the failure
📝 NOTE: If your store has multiple webhook endpoints configured for the same event, be aware that a failed delivery may cause retries to all endpoints, including ones that already received the event successfully. To avoid duplicate processing, we recommend implementing idempotency logic on the receiving end.
Processing Time
Webhooks are processed asynchronously and may sometimes experience a short delay depending on system load. User-related events (
user_created,user_updated) include a brief built-in delay to ensure all member data, including segment and tag updates, is fully reflected in the payload before it's sent.
Duplicate Events
Webhooks are not guaranteed to be delivered exactly once. This is standard behavior in most webhook-based systems.
Even if your server responds correctly, network latency or processing delays can cause retries, resulting in duplicate webhook calls.
💡 TIP: Implement idempotency logic on the receiving end to detect and handle duplicate webhook events.
Rate Limits
Uscreen maintains system stability with the following rate limits:
General API rate limit: 100 requests per minute
Sessions endpoint: 10 calls per 5 minutes
Webhook processing: Up to 100 requests per minute
⚠️ WARNING: Exceeding these limits will return a 429 (Too Many Requests) error.
Deliverability & Reliability
While 100% delivery cannot be guaranteed, Uscreen includes built-in fail-safes:
If a webhook process fails, events are queued locally and retried when connectivity is restored
Each webhook event is attempted up to 3 times to improve deliverability
💡 TIP: Schedule a monthly data backfill to ensure that you capture any missing webhook data.
Common Use Cases
Webhooks enable a wide range of workflows to elevate your Uscreen experience:
Marketing Automation
Add new users to your email marketing platform
Trigger personalized email sequences when users watch specific videos
External Invoicing
Connect with 3rd-party shop platforms like Shopify, WooCommerce, etc.
Forward user data to external invoice systems
Analytics & Reporting
Send viewing data to external analytics platforms
Track user engagement across multiple platforms
Customer Support
Trigger support tickets based on user behavior patterns
Sync customer information with your help desk software
FAQs
My webhook isn't firing. What should I check?
My webhook isn't firing. What should I check?
First, verify that the Callback URL is correctly entered under Settings > Webhooks and that your server is returning a 200 HTTP status code within 5 seconds. Check that the event type you selected matches the action you're testing. Also, confirm that the feature being tested is compatible with the delivery channel, as some events don't fire via the API or mobile apps. See the Compatibility row under each event for details.
Why is my webhook firing twice?
Why is my webhook firing twice?
Webhooks are not guaranteed to be delivered exactly once, and retries can occasionally cause duplicate events. This is standard behavior. We recommend implementing idempotency logic on your receiving server to detect and safely ignore duplicate deliveries.
Why does the user_updated webhook sometimes show outdated segment or tag data?
Why does the user_updated webhook sometimes show outdated segment or tag data?
User webhooks include a short built-in delay to ensure segment and tag updates are fully applied before the payload is sent. If you're seeing stale data, check that your receiving server is processing the full attributes block, which always contains the member's latest state.
Why is the subscription status briefly showing active before going on_hold?
Why is the subscription status briefly showing active before going on_hold?
This is expected behavior. When a payment fails, Stripe processes the event in stages, and the subscription briefly passes through active before transitioning to on_hold. This means you may receive two user_updated events in quick succession. Use the subscription_activity_status field to distinguish what type of change actually occurred.
Can I receive webhooks for video comment activity?
Can I receive webhooks for video comment activity?
A new video_comment_created webhook event may be coming soon, where it will fire when a member posts a comment on a video. This event is not yet available but will be documented here once released.
I need help setting up a custom integration with webhooks. Can Uscreen Support help?
I need help setting up a custom integration with webhooks. Can Uscreen Support help?
Our Support team can help with Uscreen-related issues, such as webhook triggers not firing or payload questions. For custom integration development, we recommend working with a qualified developer or Uscreen expert.