Sitelet https://docs.shipstatic.com/api-key
ShipStatic Docs llms.txt llms-full.txt

Your API key is a persistent credential that authenticates all programmatic access to ShipStatic.

Format

ship-{32 hex characters}

Every key starts with the ship- prefix.

Properties

Property Value
Lifetime Persistent — never expires
Scope Full account access
Per account One
Revocable Yes — regenerate from the Web console

Where to find it

Your API key is available in the Web console under Settings > API key.

Usage

The CLI, SDK, and API all authenticate with your API key:

# CLI — flag or environment variable
ship ./dist --token ship-your-api-key
export SHIP_TOKEN=ship-your-api-key
// SDK — constructor option
new Ship({ token: 'ship-your-api-key' });
// API — Authorization header
Authorization: Bearer ship-your-api-key

Configuration

Store your API key once and every tool picks it up:

Method Used by
SHIP_TOKEN environment variable CLI, SDK
~/.shiprc file CLI
--config <file> CLI
Constructor option SDK
Authorization header API

Run ship config to store your key interactively. It writes ~/.shiprc owner-only (0600), like ~/.netrc.

Note: file config is read by the CLI only. SDK consumers — and SDK-based integrations like the MCP server and the VS Code extension — get credentials from constructor options or SHIP_TOKEN, never from your dotfile. The n8n node is not one of them: it calls the API over direct HTTP with no dependencies, and its credential lives in n8n's own encrypted credential store.

No repository file is ever read. A .shiprc or package.json in your working directory is ignored, so cloning a repository can never change which account you deploy to or where your credential is sent. Per-project or per-environment configs work through --config <file> (ship --config dev.shiprc ...) or SHIP_TOKEN.

API Key vs Token

For CI and integrations, consider Tokens instead. Tokens are scoped to deploys, support an optional TTL, and are revocable, which makes them safer for both.

Both travel the same way — --token, SHIP_TOKEN, or the token constructor option — and the value's prefix says which it is: ship- for an API key, deploy- for a deploy token. There is one credential slot, so there is no precedence to reason about: you pass one value, and the platform classifies it.

Security

  • Never commit your API key. Treat it like a password — anyone with the key has full account access (deployments, domains, billing settings, the lot).
  • Don't paste it into shared chats, screenshots, or pull requests. It won't appear in API responses or logs once stored.
  • Use Tokens for CI and integrations. Scoped to deploys, optionally time-limited, easy to revoke.
  • Regenerate on suspected leak. Regeneration replaces the key — the old one stops working immediately. In-flight requests using the old key fail.
  • One key per account. Rotation is the recovery path; there is no "secondary key" mechanism.