Organizing API Requests with Collections

Every request you send in AlleForge is saved automatically to your History — searchable, but unstructured. A Collection is the deliberate version of that: a named folder that holds only the requests that belong together, so a project doesn't get lost in months of one-off calls.

What a Collection actually holds

A Collection is a folder of requests you've chosen to keep — nothing more automatic than that. If you're testing one API, its collection typically ends up holding the requests you send against it regularly: the ones you'd otherwise re-type or dig out of History every time you needed them again.

Collections are shareable. Inside a workspace, anyone with access can open a collection, see the same requests, and send them — the same underlying mechanism that makes real-time collaboration on /collaboration possible, applied to the requests themselves rather than just live editing.

Collections vs. History

These solve two different problems:

You don't have to choose between them — History keeps everything by default; Collections are what you build deliberately on top of it.

Bringing in existing collections

If you already have requests organized somewhere else, you don't have to rebuild them by hand. AlleForge can import a Postman export, an Insomnia workspace, or an OpenAPI/Swagger spec, and rebuilds the folders, requests, and variables from it automatically.

Where Environments fit in

A collection's requests are usually written once and reused against more than one place — your local machine, staging, production. That's what Environments are for: the collection stays the same, and an environment swap changes which base URL and variables it points at.

Roles and permissions

Because a collection lives inside a workspace, who can edit or just view it follows the same Workspace roles as everything else in that workspace — Owner, Admin, Editor, or Viewer.