How to Use Environment Variables in TullyAPI
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.
- Click the "+ Add Environment" button
- Give your environment a name (e.g., "Development", "Production", "Staging")
- 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_TOKENAUTH_USERNAMEAUTH_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.