Ingestion

Routinely, you will be ingesting data into Flex. New customers, customer updates, deactivations, new products, transactions and changes to outlets will need to be synchronised with Flex.

Sequencing

Data can be ingested in any order. There is no need to coordinate the sequence between entity types. For example, transactions referencing a specific outlet or customer may be ingested even if those entities haven’t been synced yet. Flex handles the dependencies automatically.

However, for individual entities, we recommend ingesting records in chronological order where possible.

Detecting Changes

Flex supports an Agent API for persisting state between synchronisation tasks. You can use this API to record any metadata that will assist you when your batch jobs execute.

Batching

For endpoints that accept an array of records, up to 500 records may be ingested in any single API call.

Idempotency

The API supports idempotency for safely retrying requests without accidentally performing the same operation twice. Assuming you use a predictable/static external identifier per entity, you can safely retry failed requests. Then, if a connection error occurs, you can safely repeat the request without risk of creating a second object or performing the update twice.

Frequency

At a minimum, data should be synchronised daily. We recommend that customer event data is ingested as close to real-time as possible, so that communication preferences can be honoured as soon as possible.