Ingest Data

Ingest is the process of importing data - products, categories, content, and more - from external sources into your project using Connectors. It can be a one-time import or a continuous sync that keeps your project up to date. Manage your integrations from the Integrations section of the admin app.

​

The ingest flow

Data moves through two steps on its way into your project:

​

Integrations and Data Feeds

An Integration is your connection to an external data source. It holds the credentials, the connection instance, and the channels that map the source’s locales and scopes to your project. Integrations live at the team level, so a single integration can serve multiple projects. Each integration has one or more Data Feeds - one per resource type. A Shopware integration might expose a products feed and a categories feed. For built-in connectors, the feed does more than pass data through - it normalizes the source’s structure into a shape Frontic can work with. A Shopify product with inline variants, for example, becomes separate product and variant feed records, each with proper keys, translations, and currency annotations. A feed can have multiple subscribing Data Syncs - pointing to different storages, even across different projects.

​

Data Feeds

You manage feeds by clicking on an integration in the Integrations section. Each feed has four tabs:

​

Records

Browse and inspect feed records before they flow into the Value Composer and get shaped into storage records.

• Filter by any field - click Filter above the list and pick any field on the feed schema. Pick a value or an operator, or a date range such as the past week or a custom period, and the list narrows down. Stack several filters and toggle between Match all and Match any, or Clear filters to start over.
• Switch channel, translation, and currency - the settings dropdown lets you pick which integration channel, translation, and currency to inspect against, useful when the same feed serves multiple locales or scopes.
• Toggle products vs. variants - for product-type feeds, switch the fetch mode between browsing parent products and individual variants.
• Jump between a product and its variants - on product-type feeds, open a record and use Search for Variants on a product to list only its variants, or Search for Parent on a variant to jump to its product. Both sit in the ⋮ menu at the top of the detail panel. The browser switches between products and variants for you and shows the result as a filter chip.
• Inspect individual records - the detail panel lists every field with its type, supports searching within fields, and offers a JSON view for the raw payload. System fields (key, parentKey, createdAt, updatedAt) sit alongside the payload.

​

Settings

Every feed has a name, a Field for Source ID (the field that uniquely identifies each record), and a Field for Parent Source ID (for parent/child relationships like product/variant). Beyond that, settings depend on the connector type - a CSV feed, for example, lets you configure the delimiter, a regex pattern for file matching, processing order, and custom record identifiers.

​

Schema

The feed schema is inferred automatically once the first records arrive - field names, types, and structure. Want to get ahead of that? Upload a sample record or define fields by hand. Either way, new fields that appear later are picked up on the fly. Frontic will periodically update the schema by itself with new record updates. You can also update the schema from one of your records in the feed record browser. The feed schema is more than documentation - it defines which fields are available in the Value Composer and drives change detection through the entire pipeline. Only fields present in the schema can be used in a Data Sync. Fields you don’t need can be muted, which excludes them from processing entirely. Change detection starts here: when a record updates, Frontic checks whether any of the changed fields are actually connected to a storage schema. If not, the update is a no-op and the storage record stays untouched. The same logic carries forward to block indices - only blocks with real changes get rebuilt. This keeps the pipeline fast and your frontend caches stable, since they only purge when something genuinely changes. Each field in the schema carries a status:

• New - the field showed up on a record but the schema hasn’t seen it before. Review and accept (or mute) so downstream processing knows what to do with it.
• Active - the field is in use; available in Value Composer slots and tracked by change detection.
• Muted - the field is ignored. Nothing on the field reaches a Data Sync, and changes to it don’t trigger downstream rebuilds.

Mixed types. When a field’s value type varies across records - sometimes a string, sometimes a number, sometimes an array - the schema picks the first type it saw and downstream coercion handles the rest where it can. If the variance is meaningful (e.g. a dimensions field that’s a string for some products and a structured object for others) and you don’t want the coercion fallback, the cleanest fix is to define the field by hand with the type you want to enforce, and split the alternative shape off into a separate field via the Value Composer during sync.

​

Updates

Three update methods exist for keeping feed data current. Which ones are available depends on the connector - built-in connectors pre-configure the methods they support.

• Ingest - push records directly to the Frontic Ingest API. Full control over timing, individual records or batch updates.
• Trigger - send a webhook to Frontic’s trigger endpoint. Frontic fetches the latest data from the source and syncs any changes.
• Polling - scheduled sync jobs that periodically check the source for updates. Configure the interval, time window, and active hours.

Check your connector’s documentation for which methods it supports.

​

What happens next

Once feed records are flowing, a Data Sync connects the feed to a Data Storage and transforms the records into the shape your storage expects. That process is covered on the Data Storages page.