Integrating with Tulip
Tulip is only as good as the information in front of your store teams. That means moving data between the systems you already run — POS, ERP, e-commerce, CRM, loyalty, marketing — and Tulip, and keeping it current.
This page lists every supported way to do that and helps you choose the correct approach. If you are starting from scratch, read Planning Your Integration first: it covers which data Tulip needs and in what order.
Two ways to connect
Tulip connects to your systems. Integration Builder is Tulip’s own integration platform. You point it at your APIs, files or cloud data platforms; it collects data on a schedule or the moment an event happens, reshapes it to fit Tulip, checks it, and loads it. It works in both directions, so activity captured in store flows back to your systems of record. There is no separate middleware to buy and no integration code for you to host.
Your systems send to Tulip. If your team would rather push, every underlying path is open and documented: a REST API for real-time calls, a bulk service for very large loads, a file drop for scheduled exports, and webhooks so Tulip can tell you the moment something changes.
Most retailers use both. A nightly catalog refresh might arrive as a file, while customer updates go through the API in real time, with Integration Builder orchestrating the parts nobody wants to hand-build.
Choose your integration path
| Path | What it does | Reach for it when |
|---|---|---|
| Integration Builder | Connects to your systems and moves data on a schedule or on an event, in either direction, built in a visual interface | You want Tulip to own the moving parts, you are connecting to an API or a cloud data platform, or the flow needs logic of its own |
| Core API | REST API for reading and writing records in real time | Your team is building directly against Tulip and wants full control |
| Bulk API | High-volume batch loading | An initial migration, or a scheduled full refresh of a large data set |
| File Importer | Picks up CSV files from a secure file drop | Your systems already produce scheduled file exports |
| Webhooks | Notifies your systems when something changes in Tulip | You need to react to in-store activity as it happens |
| Data Bridge | Reshapes and validates data as it moves | Your data does not already match Tulip’s shape, or you want to reject bad records before they land |
Data Bridge is worth calling out: it is not a separate pipe but a layer. You can apply the same mapping and validation rules to an API call, to a file import, or as steps inside an Integration Builder workflow.
Connecting to cloud data platforms
If your data already lands in Snowflake, Databricks, BigQuery or a similar platform, Integration Builder reads from it the same way it reads any other source — over the platform’s own API, or from a scheduled file export. See Working with APIs and data platforms.
Who builds the integration
Either side can. Integration Builder is switched on per environment; once it is, it is self-serve, so your team can build and run workflows without involving Tulip. Most retailers do not: Tulip’s delivery team usually builds the workflows and mappings during onboarding and keeps them running afterwards, with your team providing API access or a file drop, a data expert to confirm the mapping is right, and sign-off before go-live.
Whoever builds it, the logs and run history are visible to you.
Next steps
- Planning Your Integration — what data Tulip needs, and in what order
- Integration Builder — how workflows are built, tested and monitored
- Core API — the REST API reference
- Data Bridge — mapping and validation
- Integration Layer — how integration fits into the wider Tulip platform