Authentication

Base URL: https://api.skip2.net/v1/

Every authenticated endpoint requires a valid API key. Keys are tied to a single user account and act on that account’s active organization.

Presenting your key

Send the key on each request using either header (the Authorization header is preferred):

Authorization: Bearer sk2_a1b2c3d4e5f6a7b8.<secret>
X-API-Key: sk2_a1b2c3d4e5f6a7b8.<secret>

Key format

A full key has two parts separated by a dot:

sk2_a1b2c3d4e5f6a7b8 . <secret>
└─────── prefix ─────┘   └ secret ┘

The prefix (sk2_...) is a non-secret public identifier used to look up the key and is shown in the dashboard. The secret is shown to you exactly once at creation time and is stored only as a salted hash — Skip2 cannot recover it for you. If you lose it, revoke the key and create a new one.

The account-level toggle

API access has a global on/off switch per account, independent of individual keys. While the toggle is off, every request is rejected with api_disabled even if the key itself is valid. Enable it under Account → API.

What is checked on every request

The API validates, in order:

  1. The key exists and the presented secret matches the stored hash.

  2. The key has not been revoked (key_revoked).

  3. The key has not expired (key_expired).

  4. The key is enabled (key_disabled).

  5. The account’s global API toggle is on (api_disabled).

  6. The account is not locked (account_locked).

  7. The request’s source IP is permitted by the key’s IP allowlist (ip_not_allowed).

On success the key’s last_used_at timestamp and last_used_ip are updated.

IP restrictions

A key may optionally be restricted to a set of source IP addresses or CIDR ranges. When set, requests from any other address are rejected with HTTP 403 and the code ip_not_allowed. A key with no allowlist may be used from any address. See API Key Management for how to configure this.

Authentication failures

Authentication failures return HTTP 401 (bad or missing credentials) or 403 (the key is valid but not permitted), for example:

{
  "success": false,
  "error": {
    "code": "key_expired",
    "message": "This API key has expired."
  }
}

See Responses & Errors for the full list of error codes.

Write operations and maintenance windows

Mutating requests (POST/PUT/PATCH/DELETE/PURGE) are additionally subject to:

  • Account read-only mode — a soft-locked account may read but not write, returning read_only (HTTP 403).

  • Emergency Power Off (EPO) — during a platform maintenance window the relevant operation may be temporarily disabled, returning service_unavailable (HTTP 503). Read endpoints remain available.