TullyAPI

Fast, simple API testing tool. Now with environment variables and GraphQL!

Now with more bug fixes.

Back to App

How to Use Environment Variables in TullyAPI

• 6 min read

Testing the same API across development, staging, and production environments can be tedious—constantly changing URLs, API keys, and configuration values. Environment variables solve this problem by letting you define reusable values that automatically adapt to your current context. In this guide, you'll learn what environment variables are and how to leverage them in TullyAPI to streamline your API testing workflow.

What Are Environment Variables?

Environment variables are named values that represent configuration data for different environments. Instead of hardcoding values like API endpoints or authentication tokens directly into your requests, you create variables that can be referenced anywhere in your API tests.

For example, instead of typing https://api.production.com in every request, you create a variable called BASE_URL and reference it as {{BASE_URL}}. When you switch from your Production environment to Development, that same {{BASE_URL}} automatically becomes http://localhost:3000—no manual editing required.

Real-World Analogy

Think of environment variables like contact shortcuts in your phone. Instead of memorizing and typing your colleague's phone number every time, you save it once as "John - Work" and tap their name to call. When John gets a new number, you update it in one place, and all your messages and calls automatically use the new number.

Environment variables work the same way: define a value once, use it everywhere, and update it in a single location when it changes.

Common Use Cases

  • Multiple Environments: Maintain separate configurations for Development, Staging, and Production
  • API Keys & Tokens: Store authentication credentials that differ between environments
  • Base URLs: Switch between local (localhost:3000), staging, and production servers
  • User IDs & Test Data: Reference different test users or data sets per environment
  • API Versions: Test different API versions (v1, v2, v3) without rewriting requests

Why Use Environment Variables?

1. Avoid Hardcoding Sensitive Data

Hardcoding API keys, tokens, or passwords directly into your requests is risky. If you share your collection or accidentally commit it to version control, those secrets are exposed. Environment variables keep sensitive data separate from your request definitions.

2. Easy Environment Switching

With a single click, switch from testing against your local development server to production. All your requests automatically update to use the correct URLs, credentials, and configuration—no manual find-and-replace needed.

3. Reuse Requests Across Environments

Write your API tests once, and run them anywhere. The same request works in development, staging, and production because the environment variables adapt to your current context.

4. Team Collaboration

When working with a team, everyone can use the same request collections but with their own environment configurations. A junior developer can test against a sandbox environment while senior developers work with production, using the exact same requests.

How to Use Environment Variables in TullyAPI

Step 1: Creating Your First Environment

In TullyAPI, you'll see an Environment dropdown in the header. Click the gear icon (⚙️) next to it to open the Environment Manager.

  1. Click the "+ Add Environment" button
  2. Give your environment a name (e.g., "Development", "Production", "Staging")
  3. Click "Save Environment"

Step 2: Adding Variables

Once you've created an environment, click the Edit button to add variables:

Example Variables for Development Environment:

Key: BASE_URL
Value: http://localhost:3000

Key: API_KEY
Value: dev_key_12345

Key: USER_ID
Value: test-user-001

Example Variables for Production Environment:

Key: BASE_URL
Value: https://api.example.com

Key: API_KEY
Value: prod_key_67890

Key: USER_ID
Value: real-user-456

Click the "+ Add Variable" button to add more variables, and use the Remove button to delete any you don't need.

Step 3: Using Variables in Requests

Reference your variables using the {{VARIABLE_NAME}} syntax. TullyAPI will automatically replace these placeholders with the actual values from your active environment.

Base URL:
{{BASE_URL}}/api/users

Headers:
Authorization: Bearer {{API_KEY}}

Request Body:
{
  "userId": "{{USER_ID}}",
  "action": "login"
}

Query Parameters:
?apiKey={{API_KEY}}&userId={{USER_ID}}

You can use variables in:

  • Base URLs and endpoint paths
  • Query parameter keys and values
  • Header keys and values
  • Authentication fields (Bearer tokens, API keys, Basic Auth credentials)
  • Request body content (JSON, GraphQL, or plain text)

Step 4: Switching Between Environments

Use the Environment dropdown in the header to switch between your environments. When you select an environment, all variables in your requests will automatically update to use that environment's values.

If you select "No Environment", variables remain as literal text ({{BASE_URL}} stays as {{BASE_URL}}). This is useful when you want to see exactly what variables are being used, or when you need to temporarily disable interpolation.

Practical Example

Let's walk through a real-world scenario: testing a user login endpoint across development and production environments.

Setup

Create two environments with these variables:

Development Environment:
BASE_URL: http://localhost:3000
AUTH_TOKEN: dev-token-abc123
TEST_EMAIL: [email protected]

Production Environment:
BASE_URL: https://api.myapp.com
AUTH_TOKEN: prod-token-xyz789
TEST_EMAIL: [email protected]

Create Your Request

Method: POST
URL: {{BASE_URL}}/auth/login

Headers:
Content-Type: application/json
Authorization: Bearer {{AUTH_TOKEN}}

Body:
{
  "email": "{{TEST_EMAIL}}",
  "password": "test123"
}

Test Across Environments

With "Development" selected: Your request goes to http://localhost:3000/auth/login with [email protected] and the development token.

Switch to "Production": The exact same request now goes to https://api.myapp.com/auth/login with [email protected] and the production token.

No editing required—just select the environment and send.

Tips & Best Practices

1. Use UPPER_CASE Naming Convention

Name your variables in UPPER_CASE with underscores (e.g., BASE_URL, API_KEY, USER_ID). This makes them easy to spot in your requests and follows common environment variable conventions.

2. Organize by Purpose

Group related variables together. For example, all authentication-related variables might start with AUTH_:

  • AUTH_TOKEN
  • AUTH_USERNAME
  • AUTH_PASSWORD

3. Be Careful with Production Credentials

While TullyAPI stores all data locally in your browser, be cautious about storing production passwords, master API keys, or other highly sensitive credentials. Consider using read-only or limited-scope tokens for testing, and never commit production secrets to version control if you export your collections.

4. Use "No Environment" for Debugging

If your request isn't working as expected, switch to "No Environment" to see the raw variable syntax. This helps you identify typos or undefined variables.

5. Duplicate Environments for Quick Setup

TullyAPI lets you duplicate environments. If you need to create a "Staging" environment similar to "Production" with a few different values, duplicate the Production environment and modify only what's changed. This saves time and reduces errors.

Exporting & Importing Environments

When you export your collections from TullyAPI, your environments are included in the export file (format v2.0). This means you can:

  • Back up your entire configuration (collections + environments)
  • Share collections with team members (be mindful of sensitive values)
  • Transfer your setup to a different browser or computer
  • Version control your API test configurations

When importing, TullyAPI automatically detects the format version and correctly restores both collections and environments.

What Happens If a Variable Isn't Defined?

If you reference a variable that doesn't exist in the active environment (e.g., {{UNDEFINED_VAR}}), TullyAPI will:

  • Leave the variable as literal text in the request
  • Log a warning to the browser console

This prevents accidental requests with broken URLs or missing credentials. Always check the console if your requests aren't working as expected.

Try Environment Variables in TullyAPI

Start using environment variables to streamline your API testing workflow. Completely free, no sign-up required, and all data stays private in your browser.

Launch TullyAPI →

Key Takeaways

  • Environment variables let you define reusable values that adapt to your current context
  • Switch environments with a single click to test the same requests across dev, staging, and production
  • Use {{VARIABLE}} syntax anywhere in your requests: URLs, headers, auth fields, and request bodies
  • Organize variables using UPPER_CASE naming and logical grouping
  • Be cautious with production credentials—use limited-scope tokens when possible
  • Export and import environments along with collections for backup and sharing

Conclusion

Environment variables are a game-changer for API testing. They eliminate repetitive manual edits, reduce errors, and make it effortless to test across multiple environments. Whether you're a solo developer juggling local and production setups or part of a team with complex deployment pipelines, environment variables will save you time and headaches.

Ready to supercharge your API testing workflow? Open TullyAPI, create your first environment, and experience the difference variables make. And if you're working with GraphQL APIs, check out our guide on What is GraphQL? to learn how TullyAPI's native GraphQL support works hand-in-hand with environment variables.