> ## 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

<CardGroup cols={1}>
  <Card title="Ingest Data" icon="gears" href="/data-integration/ingest" horizontal>
    Connectors that pull data from external sources, normalize it, and land
    it in **Data Feeds** ready for the next step.
  </Card>

  <Card title="Data Storages" icon="database" href="/data-integration/data-storages" horizontal>
    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>

  <Card title="Value Composer" icon="wand-magic-sparkles" href="/data-integration/value-composer" horizontal>
    The transformation layer inside every Data Sync. Reshape, combine, filter,
    and clean raw feed records into the shape the target Data Storage expects.
  </Card>
</CardGroup>

## How it all connects

<Steps>
  <Step title="Set up a data source" icon="plug">
    Add a [Connector](/connectors/overview) 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](/connectors/overview#ip-pool) to prepare your systems for Frontic access.</Tip>
  </Step>

  <Step title="Raw data lands in a Feed" icon="inbox">
    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.
  </Step>

  <Step title="A Data Sync transforms and maps" icon="arrows-rotate">
    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](/data-integration/value-composer) to define how each
    target field gets its value.
  </Step>

  <Step title="Clean data arrives in a Data Storage" icon="database">
    The transformed records are stored in a [Data
    Storage](/data-integration/data-storages) — your project's semantic layer.
    This is where "a product" looks like a product, not like a row in someone
    else's database.
  </Step>
</Steps>

Once records are in a Data Storage, the [API Builder](/api-builder/overview) 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](/data-integration/data-storages#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](/api-builder/blocks#nested-block) inside a block.

## Where to go next

<CardGroup cols={3}>
  <Card title="Set up Ingest" icon="plug" href="/data-integration/ingest">
    Connect your first source and land records in a Data Feed.
  </Card>

  <Card title="Shape your data" icon="database" href="/data-integration/data-storages">
    Define a Data Storage schema and wire a Data Sync.
  </Card>

  <Card title="Value Composer" icon="wand-magic-sparkles" href="/data-integration/value-composer">
    How the per-field transformation works — static, mapped, and computed
    values.
  </Card>
</CardGroup>