--- title: "Architecture basics for integrating Tulip to a transactional business system" slug: "architecture-basics-for-integrating-tulip-to-a-transactional-business-system" updated: 2026-03-17T21:57:37Z published: 2026-03-17T21:57:37Z canonical: "support.tulip.co/architecture-basics-for-integrating-tulip-to-a-transactional-business-system" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Architecture basics for integrating Tulip to a transactional business system ## Overview of This Article - The scope of this article discusses integration of Tulip with transactional business systems, e.g. ERPs. - The purpose of this article is to provide the following: - A high-level overview of what is possible. - What an ideal integration looks like. - What other integration options exist when an ideal integration is not possible or practical. ## Tulip's Position Within an Enterprise Data Flow In the image below you will see at a high level Tulip's typical position within an enterprise data flow. Tulip can integrate to an ERP or other transactional business systems for whatever use cases determined to be appropriate and relevant by manufacturing operations. ![Tulip position in enterprise data flow - 2026 February.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Tulip%20position%20in%20enterprise%20data%20flow%20-%202026%20February.png) ### Knowledge Base Articles with Guidance on Planning an Integration - [Plan an integration between Tulip and an MES or ERP](/r230/docs/plan-an-integration-between-tulip-and-an-mes-or-erp) - [Build your first system integration](/r230/docs/build-your-first-system-integration) ## Premises & Principles of an Ideal Integration ### Premises & Principles - Maintain a single Source of Truth / System of Record. - Keep the integration: Simple, Current, and Performant. ### Assumptions - The Source of Truth has the latest and greatest information for that which the system is the Source of Truth. - The Source of Truth can be integrated via HTTP REST APIs. - The Source of Truth's architecture and integration use case(s) allow for an "ideal" integration architecture. ### Ideal Integration Defined - Integrate with the Source of Truth in real-time via HTTP Connectors - This option is listed as '[Option 1](/r230/docs/architecture-fundamentals-of-integrating-tulip-to-a-transactional-business-system#option-1-realtime-integration-via-http-connectors)' in the discussion below. ## Factors That May Prevent an Ideal Integration Various factors can prevent a Tulip customer from integrating to a transactional business system in the aforementioned Ideal way. These factors include and are not limited to the following: - The Source of Truth has recurring long downtimes for scheduled maintenance. - Hard business requirements mandating a manufacturing solution is not in any way dependent on real-time availability of Sources of Truth, e.g. in case the Source of Truth is unavailable due to an unexpected interruption/outage. - The performance of the Source of Truth makes certain integration use cases (e.g. fetching several hundred components for an Order's BOM) impractical to execute in real time. - I.T. leadership disallows direct integrations to the Source of Truth ## Typical ERP/Tulip Integration Use Cases The image below illustrates some of the most common use cases in which Tulip is typically integrated with an ERP. This is by no means an exhaustive list but rather meant to be representative of common integrations and a reference for further discussion herein. ![Typical ERP Integration Use Cases.svg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Typical%20ERP%20Integration%20Use%20Cases.svg) Generally each of these posts (e.g. 'Get BoM') is correlated with a given API endpoint of the ERP. For the API endpoints relevant to your integration use case(s) you would build a Connector Function. ## Options to Integrate Tulip to Transactional Business Systems The following high-level diagram shows the broad variety of options with which Tulip can be integrated to a transactional business system. The numbers on the left represent the typical order of recommendation but also (somewhat) the popularity of the options used. ![Five Options.svg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Five%20Options.svg) #### Optional iPaaS Note: the yellow dashed iPaaS boxes represent an architectural choice. An iPaaS is not always necessary but could be used by a customer as part of the architecture for various reasons (e.g. automatic retry of posts that time out, middleware logging, etc...). Alternatively to an iPaaS a customer might use custom scripting (e.g. with Python) or in the case of Architecture 1, integrate directly to the Business System without an iPaaS. - Why use an iPaaS? - To provide (with custom development) modern API endpoints if the Business System does not have those already available. - Enable automated retries on API timeouts. - API logging (enables better debugging when needed). - Which iPaaS? - Tulip does not have any specific recommendations regarding which iPaaS (but Boomi & Mulesoft are common choices used by our customers). Customer Infrastructure is the Customer's Responsibility Tulip consistently recommends Option 1 whenever possible. The purpose of this article is to provide high-level guidance on the art of the possible. Tulip can offer some guidance and advisement on the various options discussed herein, however ultimately it is up to a Tulip Customer to determine which of these architecture options is practical and sensible based on various factors, including the [Factors That May Prevent an Ideal Integration](/r230/docs/architecture-fundamentals-of-integrating-tulip-to-a-transactional-business-system#factors-that-may-prevent-an-ideal-integration), a customer's own resource availability and internal expertise thereof, and [limits of the Tulip platform](/r230/docs/platform-limits-and-best-practices). ### Option 1 - Real-Time Integration via HTTP Connector The first row in the 'Options to Integrate' diagram represents the Ideal Integration architecture discussed earlier and uses HTTP Connectors. This is by far the most common method with which Tulip customers integrate to transactional business systems such as ERPs. The implementation of such an integration via HTTP Connectors is discussed at great length elsewhere in Knowledge Base and Tulip University. ![Path 1 - HTTP Synchronous.svg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Path%201%20-%20HTTP%20Synchronous.svg) #### Key Knowledge Base Resources Relevant to Integration via HTTP Connectors - ['HTTP Connectors' Fundamentals](/r230/docs/http-connectors) - [Connector Limits](/r230/docs/connector-limits) #### Tulip University Courseware on HTTP Connectors - [Build and Use HTTP Connectors in Apps](https://university.tulip.co/http-connectors) #### Ideal Integration with Cloud-Based Business System The below diagram dives a little deeper into this ideal integration. This shows an individual Connector and Connector Function in use on a given Trigger Action. ![Option 1 deep dive v2.svg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Option%201%20deep%20dive%20v2.svg) ### Option 2 - Real-Time Integration via SQL Connector If all of the following apply, integration via SQL Connector is often the next best option: - HTTP REST APIs are not available in the Business System. - Tulip's SQL Connector [supports connectivity to the Business System's database](/r230/docs/sql-connectors#1-choose-your-database-type). - A Customer's I.T. allows connectivity to the database via SQL statements or stored procedures. ![Option 2.svg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Option%202%281%29.svg) #### Fundamental Materials in Knowledge Base & University for Option 2 - [SQL Connectors](/r230/docs/sql-connectors) - [Connector Limits](/r230/docs/connector-limits) - [Tulip University - SQL Connectors](https://university.tulip.co/sql-connectors) ### Option 3 - Asynchronous Integration via Tulip Table Records ![Option 3.svg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Option%203.svg) The third row in our 'Options to Integrate' diagram shows an asynchronous integration between a Business System and Tulip via Tulip Table records using the Tulip Table APIs. This commonly involves an iPaaS or custom scripting wherein integration-relevant content (e.g. newly-released Work Orders) are posted into their corresponding Tulip Table(s) on a regular basis - ideally as close to real-time as possible. Customers may be able to implement this in an event-driven way wherein an order being released in ERP triggers an iPaaS workflow that immediately posts data into Tulip. The other side of the integration involves the iPaaS or custom scripting fetching content from the Tulip Tables (again via Tulip Table APIs) on a frequent basis, and then posting the content back to the destination Business System. #### A common practice to keep track of data successfully sychronized back into the Business System. Consider a Tulip Table that represents consumption of raw material lots. - Use a Boolean-type column called something like 'Successfully Synched to ERP' - When the Tulip app(s) create new records into this table, that column can be NULL or False. - When the iPaaS fetches the record, and confirms the data successfully POSTed back to the Business System, the iPaaS would update that column from NULL/False to True. - This allows the iPaaS to narrow down its 'synch back to ERP' reconciliation activities to just those Tulip Table records wherein the 'Successfully Posted Back' column is NULL or False. #### Fundamental Materials in Knowledge Base & University for Option 3 - [Tulip Table API guide](/r230/docs/table-api-guide) - [Tulip Table API Limits](/r230/docs/best-practices-for-high-performance-apps) - [Tulip University Feature Deep-Dive: Table API](https://university.tulip.co/feature-deep-dive-table-api) ### Option 4 - Asynchronous Integration via 3rd-Party Database & SQL Connector ![Option 4.svg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Option%204.svg) The fourth row in our 'Options to Integrate' diagram shows an asynchronous integration between a Business System and Tulip via a third-party database and a SQL Connector. - Similar to other options, this may involve an iPaaS or database scripting as determined by the Customer's data architects. - Regarding synchronization frequency, the same principles apply - keep the data synchronization as close to real time as possible. #### Fundamental Materials in Knowledge Base & University for Option 4 - [SQL Connectors](/r230/docs/sql-connectors) - [Connector Limits](/r230/docs/connector-limits) - [Tulip University - SQL Connectors](https://university.tulip.co/sql-connectors) ### Option 5 - Asynchronous Integration via Data Lake/House ![Option 5.svg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Option%205.svg) The last row in our 'Options to Integrate' diagram shows a rarely used asynchronous integration between a Business System and Tulip via a Data Lake/House. - Regarding synchronization frequency, the same principles apply as Options 3 and 4 - keep the data synchronization as close to real time as possible. #### Fundamental Materials in Knowledge Base & University for Option 5 - [SQL Connectors](/r230/docs/sql-connectors) - [Connector Limits](/r230/docs/connector-limits) - [Tulip University - SQL Connectors](https://university.tulip.co/sql-connectors) **Connectors** **Connectors** enable real-time connectivity between your Tulip solution and a transactional system (e.g. an ERP). The output of a Connector Function can be used in Tulip Apps, Automations, and Functions. - **HTTP Connectors** utilize HTTP API endpoints. - **SQL Connectors** can enable connectivity with certain SQL databases. - **MQTT Connectors** can connect to MQTT brokers for machine monitoring. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/connector.gif) **Connector Function** **Connector Functions** are individual operations to interact with an HTTP or SQL Datasources. Connector Functions can have inputs and outputs, and can be called from: Triggers, Functions, Automations, and AI Agents. Once pulled, data can be used throughout your applications. **Integration Platform as a Service (iPaaS)** **iPaaS** is a suite of cloud-based services that connects and integrates disparate applications, data, and processes, regardless of whether they are on-premises or in the cloud. **Trigger** **Triggers** are groups of logic that are tied to an app event, such as step open, timer, widget interaction, etc. App builders can add triggers to **widgets**, **machines**, **devices**, **apps**, and **steps**. **Triggers** can contain **actions**, **transitions**, and **conditions**.