> For the complete documentation index, see [llms.txt](https://help.modelreef.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.modelreef.io/help/importing-from-google-finance-and-yahoo-apis/mapping-api-data-into-variables.md).

# Mapping API Data Into Variables

This article explains how to turn raw series imported from Google Finance, Yahoo style or similar APIs into usable **variables** and **drivers** inside a Model Reef model.

You will learn:

* How API series are stored in the Data Library.
* How to reference them in variables and formulas.
* Patterns for using them as drivers instead of direct P\&L lines.

***

## How API data is stored

When you import data from Google Finance or a similar API:

* Each requested symbol and field becomes a **Data Library entry**.
* The entry contains a time series of values with dates and selected frequency (daily, weekly, monthly).
* Metadata or tags indicate that the source is an API based feed.

These entries are conceptually similar to imported CSV series or Xero sourced series, but they are typically used as **drivers** rather than as accounting lines.

***

## Mapping API series to drivers

A common pattern is to treat API series as **drivers or modifier drivers**, for example:

* FX rate series used to translate foreign currency revenue or costs into the model currency.
* Commodity price series used as input into pricing, margin or cost formulas.
* Index levels used as macro drivers for regression based forecasts.

To implement this pattern, follow these steps:

{% stepper %}
{% step %}

### Keep the API series as a driver entry

1. Import the symbol/field into the Data Library.
2. Mark the Data Library entry with type "Driver" or "Modifier".
   {% endstep %}

{% step %}

### Reference the series in formulas

Use the driver in variable formulas. Examples:

* `Revenue = Units * Price * FXRate`
* `Cost = BaseCost * CommodityIndex`
  {% endstep %}

{% step %}

### Use drivers, not accounting lines

Keep the API series as drivers so they do not appear directly as P\&L or Balance Sheet lines; instead let variables and formulas generate the accounting impact.
{% endstep %}
{% endstepper %}

***

## Creating variables that reference API series

You can create explicit **variables** whose behaviour depends on API data. Examples:

* A variable representing "FX Adjustment" as a function of an FX rate series.
* A variable representing "Market Linked Fee Income" based on an index level.
* A variable representing "Performance Fee" based on fund returns vs a benchmark.

To create such variables, follow these steps:

{% stepper %}
{% step %}

### Create the variable

1. Create a new variable with the appropriate type and category.
2. Choose a meaningful name (e.g., "FX Adjustment", "Market Linked Fee Income").
   {% endstep %}

{% step %}

### Define the formula

1. Reference one or more API-backed Data Library entries in the variable formula.
2. Use expressions such as multipliers, thresholds, or regressions based on the driver(s).
   {% endstep %}

{% step %}

### Configure timing and recognition

1. Configure timing and delays if there is a difference between accrual and cash recognition.
2. Ensure the variable's type/category will route amounts to P\&L, Balance Sheet and Cashflow as intended.
   {% endstep %}
   {% endstepper %}

The variable will then contribute to P\&L, Balance Sheet and Cashflow in line with its type.

***

## Choosing types and categories

Because API series are external drivers, you will usually map dependent variables as:

* **Revenue** or **COGS** when the driver affects sales or direct costs.
* **Opex** or **Staff** when the driver affects operating expenses.
* **Asset** or **Liability** when the driver affects mark to market values or indexed obligations.
* **Modifier** only when the variable is intended to stay as a pure driver with no direct statement impact.

The key is to separate:

* The **driver** itself (API series in the Data Library).
* The **economic effect** (variables typed and categorised to reflect accounting impact).

***

## Examples

Some concrete examples:

* Import `GBPUSD` FX rates and create:
  * A driver `GBPUSD Rate`.
  * Revenue variables that multiply foreign currency sales by `GBPUSD Rate` to express them in model currency.
* Import a commodity index and create:
  * A driver `Input Commodity Index`.
  * COGS variables that scale with this index over time.
* Import an equity index and create:
  * A driver `Market Index`.
  * Performance fee variables that depend on whether a fund's return exceeds this index.

***

## Related articles

* [Hospitality (Restaurants, Cafés, Bars)](/use-cases/hospitality-restaurants-cafes-bars.md)
* [Build a Pricing Model](/how-tos/operations-and-unit-economics/build-a-pricing-model.md)
* [Dividend Variables: what is, rules, what it affects](/help/drivers-variables-and-timing/dividend-variables.md)
* [Overriding Variables](/syntax/scenario-syntax/overriding-variables.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.modelreef.io/help/importing-from-google-finance-and-yahoo-apis/mapping-api-data-into-variables.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.