> ## 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 Auth and host for one source system. Valid options come from the source itself. Translations the channel covers, plus connector-specific source segmentation where applicable. One feed per resource type, each with assigned channels and an update method. ## How data flows from source to project Your Shopware store, Shopify shop, CSV file drop, ERP — whatever's authoritative for the data. The connector's link to that source. Auth, host, channel config — everything that decides *what* to pull and *from where*. Live records inside Frontic, one feed per resource type. The connector keeps these in sync with the source via the feed's update methods. 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](/data-integration/value-composer) reshapes each field. 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` ## 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** and **Akeneo** 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, and CMS Pages; 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: Name the feed and pick its resource type from the connector's available types. Configure the update methods this feed uses to stay in sync (see below). Only the methods the connector supports are offered. 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: 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. 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. 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. 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. The source pushes a webhook to Frontic on every change — near-real-time delivery for time-sensitive catalogs. Frontic pulls from the source on a schedule. Lower bandwidth than triggers, with a built-in safety net behind them. The source pushes records into Frontic's [Ingest API](/reference/ingest-api). 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. ## 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: 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). 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
Shopify Admin API connector for products, blogs, pages, and metaobjects.
Shopware 6 connector with companion plugin, end-to-end onboarding, and webhook updates.
commercetools connector for products and categories via OAuth 2.0.
Akeneo PIM connector for product attributes, families, and categories.
Contentful connector for editorial content with environment selection.
Storyblok connector for stories with draft / published mode toggle.
Reviews.io connector for product and company reviews.
n8n recipe pack for Frontic — push records via the Ingest API from any n8n workflow.
SFTP-based CSV connector for nightly exports and partner-supplied feeds.
For source systems without a first-party connector — push any JSON shape via the Ingest API.