> ## 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 A **connector** is a piece of Frontic that knows how to talk to a specific source system - be it Shopware, Shopify, commercetools, some other system or even a CSV file drop. The connector handles the source's quirks for you - splitting inline variants, resolving translations, normalizing prices - so the records that land on your Data Feeds are already shaped for Frontic. You use a connector to set up an **integration**: a configured, credentialed link in your Frontic project that pulls data in (or accepts data pushed at it). This page covers how integrations work end-to-end. For vendor-specific setup, click into a connector below. ## What's in an integration > [card] Connection > > Auth and host for one source system. Valid options come from the source itself. > [card] Channels > > Translations the channel covers, plus connector-specific source segmentation where applicable. > [card] Data Feeds > > One feed per resource type, each with assigned channels and an update method. ## How data flows from source to project **1. Source** Your Shopware store, Shopify shop, CSV file drop, ERP - whatever's authoritative for the data. **2. Integration** The connector's link to that source. Auth, host, channel config - everything that decides *what* to pull and *from where*. **3. Data Feeds** Live records inside Frontic, one feed per resource type. The connector keeps these in sync with the source via the feed's update methods. **4. Data Syncs** The mapping layer that decides how feed records become storage records - including which channel powers which project scope, which channel locale fills which project locale, and how the [Value Composer](https://docs.frontic.com/data-integration/value-composer.md) reshapes each field. **5. Data Storages** The semantically structured records your blocks, listings, and pages query at runtime. The integration owns "what comes from the source" - the project's scopes, regions, and locales are independent. The Data Sync's mappings are where the two models meet. ## Connection Every integration carries one set of credentials to talk to one source system. Connection settings sit at the integration level - host URL, API keys, OAuth tokens, SFTP credentials, whatever the source needs. Frontic stores secrets encrypted and redacts them in logs. Once connected, the connector pulls **reference data** from the source - typically the list of valid sales channels, currencies, and languages - and uses it to populate dropdowns when you configure channels or feeds. A **Refresh** action is available wherever reference data is shown, in case you've added a sales channel or locale on the source side and want Frontic to pick it up without recreating the integration. ### IP Pool Depending on your integration, Frontic will need to connect to your systems for fetching data. We will use this IP pool for connections: * `195.201.46.231` * `78.47.233.107` If your system only lets known addresses in - a firewall, an IP allowlist, or a shop in maintenance mode - add both. ## Channels Every channel carries fields that describe which translations it covers: * **Channel name** - your label. * **Available translations** - the locales this channel covers. * **Fallback translation** - used when a translation is missing on a record. On top of those, a connector can declare additional **typed system fields** on its channels - name, type, required flag, and a reference to a validated set of possible values pulled from the source. These aren't free-form metadata: the framework enforces them just like the framework-level fields, and the dropdowns are populated from the source. * **Shopware** adds **Sales Channel** (validated against the live list of Shopware sales channels) and **Currencies** (validated against the sales channel's currencies). * **commercetools**, **Akeneo**, and **WEBSALE** each add **Currencies**, validated against the source's enabled currency set. * Other integrations may not declare any additional channel fields today - their channels carry only the basic fields, and any source-side segmentation lives at the connection or feed level instead. The same Frontic project can host as many channels as you have segmentations to pull from. ## Data Feeds A Data Feed is a sync source for one resource type. The connector declares which feed types it supports - Shopware for example exposes Products, Categories, CMS Pages and Manufacturers; Reviews.io exposes Product Reviews and Company Reviews; the File Importer simply exposes Content. You'll see only the feed types relevant to the connector you picked. Each feed fetches data from all your channels - a Shopware Products feed, for instance, runs against every channel you've assigned it to, pulling the catalog for each (sales channel × currencies × translations) combination. ### The setup wizard Adding a feed walks through three steps, with a **Finish** indicator on the progress bar marking the completion state: **1. Settings** Name the feed and pick its resource type from the connector's available types. **2. Updates** Configure the update methods this feed uses to stay in sync (see below). Only the methods the connector supports are offered. **3. Schema** Optionally pre-declare the feed's fields. Leave it empty if you'd rather let the schema fill in automatically as records arrive - every incoming record extends the feed's schema with any new fields it carries. Each feed has a **Refresh** action that re-runs it against the source - useful when something changed on the source side that didn't reach Frontic, or to recover from a webhook gap. You don't need to refresh after a configuration change like updating the Value Composer, the storage schema, or the sync's channel/locale mappings - those revalidate automatically (see [change detection](#change-detection) below). ## What the connector does for you A connector isn't a passthrough. Each adapter normalizes its source's quirks before records reach your Data Sync - so what arrives is already in a shape your Value Composer can map cleanly. What that means varies by connector: > [card] Variant denormalization > > Where the source mixes parent products and their variants in one structure, the connector splits them into separate records linked by `parentId` - so blocks drive grids off products and detail off variants. > [card] Currency-resolved prices > > When the source carries multi-currency pricing, the connector pre-filters the price array to the channel's currencies and stamps `currencyCode` and `currencyPrecision` on each entry. > [card] Translation merging > > Source-side localized payloads are resolved to the right value per channel translation. Your sync references field names directly - no walking source-specific translation structures. > [card] Reconciliation on refresh > > Where a connector supports it, a refresh diffs the previous result against the source's current state and emits deletes for records that disappeared - your storage doesn't accumulate orphans. For exact per-connector behavior - which associations are pre-loaded, where translations fall back, what auto-delete covers - see each connector's "What the data looks like" section. ### Reserved `$`-prefix namespace When a connector normalizes source data, it sometimes stamps the result onto the feed record under a **reserved `$`-prefix key** so it sits next to your record's own fields without colliding with them. For example: * **`$rel`** - relation metadata (Shopware uses this to expose a flat list of category IDs as `$rel.categoryIds` so syncs don't have to walk the full association) * **`$options`** - variant-defining attributes * **`$properties`** - descriptive attributes that don't drive variant selection ## Update methods Frontic supports three update methods for keeping feeds in sync. Each connector declares which combinations it supports - some support all three, some only a subset. > [card] Trigger > > The source pushes a webhook to Frontic on every change - near-real-time delivery for time-sensitive catalogs. > [card] Polling > > Frontic pulls from the source on a schedule. Lower bandwidth than triggers, with a built-in safety net behind them. > [card] Ingest API > > The source pushes records into Frontic's [Ingest API](https://docs.frontic.com/reference/ingest-api.md). You control timing, batching, and payload shape from your code. A connector can support more than one method, and you pick which ones to enable per feed. If possible, a production setup should combine **trigger + polling** - webhooks for low-latency updates, polling as a backstop for missed events. ## Change detection When a record arrives at Frontic - through any update method - the connector takes a fingerprint of it and compares against the version already on file. If nothing has materially changed, the write is dropped early: **no storage update, no cache to purge in your frontend, no downstream re-render**. Intake itself still happens (and still counts as an **API Update**), but real updates further down the queue don't get held up by no-op churn. If you control the source, prefer to push only when something has actually changed - that's always cheapest. If you can't (a nightly file drop with yesterday's content, a webhook fired by an unrelated edit), the fingerprint check keeps the downstream impact minimal. When you change a configuration like the Value Composer, the storage schema, or the sync's channel/locale mappings, the fingerprint shifts on every affected record - Frontic re-emits them automatically, so the new shape lands downstream without a manual refresh. ### On the dashboard The **Pipeline** card on the project dashboard shows the last 24 hours of this flow: * **Records in** counts feed record changes. The first number is this project's feeds; the number after the slash is every feed in your team, so you can see how much of the traffic is yours. * **Renderings out** counts the storage records this project wrote. It's scoped to the project. * **Skipped** appears under either number when change detection dropped something: a feed record that arrived with the same payload as the one on file, or a storage record whose fingerprint didn't change. The skipped count under Records in is team-wide; the one under Renderings out is this project's own. Skipped changes aren't part of the main numbers. ## Data Syncs - mapping integration to project Up to this point, everything is integration-side. The Data Sync is where the integration meets your project. A Data Sync sits between a feed and a storage and carries two kinds of mappings: > [card] Channel → Scope > > For every project scope, pick which integration channel powers it. The same channel can power many scopes (one Shopware sales channel feeding both `public` and `b2b` scopes), or different scopes can be powered by different channels (one channel per scope). > [card] Channel locale → Project locale > > For every project locale within a scope, pick which translation from the mapped channel fills it. The same channel translation can map to many project locales (a single `de` translation feeding `de-DE`, `de-AT`, and `de-CH`). Both mappings are constrained: **every project scope and every locale within that scope must be satisfied** before the Data Sync can run. Frontic validates this at save time - you can't end up with a project scope or locale silently missing data. Where a project locale's mapped channel translation has no value for a record, Frontic falls back to the channel's **fallback translation** before returning `null`. That makes partially-translated catalogues safe to ship: the experience still renders, it just renders the fallback locale's value where translation hasn't caught up. ## Available connectors > [card] [Shopify](https://docs.frontic.com/connectors/shopify.md) > > Shopify Admin API connector for products, blogs, pages, and metaobjects. > [card] [Shopware](https://docs.frontic.com/connectors/shopware.md) > > Shopware 6 connector with companion plugin, end-to-end onboarding, and webhook updates. > [card] [commercetools](https://docs.frontic.com/connectors/commercetools.md) > > commercetools connector for products and categories via OAuth 2.0. > [card] [Akeneo](https://docs.frontic.com/connectors/akeneo.md) > > Akeneo PIM connector for product attributes, families, and categories. > [card] [WEBSALE](https://docs.frontic.com/connectors/websale.md) > > WEBSALE connector for products and categories, with prices and stock per subshop. > [card] [Contentful](https://docs.frontic.com/connectors/contentful.md) > > Contentful connector for editorial content with environment selection. > [card] [Storyblok](https://docs.frontic.com/connectors/storyblok.md) > > Storyblok connector for stories with draft / published mode toggle. > [card] [Reviews.io](https://docs.frontic.com/connectors/reviews-io.md) > > Reviews.io connector for product and company reviews. > [card] [n8n](https://docs.frontic.com/connectors/n8n.md) > > n8n recipe pack for Frontic - push records via the Ingest API from any n8n workflow. > [card] [File Importer](https://docs.frontic.com/connectors/csv-import.md) > > SFTP-based CSV connector for nightly exports and partner-supplied feeds. > [card] [Custom](https://docs.frontic.com/connectors/custom.md) > > For source systems without a first-party connector - push any JSON shape via the Ingest API. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.