---

name: runway-install-auth description: >- Install and verify a server-side Runway Dev client without spending generation credits or exposing an organization key. Use when bootstrapping or rotating an integration. Trigger with: "configure Runway API", "install Runway SDK", "verify Runway authentication". allowed-tools: Read, Grep, Write, Edit version: 2.0.0 argument-hint: '[node|python|rest]' model: inherit effort: high license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags:

• saas
• runway
• authentication
• sdk
• secrets compatibility: 'Requires server-side Runway Dev access, current first-party documentation, an approved credit budget, and controlled media storage.'

---

Secure Runway SDK and REST Bootstrap

Overview

Establish a reproducible client, explicit API-version contract, and non-billable authentication probe. Runway API keys are organization-scoped credentials, so a working client is not evidence that a user should retain access or that a billable generation is approved.

Prerequisites

• Runway Dev organization and an operator authorized to manage API keys
• Node.js 18+ or Python 3.8+, or an HTTP client for the REST path
• A secret manager and a reviewed X-Runway-Version value

Instructions

Step 1: Discover the integration boundary

Use Read and Grep to locate runtime manifests, lockfiles, existing Runway clients, environment-variable names, and browser/server boundaries. Separate Runway Dev API access from the consumer Runway web application and from the OAuth-based Runway Dev MCP.

Step 2: Resolve and pin the client

Choose @runwayml/sdk, runwayml, or direct REST. Query the package registry and official SDK page at implementation time, review the changelog, and pin the selected compatible version in the project lockfile instead of copying a stale version from this skill.

Step 3: Provision the key safely

Create or rotate a key in the Developer Portal under the intended organization. Store it as RUNWAYML_API_SECRET in the deployment secret manager. Never place it in source, logs, screenshots, browser bundles, MCP configuration, or client-visible environment variables.

Step 4: Configure the protocol

The official SDKs read RUNWAYML_API_SECRET and supply the version header. For direct HTTP, send Authorization: Bearer <secret> and X-Runway-Version: 2024-11-06 to https://api.dev.runwayml.com; centralize both headers in one server-side client.

Step 5: Run a read-only probe

Use a documented organization or task read endpoint that the key is authorized to access. Record status, request ID, API version, and organization identity in redacted form. Do not create a generation merely to prove authentication.

Step 6: Exercise rotation and revocation

Install the replacement key, prove the read path, switch consumers, disable the old key explicitly, and prove the old key receives 401. Removing an organization member alone does not revoke an organization-scoped key.

Authentication

Runway REST authentication is a bearer API secret plus the required X-Runway-Version header. The SDKs obtain the secret from RUNWAYML_API_SECRET; browser code must call a protected server endpoint rather than receive the secret.

Tool Discipline

Use Read and Grep to inspect application configuration, provider documentation, lockfiles, fixtures, schemas, tests, and redacted operational evidence before proposing a change. Use Write or Edit only for an approved implementation, configuration, test, runbook, or redacted receipt. Do not create, cancel, delete, retry, deploy, rotate, revoke, publish, or otherwise mutate production Runway resources without explicit operator approval.

Output

• Pinned SDK or reviewed REST-client decision
• Redacted authentication probe with organization and API-version evidence
• Key rotation, revocation, and rollback record

Return the environment, organization alias, operation and task identifiers, API and SDK versions, model or router policy, source-contract fingerprint, task-state evidence, credit boundary, output disposition, unresolved risk, rollback state, and final decision without exposing API secrets, prompt or media contents, or temporary signed URLs.

Examples

A service replaces an exposed development key. The operator loads a new secret version, proves a read-only organization call, shifts one canary worker, disables the old key, and confirms that the disabled credential fails without issuing a paid generation.

Error Handling

Failure	Response
401 from the probe	Check the complete key, organization, disabled state, bearer header, and secret-manager mapping; do not retry blindly.
Version-header rejection	Compare the reviewed official version contract and the actual outgoing request; update one central client.
Key appears in a client bundle or log	Stop rollout, revoke it, purge accessible artifacts through the approved process, and issue a replacement.

Validation

Verify the resolved dependency, lockfile, server-only secret boundary, outgoing host and headers, a successful read-only probe, and a failed-old-key rotation test. Do not report success from environment-variable presence alone.

Resources

• First-party source notes
• Runway agent context
• API reference
• Models
• Usage tiers
• Pricing
• Production checklist