> ## Documentation Index > Fetch the complete documentation index at: https://docs.apinizer.com/llms.txt > Use this file to discover all available pages before exploring further. # Variables > Variables are used for information transfer such as getting values from and sending values to headers, parameters, or body of messages. Definitions are made for project-based use. The Apinizer Platform comes with ready-made variables with the initial installation, and when a new project is created, the variables under the Management menu are copied to the relevant project. All variables can be moved to the Admin page with the 'Globalize' option to make them available for use in all projects. ## Variable Types 5 different types of variables are created in Apinizer: Used to get values from HTTP headers Used to get values from URL parameters Used to get values from message body Used to get values from system properties Used to transfer data between policies The Apinizer Platform comes with ready-made variables with the initial installation. When a new project is created, all variables in the variables section under the **Management** menu are copied to the relevant project. Since variables created under the Management menu are used by copying them to projects, update or delete operations on these variables do not affect the definitions in the projects where they are used. All variables can be moved to the Admin page with the "Globalize" option to make them available for use in all projects and management is left to the Admin user. ## Creating Header Type Variable To create this type of variable, **Header** is selected as the **type** and the relevant input fields are filled. Variable name and header name can be defined differently. The name is a unique definition system-wide. Header name is the value expected from the client. | Field | Description | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** | Field where the name of the variable definition is entered. | | **Description** | Description can be written to facilitate management related to the created variable. | | **Type** | Field where which part of the message the variable is expected is entered. | | **Header Name** | Field where the header name expected in the request from the client is entered. If this field contains multiple values, the first value is used. | Header variables are used to extract data from HTTP headers. For example, values can be retrieved from headers such as `X-API-Key`, `Authorization`, `Content-Type`. ## Creating Parameter Type Variable To create this type of variable, **Parameter** is selected as the **type** and the relevant input fields are filled. Variable name and parameter name can be defined differently. The name is a unique definition system-wide. Parameter name is the value expected from the client. | Field | Description | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Field where the name of the variable definition is entered. | | **Description** | Description can be written to facilitate management related to the created variable. | | **Type** | Field where which part of the message the variable is expected is entered. | | **Parameter Type** | Field where the request type of the parameter from the client is selected. Default value is QUERY. Values that can be read as form parameter values are **x-www-form** values and **attached text data part** values. In x-www-form values, addition, deletion, and editing can be done; the text data part is read-only, addition/editing cannot be done. Reading can be done from anywhere. Adding/deleting/editing values is only valid for the request (request) line. | | **Parameter Name** | Field where the parameter name expected in the request from the client is entered. If the Parameter Type value is Query and it is a multiple value, the first value is used. | Parameter variables are used to extract data from URL query parameters, path parameters, or form parameters. For example, values can be retrieved from query parameters like `?page=1&limit=10` or path parameters like `/users/{id}`. ## Creating Body Type Variable To create this type of variable, **Body** is selected as the **type** and the relevant input fields are filled. | Field | Description | | ----------------- | ---------------------------------------------------------------------------------------------------------- | | **Name** | Field where the name of the variable definition is entered. | | **Description** | Description can be written to facilitate management related to the created variable. | | **Type** | Field where which part of the message the variable is expected is entered. | | **Message Type** | Field where the type of message content is selected. Default value is JSON. | | **JSON/XML Path** | Field where JSON/XPath information necessary to get the value from the request from the client is entered. | There are some differences in how XPath works. It is recommended to refer to the relevant documentation page for detailed information on this topic. Body variables are used to extract data from message body. JSONPath is used for JSON format, XPath is used for XML format. For example, a username can be extracted from JSON content with a JSONPath expression like `$.user.name`. ## Creating Context Values Type Variable To create this type of variable, **Context Values** is selected as the **type** and the relevant input fields are filled. | Field | Description | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Field where the name of the variable definition is entered. | | **Description** | Description can be written to facilitate management related to the created variable. | | **Type** | Field where which part of the message the variable is expected is entered. | | **Value** | Field where the predefined value expected in the request from the client is selected. Only Http Info and Backend Endpoint from these values can be edited; other values are read-only. | | **Zone ID** | This field becomes active if any value from the Date/Time group is selected as the value. Example value: "+03:00" or "Europe/Istanbul". For more information, you can refer to the [Java ZoneId documentation](https://docs.oracle.com/javase/8/docs/api/java/time/ZoneId.html#of-java.lang.String-). | Request information selectable in the form: * Client IP address * HTTP method * Content type * Path information * Query string * Request URI * Remote user information * Server information (name, port, etc.) Date/time values require time zone (zoneId): * Epoch milliseconds * Formatted date-time * Formatted date * Formatted time * Year, month, day, hour, minute, second information * Environment ID and name * API Proxy Group ID and name * API Proxy ID and name * API Method information * Message correlation ID * Content length * Response status code * Compression information Context values are used to extract data from system properties and request context. These values are selected from a dropdown menu in form-based configuration and displayed with user-friendly labels. ## Creating Custom Variable Type Variable To create this type of variable, **Custom Variable** is selected as the **type** and only the name field is filled. Afterwards, it becomes possible to assign values, read values, and change values from Script and Business Rule policies with the entered name of this variable. It is mostly used for transferring data from one policy to another. | Field | Description | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Field where the name of the variable definition is entered. | | **Description** | Description can be written to facilitate management related to the created variable. | | **Type** | Field where which part of the message the variable is expected is entered. | | **Initialized with Script** | Field used to determine the initial value of the Custom Variable. This field only works if the variable **has never been created** or is **null**. To give an initial value, the variable name added to the customVariableMap object with the name used here must be exactly the same. For example, if the variable name is "test", the expression should be written as `customVariableMap.put("test",value)` in the last line of the script. | | **Script Language** | Field where Script Language is selected. | | **Script Body** | Field where script content is entered. | **Custom Variable** is especially used for transferring data between pipelines. Data can be added, read, and changed to Custom Variable during flow with Script and [Business Rule](/en/develop/policies/business-rule) policies. This enables data transfer from one policy to another. When adding Business Rule action types, variable type selection and new variable creation screens have been improved for a clearer user experience. The first value is always taken on the variables screen, even if the header (header) and parameter (parameter) values come as multiple (multiple). Only in script policy, if there is a multiple (multiple) value, it can be used separated by #. When showing in log records, it is shown as **key: val1#val2#val3**. ## Runtime Context Variable Support (#{}) In policies that make HTTP calls and in routing addresses, context variable usage is supported. Placeholders in the `#{variable_name}` format are replaced on each request with values from the request context (custom variable map). ### Supported Fields * **HTTP URL** – e.g. `https://api.example.com/users/#{userId}` * **Header name and value** – e.g. `Authorization: Bearer #{token}` * **Query parameters** – e.g. `?sessionId=#{sessionId}` * **Form parameters** (URL-encoded body) * **Request body content** * **Routing address** – `#{...}` can be used at runtime in the backend address * **JSON Error Response Template and XML Error Response Template** – `#{variableName}` can be used. For error details: `#{error.customizedErrorCode}`, `#{error.customizedHttpCode}`, `#{error.customizedMessage}`, `#{error.defaultErrorCode}`, `#{error.defaultMessage}`, `#{error.defaultHttpCode}` ### Variable Type Comparison | Format | Description | Resolution Time | | -------- | -------------------- | --------------------------------- | | `${key}` | Environment variable | At deploy time (current behavior) | | `#{key}` | Context variable | On each request (new) | * **Environment variable:** Fixed for the environment; resolved at deploy time. * **Context variable:** Per request; read from the custom variable map (can be set by Script policy, data manipulation, etc.). ### Affected Policies and Fields * REST API Policy * JOSE Validation Policy (dynamic key HTTP request) * JOSE Implementation Policy (dynamic key HTTP request) * Authentication API Policy * OIDC Policy (token endpoint, introspection endpoint, resource endpoint, form parameters) * Routing addresses (backend address) * JSON Error Response Template and XML Error Response Template * Identity Providers: Database Provider, LDAP Provider, API Provider ### Behavior * Missing `#{key}` values are replaced with empty string ""; no exception is thrown, a warning-level log is written to the application log. * In Script policy, the custom variable map is already accessed directly, so this placeholder mechanism is not used there. * Existing variable-based substitution and data manipulation logic is unchanged; this works as an additional layer on top. ### Example Usage * **REST API URL:** `https://${baseHost}/api/v1/users/#{userId}` — `${baseHost}` is resolved at deploy time, `#{userId}` on each request. * **JOSE dynamic key endpoint:** `https://auth.example.com/keys/#{keyId}` * **Routing address:** `https://#{tenant}.backend.example.com` — tenant can change per request. This feature currently applies only in the HTTP context. ## Variable Management Variables are defined at the project level and can be used in all API Proxies in the relevant project. Variables created under the Management menu are automatically copied to the project when a new project is created. All variables can be moved to the Admin page with the "Globalize" option to make them available for use in all projects. Updating or deleting variables in the Management menu does not affect the definitions in the projects where they are copied. ## Variable Usage Scenarios Variables are used in the following situations: Used for dynamic values in policy settings. Client definition for policies such as Rate Limiting, Throttling, API Key. Used to make policy execution decisions based on variable values. Used to route to different backends based on variable values. Used for dynamic values in message transformation operations. Variable usage in Groovy/JavaScript scripts and adding, reading, and changing data to Custom Variables. Data transfer between pipelines with Custom Variable. Data transfer from Request Pipeline to Response Pipeline, from one policy to another. ## Next Steps Learn about environment variables Learn about the Policy concept Learn about conditional policy execution Variable usage in Script policy Variable definition API reference