Agent skill · software engineering · jeremylongshore
runway-webhooks-events
Convert authoritative Runway task polling into durable internal events or signed customer callbacks without claiming native provider webhooks. Use when downstream systems need completion notifications. Trigger with: "Runway task events", "Runway completion webhook", "notify when Runway finishes".
Why this skill is useful
Provides specific implementation patterns and error handling for the Runway webhooks API that the AI wouldn't reliably generate on its own.
What it needs
Requires python installed locally. Requires runwayml account access. About 3k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
Runway Polling-to-Event Relay Overview The documented Runway generation surface exposes task retrieval and cancellation, not a native generation-completion webhook endpoint. Build notifications by reconciling provider task state into an internal outbox, then deliver idempotent internal events or your own signed customer webhook. Prerequisites Durable operations, provider task IDs, and legal state transitions A bounded polling scheduler and transactional outbox Consumer authentication, signing, retry, and replay policies Instructions Step 1: State the authority boundary Document that Runway is polled via GET /v1/tasks/<task-id>. Do not configure a fictional provider webhook secret or tell consumers that a callback originated from Runway. Step 2: Reconcile provider state Retrieve due nonterminal tasks at five-second-or-longer jittered intervals with backoff. Treat THROTTLED as queued and accept only legal forward transitions to SUCCEEDED, FAILED, or CANCELLED. Step 3: Write state and outbox atomically Persist the newly observed state, provider evidence hash, and one outbox record in the same transaction. Use a uniqueness key such as operation ID plus state version so restarts cannot duplicate logical events. Step 4: Shape the internal event Emit internal operation ID, provider task ID, terminal state, timestamps, model or router metadata, stored-asset ID, and redacted failure class. Never emit bearer keys, prompt/media bodies, or signed provider URLs. Step 5: Deliver your callback For customer webhooks, sign exact raw bytes with your service's secret, include timestamp and event ID, retry with a bound, and expose replay and verification guidance. This is your protocol, not Runway's. Step 6: Reconcile delivery Track attempts, acknowledgements, dead letters, consumer idempotency, and asset authorization. A callback failure must not trigger a new Runway generation. Authentication Provider polling uses the server-side Runway bearer secret and version header. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/runway-webhooks-events--e79d1a