Article data
The Product Catalog service manages articles — creating, updating and retrieving them. Article information is store-specific as well as general, so the store identifier matters: sale prices differ between stores and chains. For retrieval you can look up a single article by store and article identifier, or run a configurable search across a set of articles, narrowing by store, by an optional set of article identifiers, and by whether you want only articles sold via displayed barcodes or those available through a catalog such as pastry.Import scenarios
All three upsert the records they carry.
Product data
The same service stores core product properties that apply across all stores. If store-level pricing is not part of your integration, product data alone may be enough. A product record holds its unique identifier and name, EAN numbers, images, brand, suppliers, and any additional attributes you need. Products are stored in a hierarchical tree, grouping related products under common parent categories — broad classifications down to specific items. That structure is what makes category-based promotions possible.Purchase data
Send checkout transactions to Lobyco to allocate benefits and generate digital receipts. The rules, validation and integration options are covered in Transaction Data.Store data
The Store service handles retail chains and individual stores: identifiers, names, contact details, physical location, operational status and opening hours. Chain data carries the branding that unifies stores under one identity — logos, colours and identifiers. Chains must exist before the stores that reference them. Both can be imported in bulk or maintained individually.Fields, import modes, validation rules and the order to run imports in are covered in Importing store and chain data.
Data Import Service
The Data Import Service is the bulk loading path used by Store Service, Offers and others. It validates, processes and imports data from external systems in a controlled, observable way — asynchronously, so a large load never blocks your call. It handles tens of thousands of records or more, and applies back-pressure and throttling so a big import cannot overwhelm the service receiving it. Use it to migrate from legacy systems, bulk load POS transactions, run scheduled synchronisations, or correct records in bulk.How an import runs
1
Create the job
Returns ajobId that identifies the operation from here on.2
Upload and validate
The file is parsed and every record checked against business rules.3
Process valid records
Validated data is passed to the target service.4
Read the results
Processed, succeeded and failed counts, with detailed errors per failed row.The v2 API creates the job and uploads the file in one request. Prefer it for new integrations — it removes a round trip and a whole class of half-created-job states.
File formats
Both formats require field names matching the target entity’s schema.
A JSONL file looks like this: