> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frontic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

Data Integration is how raw data from any source - Shopware, Shopify, a PIM, a CMS, or a custom API - turns into **clean, typed, semantically meaningful records** your experience can build against.

## What's involved

> [card] [Ingest Data](https://docs.frontic.com/data-integration/ingest.md)
>
> Connectors that pull data from external sources, normalize it, and land
> it in **Data Feeds** ready for the next step.

> [card] [Data Storages](https://docs.frontic.com/data-integration/data-storages.md)
>
> Where your data lives in its **shaped, semantic form**. Each Data Storage
> has a schema and receives records from a feed through a **Data Sync**.

> [card] [Value Composer](https://docs.frontic.com/data-integration/value-composer.md)
>
> The transformation layer inside every Data Sync. Reshape, combine, filter,
> and clean raw feed records into the shape the target Data Storage expects.

## How it all connects

**1. Set up a data source**

Add a [Connector](https://docs.frontic.com/connectors/overview.md) for your commerce system, PIM,
CMS, or any REST endpoint. The Connector carries credentials and tells
Frontic how to connect and stay in sync with the source.

> [!TIP]
>
> Check [Frontic's IP pool](https://docs.frontic.com/connectors/overview.md#ip-pool) to prepare your systems for Frontic access.

**2. Raw data lands in a Feed**

Each Connector provides one or more **Data Feeds** - one per resource
type. A typical e-commerce integration might expose a `products` feed and a
`categories` feed. For built-in connectors, the feed records are already
normalized - keys, translations, currencies, and parent/child
relationships are in place.

**3. A Data Sync transforms and maps**

A Data Sync connects a Feed to a Data Storage. It maps the source's
scopes, regions, and locales onto yours, and uses the
[Value Composer](https://docs.frontic.com/data-integration/value-composer.md) to define how each
target field gets its value.

**4. Clean data arrives in a Data Storage**

The transformed records are stored in a [Data
Storage](https://docs.frontic.com/data-integration/data-storages.md) - your project's semantic layer.
This is where "a product" looks like a product, not like a row in someone
else's database.

Once records are in a Data Storage, the [API Builder](https://docs.frontic.com/api-builder/overview.md) takes over: Detail Blocks, Search Listings, and Page URLs shape that data into the exact API your experience needs.

## Why this matters

Source systems structure data for their own purposes - inventory management, order processing, content editing. That structure carries legacy fields and internal clutter your frontend doesn't need and shouldn't see.

Data Storages flip that perspective. They're structured for the **consumer** - your storefront, your agent, your app - regardless of where the data originally came from. The source's footprint is gone. What remains is a clean data model shaped for the experience you're building.

This separation has real consequences:

* **Swap sources without breaking frontend code.** Your app doesn't know or care whether product content comes from Shopware, Akeneo, Storyblok, or a custom API. Change the source, update the Data Sync, and the frontend never notices.
* **Keep AI agents focused.** A typical source record from a commerce platform can run to thousands of tokens - full of internal metadata, deprecated fields, and noise that invites model drift. A Frontic Data Storage schema for the same product is a fraction of that size, with only the fields that matter.
* **One shape, many surfaces.** Whether a human renders a product card or an AI agent composes a recommendation, they read from the same typed, meaningful structure. And because the data is already clean and well-typed, indexing it for semantic search (coming soon) produces rich embeddings that make LLM-powered discovery work out of the box.

## Combining data from multiple sources

Each Data Storage is connected to exactly one Data Feed through a Data Sync. But most shopping experiences pull data from more than one system - products from Shopware, editorial content from Storyblok, reviews from Reviews.io. There are two ways to bring them together:

* A Data Storage field can reference data from another storage by a shared key. For example, your `Products` storage could pull in feature descriptions from a `ProductFeatures` storage that syncs from Storyblok, while the product itself comes from Shopware. See [mapped fields](https://docs.frontic.com/data-integration/data-storages.md#mapped-fields) for how to set this up.
* Keep each source in its own Data Storage and combine them at query time. Your frontend queries one endpoint and gets the composed result - products with their reviews, editorial content, and whatever else you need - without the storages knowing about each other. See how to [nest blocks and listings](https://docs.frontic.com/api-builder/blocks.md#nested-block) inside a block.

## Where to go next

> [card] [Set up Ingest](https://docs.frontic.com/data-integration/ingest.md)
>
> Connect your first source and land records in a Data Feed.

> [card] [Shape your data](https://docs.frontic.com/data-integration/data-storages.md)
>
> Define a Data Storage schema and wire a Data Sync.

> [card] [Value Composer](https://docs.frontic.com/data-integration/value-composer.md)
>
> How the per-field transformation works - static, mapped, and computed
> values.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.