English for Bruno API Client

Switching an API testing workflow from a cloud-synced tool to a git-friendly one changes how a team actually talks about sharing requests, and this vocabulary covers the specific terms that make that conversation precise.

Key Vocabulary

Collection — a folder of related API requests stored as plain files on disk, the top-level organizational unit in Bruno, structured so it can be committed to a git repository alongside the codebase it’s testing. “Don’t keep these requests in your personal workspace — put them in the shared collection in the repo, so everyone on the team has the same set of requests and they stay in sync with the API.”

.bru file — the plain-text file format Bruno uses to store each request, human-readable and diff-friendly, in contrast to a JSON blob that’s harder to review meaningfully in a pull request. “You can actually review this API request change in the pull request now — it’s a small, readable diff in the .bru file, not an opaque JSON export like our old tool produced.”

Environment — a named set of variables, like a base URL or API key, that can be swapped without editing the requests themselves, letting the same collection run against staging, production, or a local instance. “Don’t hardcode the staging URL into every request — define it as a variable in the staging environment instead, so switching to production is one dropdown change, not editing every request.”

Runner — Bruno’s feature for executing a whole collection or folder of requests sequentially, often used for basic API smoke testing or workflows where one request depends on data returned by a previous one. “We’re using the runner to chain the login request into the requests that depend on its token — running them one at a time manually was error-prone and slow.”

Pre-request script — JavaScript code attached to a request that runs before it’s sent, commonly used to generate a timestamp, sign a request, or set a variable dynamically based on a previous response. “That signature keeps failing because it’s stale — we need a pre-request script to regenerate it fresh before each send, instead of relying on a value that was hardcoded once and never updated.”

Common Phrases

• “Is this request in the shared collection, or still just in your local workspace?”
• “Can we actually review this .bru file diff, or is it still exported as opaque JSON?”
• “Which environment is this request pointed at right now?”
• “Should we chain these with the runner, or are they independent enough to run separately?”
• “Does this need a pre-request script, or is the value static enough to hardcode?”

Example Sentences

Proposing a tooling switch: “I’d like to move our API requests from the old tool to Bruno. The collection lives as plain .bru files in the repo, so request changes go through code review like everything else, instead of syncing silently through a cloud account nobody else can see.”

Explaining an environment mix-up: “That request hit production by accident because the environment dropdown was still set to production from testing something else earlier — we should default new team members’ setup to the staging environment to avoid this.”

Describing a chained test setup: “We’re using the runner to execute the login request first, then the three requests that need its auth token, in sequence — running them out of order, or independently, would just fail with an authentication error.”

Professional Tips

• Keep the collection in the same repository as the code it tests, not in a separate personal workspace — it keeps requests versioned, reviewable, and in sync with actual API changes.
• Review a .bru file diff in pull requests the same way you’d review code — its plain-text format exists specifically to make request changes legible in a code review, not just importable.
• Use a named environment for every base URL or credential instead of hardcoding values into individual requests — it’s what makes switching between staging and production a safe, deliberate action instead of a manual edit.
• Reach for the runner when requests have a real dependency order, like an auth token from one request being needed by the next — for independent requests, running them individually is often clearer.
• Use a pre-request script for values that need to be generated fresh per request, like timestamps or signatures — hardcoding a value that’s supposed to be dynamic is a common source of intermittent request failures.

Practice Exercise

1. Explain why storing API requests as .bru files in a repo is different from a cloud-synced tool.
2. Describe what an environment is used for in Bruno.
3. Write a sentence explaining when a pre-request script would be necessary.