Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/JonathanHerSa/xolo-api-hub/llms.txt

Use this file to discover all available pages before exploring further.

Environments are named collections of key-value variables scoped to a project workspace. They let you maintain separate configuration for development, staging, and production without duplicating requests. A single URL template like {{baseUrl}}/orders/{{orderId}} resolves to a completely different endpoint depending on which environment is active — switch environments in the toolbar and every {{variable}} reference across all requests, headers, and bodies updates instantly.

Creating an Environment

1

Open the Environments screen

From within an active project, tap the layers icon in the workspace app bar, or navigate directly to the Environments screen from the side menu.
2

Open the sidebar

Tap the hamburger menu icon (☰) in the Environments screen app bar to slide out the environment list sidebar.
3

Tap New Environment

Tap + New Environment at the bottom of the sidebar. An alert dialog prompts for a name.
4

Enter a name and create

Type the environment name (e.g. Staging) and tap Create. Xolo calls createEnvironment(name, workspaceId) and the new environment appears in the sidebar list immediately.
When you create a new root-level project (collection), Xolo automatically generates Development, Staging, and Production environments — each pre-seeded with a baseUrl variable — so you can start testing right away without manual setup.

Adding Variables

Select an environment in the sidebar to view its variables in the main panel. Tap + Add Variable to open the variable editor dialog. Each variable has two fields:
FieldDescription
keyThe variable name used inside {{...}} tokens
valueThe resolved string substituted at send time
Saving a variable calls upsertVariable(key, value, environmentId, workspaceId) on XoloRepository. The call is an upsert, so editing an existing variable by the same key updates it in place rather than creating a duplicate.
await repo.upsertVariable(
  key: 'baseUrl',
  value: 'https://staging.api.example.com',
  environmentId: env.id,
  workspaceId: workspaceId,
);
Tap any existing variable row to re-open the editor and change its value. Tap the delete icon (🗑) on a row to call deleteVariable(id) and remove it immediately.
Set {{baseUrl}} as an environment variable so changing servers only requires editing one value. Every request that uses {{baseUrl}}/... in its URL will automatically point to the new server when you save.

Switching Environments

Tap the active environment badge (the coloured chip showing the current environment name) in the composer toolbar. A popup menu lists all environments defined for the active workspace; tap one to switch. Switching environments calls setActiveEnvironment(envId, workspaceId). Because all URL bars, header tables, and body editors consume the resolvedVariablesProvider stream, every {{variable}} in the UI resolves to the new values without any manual refresh. You can also activate an environment directly from the Environments screen by selecting it in the sidebar and tapping the Activate button in the main panel header.

Global Variables

Variables stored without an environmentId are globals — they are available in all environments within the same workspace. In the Environments screen, select Globals (the public/globe icon item) at the top of the sidebar to view and manage workspace-scoped global variables. Global variables use the same upsertVariable call with environmentId: null:
await repo.upsertVariable(
  key: 'apiVersion',
  value: 'v2',
  environmentId: null,  // global — no environment scope
  workspaceId: workspaceId,
);

Variable Resolution Order

When Xolo resolves {{variables}} for a request, globals are loaded first and then environment-specific variables are merged on top. This means environment variables always win over globals with the same key:
// From resolvedVariablesProvider in environment_provider.dart
final globalVars = <String, String>{};
final envVars = <String, String>{};

for (final v in vars) {
  if (v.environmentId == null) {
    globalVars[v.key] = v.value;
  } else {
    envVars[v.key] = v.value;
  }
}

return {...globalVars, ...envVars}; // env overrides globals
The final merged map is passed to VariableParser.parse(input, variables), which performs the token substitution using a single regex pass over the input string.

Dynamic Built-in Variables

VariableParser resolves a set of built-in dynamic variables at send time. These do not need to be defined in any environment — just reference them directly in a URL, header, or body:
VariableResolved value
{{$timestamp}}Current time as Unix milliseconds
{{$guid}}A random UUID v4
{{$randomInt}}A random integer between 0 and 999
{{$isoDate}}Current date in YYYY-MM-DD format
{{$isoDateTime}}Current date-time in ISO 8601 format
{{$randomEmail}}A random email address (user12345@xolo.test)
{{$randomString:N}}A random alphanumeric string of length N (default 8)
{{$randomIntRange:min:max}}A random integer between min and max inclusive

Variable substitution example

Given the following environment variables:
{
  "baseUrl": "https://api.example.com",
  "userId": "42"
}
A request URL template:
{{baseUrl}}/users/{{userId}}
Resolves to:
https://api.example.com/users/42
A header using a dynamic variable:
X-Request-Id: {{$guid}}
Resolves to a fresh UUID on every send, for example:
X-Request-Id: 3f2504e0-4f89-11d3-9a0c-0305e82c3301

Build docs developers (and LLMs) love