Broadcaster
A broadcaster whose ad reporting and playout automation depend on knowing exactly when a break started
Streaming platformExploringBuilt by Professional ServicesLast updated 29 July 2026
SCTE Markers Web HooksDownstream notification the moment an ad break starts
Downstream systems find out about an ad break by asking repeatedly, which means they always find out slightly too late. This POC investigates pushing an SCTE-35 marker to downstream systems as a webhook the moment it appears in the stream, so automation reacts to the break instead of discovering it afterwards.
The problem this solves
Ad break signalling is present in the stream as SCTE-35 markers, but most downstream systems - ad decisioning, reporting, social automation, alerting - have no way to be told about it. They poll an API, or they infer it from playlist changes, and either way they act on information that is already stale by the time they have it.
Polling also scales badly in the wrong direction: the more channels you run, the more requests you make to find out that nothing has happened. The cost is paid continuously, while the event it is looking for happens rarely.
Who this is for
This is relevant if you are:
Telco
A telco or platform operator running multiple channels where per-channel polling has become the dominant load
Developer
A developer or integration team wiring ad decisioning and analytics to live channels and currently writing polling loops
The approach we are investigating
- 1Detect SCTE-35 markers in the live stream as they pass, rather than reconstructing them from manifest changes.
- 2Normalise each marker into a single event shape that carries the channel, the marker type and the exact time it occurred.
- 3Deliver that event to subscriber endpoints as a webhook, with retry and ordering guarantees defined up front rather than assumed.
- 4Establish what delivery guarantees downstream systems actually need, because that decides whether this can stay simple.
What makes it different
Signalling ad breaks is not a new problem, but it is nearly always solved inside one vendor's stack, which means the systems that most need the event are the ones least able to subscribe to it. The point of this POC is that the marker becomes an ordinary webhook any system can consume, without that system needing to understand transport streams or manifests at all.
Current status & next steps
ExploringReviewed 29 July 2026
This is an early concept and nothing is deployed. There is no demo on this page because there is nothing yet worth putting in front of a visitor - that is what the Exploring status means here.
The open question is delivery semantics: at-least-once with duplicates is straightforward, exactly-once is not, and which one is required depends entirely on what the subscriber does with the event.
Are you polling for ad breaks today?
Tell us which downstream systems need to know about a break and what they do with that knowledge. That determines the delivery guarantees this has to meet.