Skip to content

OpenAPI Import

Turn an OpenAPI spec into runnable YAML files.

Turn an OpenAPI or Swagger spec into curl-runner YAML with one command or in the studio. One file per operation, a .env, and auth credentials stay out of files.

Read the docsInstall curl-runner

Screenshots

  1. The Import dialog on the OpenAPI tab with pets.yaml picked: 6 requests in 3 folders. Two items need attention, a file to pick for the file field of Upload photo and the secret PETS_API_KEY to set. The preview lists the six request files in pets, store and users.
    Preview a spec before you importPick an OpenAPI or Swagger file. The preview lists one file per operation and what needs your attention, before anything is written.
  2. The Import dialog after an OpenAPI import: Imported 6 requests, and the base URL and secrets are in .env. Needs your attention lists a file to pick for Upload photo, with an Open link, and the secret PETS_API_KEY to set.
    Finish what the import leftThe summary lists what still needs you. Open goes straight to the request with a file to pick.

Plain YAML underneath

Each operation becomes a file like this one. The CLI, CI and the studio run it as it is.

pets/list-pets.yaml
# Imported from OpenAPI: Pets
# operationId: listPets
# Everything about pets.

request:
  name: List pets
  method: GET
  url: ${PETS_BASE_URL}/pets
  headers:
    X-API-Key: ${PETS_API_KEY}
  params:
    # # How many pets to return.
    # limit: "1"
  expect:
    status: 200

Benefits

  • One file per operation

    Each tag becomes a folder and each operation its own YAML file, with sample values taken from the spec.

  • A smoke test from the start

    Each request checks the lowest documented 2xx status, so the folder works as a smoke test before you change anything.

  • Secrets stay out of files

    Secrets are listed by name in .env and set in .env.local. Set them in Environments in the studio and they go to the macOS Keychain. A short list shows what still needs your attention.

Good for

  1. Smoke-testing an API from its spec
  2. Starting a test suite for an API you did not write
  3. Keeping API requests in your repo, next to the code
  4. Regenerating into a fresh folder when the spec changes