Collections and cloud sync

Group related requests into collections, set shared base URLs and auth once, import from OpenAPI, and sync everything across your devices.

Updated

A collection is a folder of saved requests that share configuration. Once an endpoint works, saving it means you never rebuild the headers by hand again.

Group by service, not by ticket

The organising principle that survives contact with a real project is one collection per API, with folders inside it per resource:

Billing API
├── Customers
│   ├── List customers
│   ├── Create customer
│   └── Cancel subscription
└── Invoices
    ├── List invoices
    └── Void invoice

Collections named after tickets rot within a sprint. Collections named after services stay useful for years.

Set the base URL once

Put the base URL and authentication on the collection rather than on each request. Then switching between staging and production is one edit instead of thirty, and a rotated token is updated in a single place.

Import from OpenAPI

If the API publishes an OpenAPI 3.x document, import it. You get the requests and the response schemas in one step, which is considerably faster than clicking through documentation.

Sync and share

Sign in and collections sync across your machines. Team workspaces extend that to other people, with roles controlling who can edit. Everything stays free — there is no seat pricing to run into.

If you have not saved anything yet, start with how to test a REST API and save the request at the end of it.

Frequently asked questions

Do collections work without signing in?

Yes. Collections are stored on your machine and work fully offline. Signing in adds cloud sync across devices and sharing with a team workspace.

Can I import an existing Postman collection or OpenAPI spec?

OpenAPI 3.x import is supported and generates both the requests and their response schemas. That is usually the cleaner path, since an OpenAPI document describes the contract rather than one person's saved requests.