Ownership

#team-api-sdk owns the API Design Guidelines and these spectral rules that help teams align with them. The @zapier/zapier-sdk GitLab group is the code owner of this repository.

MRs are always welcome!

Versioning Philosophy

This ruleset ships in two major version lines:

1.x — Leveling up existing APIs

The 1.x series (latest: 1.9.0) was designed to help existing API services incrementally improve their alignment with Zapier's API Design Guidelines. Rules used warn and info severities to surface issues without blocking CI pipelines, giving teams time to address them.

Existing services can stay on 1.x. There is no requirement to upgrade — 1.x will continue to receive backported rule additions where appropriate.

2.x — Strict standards for new APIs

The 2.x series is for new API services that should come out of the box fully aligned with all key API Design Guidelines. All rules are elevated to error severity (except rate-limit/503 rules which remain info since those concerns may be handled upstream by a proxy, load balancer, or WAF).

Key differences from 1.x:

• All rules are errors — linting violations fail CI by default
• Auth schemes tightened — only anonymousServiceJwt, serviceAndUserJwt, and OAuth are allowed (legacy schemes like userJwt, apiKey, zapierSession require an exemption)
• Public API gateway requirement — APIs must pass the 2.x ruleset to be promoted to public status via api.zapier.com

New services should adopt 2.x. Zapier's API service templates will ship with 2.x lint rules configured.

Which version should I use?

| Scenario | Version | |----------|---------| | Existing service, already linting with 1.x | Stay on 1.9.0 (upgrade when ready) | | New API service | Use 2.x | | API being promoted to public via api.zapier.com | Must pass 2.x rules |

Features

Provides a Spectral linting ruleset to lint OpenAPI schemas against Zapier's API Design Guidelines.

Installation

pnpm add -D @stoplight/spectral-cli
pnpm add -D @zapier/spectral-api-ruleset

For some reason, installing the CLI globally and running spectral lint or npx spectral lint always fails to find the package. Adding the CLI as a local dependency and then running pnpm exec spectral lint does work.

Usage

CLI

There are a few ways you can use this ruleset in your projects.

You can load the ruleset in a few different ways with Spectral.

They support direct http access, via NPM, and via the local file system.

If you'd like to extend the ruleset and and even more specific rules for your API service, you can create a local spectral.yaml that extends the ruleset:

extends:
  - '@zapier/spectral-api-ruleset'

Then run:

spectral lint your-schema.yaml --ruleset .spectral.yaml

or

pnpm exec spectral lint your-schema.yaml --ruleset .spectral.yaml

or

spectral lint your-schema.yaml --ruleset https://unpkg.com/@zapier/spectral-api-ruleset@{VERSION}/.spectral.yaml

depending on whether you installed the CLI locally or globally.

See the Spectral CLI docs for more details.

CI

Use a GitLab job like the following:

openapi:lint:
  stage: validate
  before_script:
    - mkdir spectral
  script:
    - pnpm exec spectral lint your-schema.yaml -o spectral/junit.xml -f junit
  artifacts:
    when: always
    paths:
      - spectral
    reports:
      junit: spectral/junit.xml

For non-TypeScript projects, you can use the spectral docker image to avoid installing additional dependencies.

openapi:lint:
  stage: test
  image:
    name: stoplight/spectral:6.15.0
    entrypoint: [""]
  script:
    - spectral lint openapi.yaml
  only:
    - merge_requests

See Continuous Integration docs and our own openapi:lint guideance in the Engineering Index for more details.

Exemptions

Some rules in this ruleset can be exempted on a case-by-case basis with approval from #team-api-sdk. Below are the available exemptions and how to use them.

Sorting Parameter Exemption

The zapier-sorting-parameter rule requires using order_by instead of sort_by or ordering for sorting parameters. If you need to use an alternative parameter name, you can request an exemption.

paths:
  /test:
    get:
      parameters:
        - name: sort_by
          in: query
          x-zapier-sorting-parameter-exempt: true
          description: Field to sort by

Exclusionary Filter Exemptions

Two rules keep exclusionary filters (?exclude_zap_ids=1,2) consistent, and a third blocks the Django ORM lookup style they replace:

• zapier-no-orm-lookup-parameter — no __ in a query parameter name. Exempt with x-zapier-orm-lookup-exempt: true.
• zapier-exclusion-parameter-naming — exclusions must be spelled exclude_<plural field>. Exempt with x-zapier-exclusion-exempt: true.
• zapier-exclusion-parameter-shape — an array-valued exclude_* parameter must set style: form and explode: false. Exempt with x-zapier-exclusion-exempt: true.

A legacy Django-style exclusion parameter trips the first two rules at once, so exempting it fully takes both flags:

paths:
  /test:
    get:
      parameters:
        - name: owner_id__not_in
          in: query
          x-zapier-orm-lookup-exempt: true
          x-zapier-exclusion-exempt: true
          description: Owner IDs to filter out (pending rename to exclude_owner_profile_ids)

Batch Operation Exemptions

Seventeen rules enforce the batch API contract on operations whose operationId starts with batch followed by a PascalCase verb. Two flags cover them, both set on the operation:

• x-zapier-batch-operation-id-exempt: true — skips zapier-batch-operation-id-convention, the naming rule.
• x-zapier-batch-contract-exempt: true — skips the sixteen shape rules: zapier-batch-status-codes, zapier-batch-response-envelope, zapier-batch-meta-counts, zapier-batch-result-status-enum, zapier-batch-error-required-fields, zapier-batch-error-status-type, zapier-batch-request-cap, zapier-batch-over-limit-response, zapier-batch-no-atomic-flag, zapier-batch-async-handle, zapier-batch-callback-declared, zapier-batch-callback-url-naming, zapier-batch-status-envelope, zapier-batch-status-result-enum, zapier-batch-status-meta-pending and zapier-batch-idempotency-key-naming.

The same flag covers a status operation named get<Resource>Batch, so one exemption on that operation skips the status rules as well.

Note that the envelope and status rules apply to a batch callback request body as well as to the 200 response: when an asynchronous batch delivers its result to a callback_url, that payload is the batch result and carries the same contract.

The shape rules read a schema node in either of two forms — a plain object schema with properties, or the allOf composition the guidance recommends (a shared base plus a member that narrows status) — because Spectral resolves $ref before a rule runs but never merges allOf.

paths:
  /v1/assets/batch-delete:
    post:
      operationId: batchDeleteAssets
      x-zapier-batch-contract-exempt: true
      description: Legacy batch delete, still on the pre-standard response shape

Idempotency Key Exemption

Nine rules keep idempotency keys consistent with the idempotency guidance:

• zapier-idempotency-key-header-name — a header that carries an idempotency key must be named Idempotency-Key. The check ignores case.
• zapier-idempotency-key-not-in-query — an idempotency key must not be a query, path or cookie parameter.
• zapier-idempotency-key-not-in-request-body — a single-entity operation must not take an idempotency key in its request body.
• zapier-batch-idempotency-key-naming — a batch operation's per-item key must be named exactly idempotency_key. x-zapier-batch-contract-exempt: true on the operation also skips it.
• zapier-idempotency-key-not-request-level — a request body must not carry idempotency_key at its top level. A single-entity operation uses the header; a batch puts the key on each item.
• zapier-idempotency-key-header-schema — the Idempotency-Key header must be a string. A nullable string (for example a oneOf of the string and null) also passes. A declared maxLength must be at most 255.
• zapier-idempotency-key-header-max-length (warning) — the Idempotency-Key header should declare a maxLength, preferably 255.
• zapier-idempotency-key-error-responses — an operation that accepts Idempotency-Key must declare the 400 (invalid key) and 422 (key reused) responses.
• zapier-idempotency-key-conflict-response (warning) — an operation that accepts Idempotency-Key should declare the 409 (key in progress) response.

Exempt an existing field with x-zapier-idempotency-exempt: true on the parameter or the property schema. For the two response rules, set the flag on the operation or on the path item. An exempt Idempotency-Key parameter also skips them. Use the flag until the owning team ships a version that uses the header:

components:
  schemas:
    RunRequest:
      type: object
      properties:
        idempotency_id:
          type: string
          x-zapier-idempotency-exempt: true
          description: Legacy idempotency key. New clients send the Idempotency-Key header.

Glossary Term Exemption

The zapier-glossary-* rules (errors) check each operation's summary and description, and the spec's info.title and info.description, against the "Don't use these terms" column of the Zapier content-design glossary. There is one rule per term, for example zapier-glossary-connectors. Each error names the term to use instead and links to the glossary page at the commit the rules were built from. The rules match whole words in any case and cover common word forms, so re-run also catches re-running and re-ran.

A matching term fails the lint run. If the term is right for your API, exempt the operation with x-zapier-glossary-exempt: true:

paths:
  /v1/connectors:
    get:
      x-zapier-glossary-exempt: true
      summary: List connectors

info has no exemption, because its title and description are the spec's headline on docs.zapier.com. To allow a term there, turn that rule off in your own .spectral.yaml:

rules:
  zapier-glossary-connectors: off

Common words the glossary lists, such as "user" and "account", are not checked, because in API descriptions they usually mean something else. See Skipped terms for the list.

Version in Paths Exemption

The zapier-single-major-version-in-paths rule requires all paths to contain a major version (e.g., /v1/). If you need paths without versioning, you can request an exemption.

paths:
  /no-version-but-exempt:
    x-zapier-version-in-paths-exempt: true
    get:
      description: This path is exempt from versioning requirement

Auth Scheme Exemption

The zapier-allowed-auth-schemes rule requires using one of the allowed authentication schemes for new APIs (anonymousServiceJwt, serviceAndUserJwt, or OAuth). If you need to use a different scheme (e.g., legacy userJwt, apiKey, or custom HMAC signatures), you can request an exemption.

components:
  securitySchemes:
    hmacSignature:
      type: apiKey
      in: header
      name: X-Signature
      x-zapier-auth-scheme-exempt: true
      description: Legacy HMAC signature scheme

Required Scopes Exemption

The scope rules enforce the granular scope convention (<resource>[:<subresource>][:<action>], actions read | write | delete | run):

• zapier-required-scopes-present — operations secured by serviceAndUserJwt at the operation level must declare a non-empty x-zapier-required-scopes.
• zapier-required-scopes-present-inherited — the same requirement for operations that inherit serviceAndUserJwt from the root-level security array (OpenAPI security inheritance) without overriding it.
• zapier-scope-name-format / zapier-scope-action-vocabulary — scope names must follow the convention. Checked everywhere a scope name can appear: x-zapier-required-scopes entries, inline security-requirement scopes (operation- and root-level) on the approved schemes, and oauth2 security-scheme flow scope definitions.

OAuth-secured operations are not required to carry x-zapier-required-scopes because the OAuth2 security scheme declares scopes natively — but their scope names are still checked for format/vocabulary. If an operation legitimately cannot declare convention-compliant scopes (e.g. an internal-facing operation in a shared spec, or a legacy off-pattern scope pending rename), add x-zapier-required-scopes-exempt: true to the operation to skip the presence and naming rules for that operation.

Two structural companions are not exemptable, because they flag things that are always mistakes rather than policy choices: zapier-required-scopes-valid (wherever the extension appears on an operation it must be a non-empty array of non-empty strings) and zapier-required-scopes-operation-level (the extension and the exempt flag are only honored on the operation object — declared at the path-item or root level they are silently ignored by tooling, so the rule rejects them there).

paths:
  /v1/legacy/zaps:
    get:
      # The exempt flag alone suppresses the presence and naming rules. The
      # x-zapier-required-scopes below is only shown to illustrate a legacy
      # off-pattern scope being carried through — it is not required for the
      # exemption to take effect.
      x-zapier-required-scopes-exempt: true
      operationId: listZaps
      x-zapier-required-scopes:
        - zap:all

Development

Setup

1. Install dependencies:

pnpm install

2. Run tests:

pnpm test

3. Build the package:

pnpm run build

4. Validate the package:

pnpm run validate

Adding Rules

You can add rules to .spectral.yaml. See the Rules docs for details.

• Provide the correct severity. In 2.x, all rules should be error unless the rule covers something that may be handled upstream (e.g., rate limiting, service unavailability), in which case use info.
• Provide a clear description, as well as a documentationUrl that points to the relevant guide or guide section.
• Provide a message, which in most cases should just be {{error}}.
• Use only Core Functions, not Custom Functions, because Python services copy .spectral.yaml and glossary.spectral.yaml and a custom function does not reach them; a test in src/index.test.ts checks this.
• Include unit test(s) in src/spectral.test.ts for all new rules.

Updating the Glossary Terms

glossary.spectral.yaml is generated from the zinnia-docs glossary. Do not edit it by hand. See scripts/glossary/README.md for how to update it.

Testing

This project uses Vitest for testing. To run the tests:

pnpm test

Publishing

GitLab CI will automatically publish the package to NPM when a merge request is merged into the main branch. Be sure to update the package version in package.json accordingly before merging.