URL Sequencer Target

Introduction

The URL Sequencer Target fires a timed sequence of HTTP GET requests at up to ten different URLs. Each request has its own delay (measured from the start of the sequence) and reports its own live status, so a multi-step automation flow — notify a control system, start a cloud encoder, pull a CDN cache, post a "we're live" webhook — runs from a single Composer target with predictable timing.

The whole sequence can be configured to repeat on a fixed cadence with an optional cap on the number of iterations, useful when the same set of calls needs to run throughout a show rather than once at startup. Each request optionally fires a Script Engine callback with the response body, so a single sequence can drive logic in your project script — parse a JSON status payload, update on-screen graphics, write the result to a project property.

For a single one-shot HTTP call without a timeline, the HTTP Target is the simpler tool. For more elaborate automation that needs custom HTTP methods, headers, or request bodies, drive HTTP requests directly from the Script Engine — the URL Sequencer is purpose-built for the timeline-of-GETs case.

How a sequence runs

When the target starts (manually via StartCommand, automatically via AutoStart, or remotely via the HTTP API / a Connector), a stopwatch starts at zero and each configured URL fires when its Delay elapses:

• Delays are measured from the start of the sequence, not from the previous request. URL 1 with delay 0, URL 2 with delay 500, URL 3 with delay 2000 produces a sequence at 0 ms / 500 ms / 2000 ms — the gap between URL 2 and URL 3 is 1500 ms, not 2000 ms.
• Empty URL slots are skipped silently. The sequence simply moves on to the next configured slot. This makes it natural to leave a gap-free 2–4 URL sequence configured even when slot 5+ is unused.
• URLs must include the scheme (http:// or https://) — bare hostnames are rejected. The component's verifier marks malformed URLs in the per-slot status field at startup.
• Per-slot Status updates live as each request completes — sent, HTTP status code on success, timed out, or the error string on failure. Useful while authoring a sequence and as a runtime diagnostic.
• Repeat Sequence loops the entire sequence after Repeat Delay ms have elapsed since the last request fired. Max Repeats bounds the iteration count (0 = unlimited); RepeatCounter tracks how many full passes have run since StartCommand.
• Reset rewinds the sequence to the start without firing anything — useful when iterating on URL or delay changes.

URL slots 2 through 10 live behind an expandable More URLs section in the property panel so the common case (1–2 URLs) stays compact. Three commands — Start, Stop, Reset — are surfaced in the panel as a single button strip and listed in the property table below.

• Pre-show automation — at the top of a broadcast: notify a control system, start cloud encoders, arm cameras, post a "we're live" webhook, all on the cadence you choose.
• Webhook orchestration — fire several webhooks in a known order with controlled delays between them (cache invalidate → CDN pull → notify subscribers).
• Keep-alive / heartbeat — re-fire a small sequence at a fixed cadence to keep upstream services from timing out, or to publish a periodic status ping. Set RepeatSequence = true and a sensible Repeat Delay.
• Scripted health checks — hit several endpoints in turn at the start of a show to confirm every system is reachable before going on air; pair with RequestResponseCallback to flag any non-200 response.
• Show-end teardown — at the close of a programme: stop cloud encoders, post a "we're done" webhook, ping a notification service. A second URL Sequencer Target instance handles teardown on its own schedule.
• Script-Engine integration — each request can fire a callback with the response body, so the sequence can drive logic in your project script (parse JSON, update on-screen graphics, gate other actions on a service's response).

Limitations

• GET only — no POST, PUT, DELETE. For methods other than GET, drive HttpClient from the Script Engine.
• No custom headers or request body — the URL itself is the entire request shape. For Authorization: Bearer …, a JSON body, or any non-trivial header, use a Script Engine fetch or the HTTP Target.
• Default timeout — uses .NET's default HttpClient timeout (≈100 seconds). Slow endpoints stretch the perceived sequence duration; if the Script Engine callback is wired up, the timeout result surfaces there too.
• No retries — a failed request is reported in the slot's Status and the sequence moves on. Wrap retry logic on the outside (Connector / Script Engine) when a request must succeed.

URL Sequencer Target - Settings

URL 1

URL 1 — the first endpoint in the sequence.

More URLs

More URLs — expand to configure additional URLs (2-10) in the sequence.

Repeat Settings

Repeat Settings — make the whole sequence loop and bound the number of repeats.

Status

Status — overall state of the sequence and counters for sent/failed requests.

Action

Action — start, stop and reset the sequencer; pick how validation issues are logged.

Script Callback

Script Callback — hook a Script Engine function into per-request response handling.

Inherits from: AbstractTarget.

See also: URL Sequencer Target in Script Engine Objects.

Driving from outside

Three command properties drive the target: StartCommand, StopCommand, ResetCommand. They're invokable from the property panel, from a Script Engine script, from the HTTP API (/api/invokecommand?targetname=URL+Sequencer+Target&command=StartCommand), or via a Connector. Per-slot URLs and delays can be reconfigured at runtime via /api/setproperty so a single target can serve different URL sets across different shows without re-authoring the project.

The RequestResponseCallback property names a Script Engine function called once per request as soon as the response arrives. The script receives a JSON object with the URL slot id, status code, response body, request timestamp, and response time — handy for dispatching logic on per-endpoint outcomes:

function OnSequencerResponse(data) {
    Log.Info("URL " + data.urlId + " → " + data.statusCode + " in " + data.responseTimeMs + " ms");
    if (data.statusCode !== 200) {
        SetObjectProperty("Status Indicator", "Visible", true);
    }
    if (data.urlId === 1 && data.responseBody) {
        const payload = JSON.parse(data.responseBody);
        SetObjectProperty("Score Display", "Text", payload.score);
    }
}

RepeatCounter and the per-slot UrlNStatus properties surface as readable HTTP API state too, so a dashboard can monitor sequence progress without watching the property panel.

Related components

• HTTP Target — single one-shot URL call with response capture. Reach for it when the timeline / repeat features of URL Sequencer aren't needed.
• Connectors — visual action sequences that can include HTTP calls alongside scene / layer / target operations. Use a Connector when you want to interleave HTTP calls with non-HTTP actions (switch a scene, mute an input) on the same trigger.
• Script Engine — full programmability for custom HTTP methods, headers, bodies, retries, and conditional flows. Reach for the Script Engine when the request shape exceeds what a URL string can express.