Runway API X-Runway-Version header: dated versions vs Sume /v1

Every Runway API request needs an X-Runway-Version header carrying a date, such as 2024-11-06, and Runway says it supports an old version for four months after a new one is created. Sume has no date header in the docs I read: its version is the /v1 path, and the video route is POST /v1/videos.

Runway's facts are from its Core API documentation, read on 2026-10-02; the page gives the header format and the four-month window. Sume's side is from the API reference and Public API.

What does the Runway version header do?

It pins your requests to a dated version of the API. The header is mandatory, and the example date on the page is 2024-11-06. The page says old versions stay supported for four months after a newer one appears. The text I read does not list the dates of past versions or what changed between them, so read the current Runway page for the date to send.

The practical meaning is a clock: a version you pinned a year ago may be outside the support window, and the failure shows up as a refused or changed behavior rather than a compile error. Put the version string in one constant and review it on a schedule.

How does Sume version its API?

The paths carry the major version. The reference lists GET /v1/health as the versioned API health, calls the unversioned /health hidden, and puts the public routes under /v1. Video generation is https://api.sume.com/v1/videos. The docs I read do not publish a deprecation window like Runway's four months, so no such number is claimed.

What Sume does publish is a changelog of notable product and API updates, newest first, and a live OpenAPI document at GET /v1/openapi.json that is public. Treat those two as your upgrade signal.

curl https://api.sume.com/v1/health
curl https://api.sume.com/v1/openapi.json -o sume-openapi.json

What should a client do about versions?

For Runway, send the header on every call, keep the date in config and set a calendar reminder shorter than four months. For Sume, pin the path, snapshot openapi.json in CI and diff it, so a schema change fails a build rather than a production job.

Retries need the same care in both. On Sume, send an Idempotency-Key so a replayed submit returns the original job. Runway's task endpoints also matter here: its page says the way to stop a task is DELETE /v1/tasks/{id}, that the delete does not refund credits for a generation already in progress, and that aborting an SDK polling call does not cancel the task.

Which statuses and limits move with versions?

Version differences usually surface in status values and per-model limits, so test those after any bump. The two vocabularies below are what the pages list today.

Bottom line

Runway asks you to track a date, Sume asks you to track a path and a schema. Neither removes the need to read release notes. Pin the version, keep job ids, and test one small request per model after every change; the per-second rates on the Runway pricing guide and in Sume's GET /v1/videos/models can both move independently of the API version.