Variables

Variables in Dynomate allow you to make your requests more flexible, reusable, and environment-aware. Instead of hardcoding values like keys, filters, or table names, you can use variables that can be changed without modifying your underlying requests.

Why Use Variables?

Variables provide several key benefits:

Reusability - Create requests once and reuse them with different values
Environment switching - Easily switch between development, staging, and production environments
Collaboration - Share requests with team members who can provide their own values for variables
Centralized configuration - Update shared values in one place
Dynamic operations - Change table references, user IDs, and other values across multiple operations at once

Dynomate implements variables at multiple levels - global environment variables, collection variables, and request variables - giving you fine-grained control over how values are shared and used across your workflow.

Variable Types

Dynomate supports three types of variables, each with a different scope and purpose:

Global Variables

Available across all collections and requests in Dynomate

Scope: Application-wide

Collection Variables

Available to all requests within a specific collection

Scope: Collection

Request Variables

Available only within a specific request

Scope: Request

Variable Precedence

When the same variable name is defined at multiple levels, the more specific definition takes precedence:

Request Variables > Collection Variables > Global Variables

Global Variables

Global variables are available across your entire Dynomate application, making them ideal for:

Environment settings (dev, staging, prod)
Company-wide constants
Frequently used values across multiple collections
Common user IDs or entity identifiers for testing

Setting Global Variables

Click "Configure Environment Variables" in the dropdown menu
Select or create an environment (e.g., "prod")
Add variables with names and values (e.g., user_id: "user#1")
Click "Save" to apply your changes
Select the environment from the dropdown when running requests

Global Variables Example

{ 
  "environment": "prod",
  "region": "us-west-2",
  "company_id": "company-123",
  "api_version": "v2"
}

Environment Switching

With global environment variables, you can create separate configurations (prod, dev, staging) and quickly switch between them. Your requests will automatically use the values from the selected environment, making it easy to test across different environments without changing your requests.

Collection Variables

As mentioned in the demo, Dynomate also supports collection variables. These are scoped to a specific collection of requests and are useful for:

Project-specific settings that should be shared by all requests in the collection
Values shared across multiple requests in the same collection
Variables that should be version-controlled alongside your collection

The demo explained that collections can be shared with your team, and each collection can have its own set of variables. This makes collections portable and reusable across different environments and team members.

Team Collaboration

Collection variables are especially useful for team collaboration since collections can be committed to Git and shared with your team. Each team member can then adapt the variables to their specific needs without changing the underlying request structure.

Request Variables

Request variables are the most specific type, available only within a single request. They're ideal for:

Request-specific parameters
Temporary values needed for a single operation
Overriding collection or global variables for a specific use case

Setting Request Variables

Open your request in the editor
Click on the "Variables" tab above the request editor
Add or edit your request variables
Click "Save" to apply the changes

Request Variables Example

{ 
  "user_id": "user-789",
  "status": "active",
  "limit": 10,
  "include_deleted": false
}

Using Variables in Requests

Once you've defined your variables, you can use them in your requests with the following syntax:

Variable Syntax

${variable_name}

Example: Query with Variables

Using Variables in a Query

{
  "operation": "query",
  "table": "${user_table}",
  "keyCondition": "status = :status",
  "expressionValues": {
    ":status": "${status}"
  },
  "limit": ${limit}
}

Complex Variable Usage

Variables can be used in most places within a request, including:

Table names
Key values
Filter expressions
Update expressions
Numeric values (like limits or capacities)
Boolean values (like consistent read options)

Combining Variables and Operation References

You can combine variables with operation references to create highly dynamic requests:

Variables with Operation References

// First operation uses variables
{
  "name": "getUserById",
  "operation": "getItem",
  "table": "${user_table}",
  "key": { "userId": "${user_id}" }
}

// Second operation combines variables and references
{
  "name": "getUserOrders",
  "operation": "query",
  "table": "${order_table}",
  "keyCondition": "userId = :userId",
  "expressionValues": {
    ":userId": "${get_user_by_id.item.userId}"
  },
  "limit": ${items_per_page}
}

Best Practices

Use Descriptive Variable Names

Choose clear, descriptive names for your variables that indicate their purpose.

Good

user_table, order_limit, active_status

Bad

table1, lim, st

Choose the Right Scope

Select the appropriate variable type based on how widely the variable will be used:

Use global variables for environment settings and company-wide constants
Use collection variables for project-specific settings
Use request variables for one-off parameters or to override higher-level variables

Document Your Variables

Add comments or descriptions to your variables, especially if they'll be used by other team members.

// User table name - changes between environments
"user_table": "Users-v2",

// Maximum items to return in list views
"items_per_page": 25

Use Environment-Specific Variables

Create separate global variable sets for different environments (development, staging, production) to easily switch contexts.

// Development environment
{ 
  "environment": "dev",
  "user_table": "dev-Users",
  "base_url": "https://dev-api.example.com"
}

// Production environment
{ 
  "environment": "prod",
  "user_table": "prod-Users",
  "base_url": "https://api.example.com"
}

Version Control Your Collections

Since Dynomate stores collections and requests as local files, you can commit them to version control. This allows you to:

Track changes to your requests over time
Share standardized requests with your team
Allow each team member to use their own variables while sharing the same request structure