Total Chaos home page
Documentation sections
Available Last updated 2026-09-05

HTTP / Webhooks Integration

Send HTTP requests from CueForge cues, and receive HTTP into CueForge via Control Mapping.

Available

CueForge supports HTTP in both directions: HTTP Cues send requests to external endpoints, and Control Mapping receives HTTP requests to fire cues and show actions.

Sending HTTP from CueForge

An HTTP Cue sends a request when it fires in the show:

  • Endpoint Profile (with a Manual URL fallback)
  • Method — GET, POST, PUT, PATCH, or DELETE
  • Timeout, Body, and Headers
  • A Test Request button in the cue editor sends the request immediately

Typical targets: webhooks, REST APIs, logging services, networked show equipment with an HTTP interface.

Receiving HTTP into CueForge

CueForge receives HTTP through Control Mapping. Enable the HTTP listener in Settings → Triggers & Control (choose the port), then open Window → Control Mapping to author mappings that match a method and path to cue actions or global show actions.

Note: The listener always returns HTTP 200 and matches on method + path only. Request bodies are not matched in this beta. Receiving is verified with real tools such as curl; each request executes exactly once.

See Control Mapping and the Trigger Inbox for the full authoring workflow.

Requirements

  • For sending: a reachable endpoint, a valid URL and method, and network access to the target host
  • For receiving: the HTTP listener enabled in Settings → Triggers & Control and the sending system pointed at CueForge’s port

Test procedure

  1. For sending: verify the endpoint independently with curl or a REST client, then create a test HTTP Cue and use its Test Request button.
  2. For receiving: enable the listener, send a matching request, then map the source from Sources or the Trigger Inbox’s Approve (Learn is MIDI-only in this beta) — or use the Trigger Inbox’s Test on a proposal.
  3. Only after both directions behave, connect production endpoints.

Show safety notes

  • Verify endpoint behaviour independently before showtime.
  • Do not rely on HTTP responses for critical safety functions.
  • Use HTTPS where possible; avoid sending sensitive data over unencrypted connections.
  • Treat endpoint failure as a normal condition and design cues accordingly.

Current limitations

  • No retry logic; failed requests do not block cue playback.
  • The receiving listener matches method + path only and always returns 200.
  • Timeout behaviour is OS-dependent.