# How to integrate Tulip with your ERP > Source: https://netray.co/erp-help/mes-tulip-to-erp-integration-connectors-tables-work-orders > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Tulip talks to an ERP through Connectors: you define an HTTP or SQL connector with functions that your Apps call as triggers. Use Tulip Tables as a local cache of work orders and as an outbox of completions, and let an integration layer or the ERP's API do the actual posting. Keep ERP credentials in the connector, not in the App logic. ## Kind how-to ## System mfg-systems ## Erp Tulip with any ERP ## Module Tulip / Connectors and Tables ## Query how to integrate Tulip with ERP ## Alternate Queries - Tulip connector function ERP work order - Tulip Apps sync with SAP NetSuite SyteLine - Tulip Tables to ERP data sync - Tulip on-prem connector host ERP ## Applies To Tulip Frontline Operations Platform with Connectors (HTTP and SQL), Connector Functions, Tulip Tables, and the On-Prem Connector Host; any ERP with an API, database interface or middleware. ## Steps ### Connect a Tulip App to an ERP **Items:** List what the App needs from the ERP (open work orders, routing steps, item data, operators) and what it must return (completed quantity, scrap, labor time, lot numbers). Create a Connector in Tulip (Settings, Connectors) of the right type: HTTP for REST/SOAP-style APIs or SQL for a database view, and store the credentials there. If the ERP is not reachable from the cloud, install the On-Prem Connector Host inside your network so Tulip reaches the ERP through it, and restrict it to the specific endpoints required. Define Connector Functions, for example GetOpenWorkOrders and PostCompletion, with typed inputs and outputs, and test each in the connector editor with real sample data. Create Tulip Tables such as WorkOrders (cache) and CompletionOutbox (events to post). Add a status column and a unique event key to the outbox. In the App, use Triggers to call GetOpenWorkOrders on a schedule or button and upsert into the WorkOrders table, and write a CompletionOutbox record when the operator finishes a step. Run the posting call from an Automation or an integration layer that reads the outbox, calls the ERP, and writes back POSTED or ERROR with the response message. Show the operator or supervisor the post status in the App so errors are corrected at the station, not discovered later. ## Sections ### Connector Functions: how they work **Body:** A Connector Function is a named, typed call defined once and reused across Apps. For an HTTP connector you set method, path, headers, query parameters and body template, then map the JSON response to output fields such as work order number, quantity and due date. In the App editor, a Trigger calls the function and writes results into variables or Tables. Keep functions small and single purpose. A GetWorkOrder function by order number is easier to test and cache than a function returning every order. Handle pagination on the ERP side or in the function, because very large responses slow Apps on tablets and can hit platform limits. Errors matter: build the trigger so a non-success response is captured and shown, rather than assuming the call worked. A silent failure is the main reason operators finish a job in Tulip and find no record in the ERP. **Code:** POST /api/v1/production-completions Headers: Authorization: Bearer , Idempotency-Key: {{event_key}} Body: {"workOrder":"{{wo}}","operation":{{op}},"qtyGood":{{good}},"qtyScrap":{{scrap}},"completedAt":"{{ts}}"} ### Using Tulip Tables as cache and outbox **Body:** Tulip Tables are good for data that Apps share across stations: a cache of released work orders and routing steps, and a record of events. Treat the work order table as a copy refreshed from the ERP, not the master, and store the ERP's last-modified time so an App can warn when an order changed after the operator started. The outbox pattern matters because tablet networks drop and ERPs go down for maintenance. Writing the completion to a Table first guarantees the event exists, then a posting process retries until the ERP accepts it. Include a unique event key and send it as an idempotency key or reference field so retries cannot double-post. Do not store sensitive data you do not need. If the ERP holds controlled technical data, keep drawings and specs referenced by link or ID and enforce the ERP or PLM permissions, rather than copying files into Tulip. ### Which system owns what **Body:** Common split: the ERP owns orders, routings, items, inventory and cost. Tulip owns operator guidance, data capture (checks, measurements, photos), station state and step timing. The quality and inspection results captured in Tulip often feed a QMS or the ERP's quality module, so decide early where the record of truth lives. Labor and time posting is where disputes arise. Tulip can capture step start and stop to the second, but the ERP may expect labor by operation and employee. Agree the rule: post total labor per operation from Tulip steps, or keep punch-based labor in the ERP and use Tulip times for analysis only. For aerospace, defense and medical environments, attach the evidence the audit needs, such as serial or lot, operator ID, tool or gauge ID and measured values, to the same event key as the ERP completion so the two records can be traced together. ### Security, hosting and change control **Body:** Use a dedicated integration account with only the permissions needed: read on open orders, create on completions. Never reuse an administrator login. Rotate tokens and keep a list of which connector uses which credential. If data residency or network rules prevent a cloud connection to the ERP, the On-Prem Connector Host and outbound-only firewall rules are the usual answer. Confirm with your security team what data leaves the plant to the Tulip cloud and document it. Version your connectors and test functions in a non-production ERP company or test environment before changing an App used on live lines, since an API field rename in an ERP upgrade will break a mapped function. ## Pitfalls - Calling the ERP directly from every App step without an outbox, so one network blip loses a completion. - No idempotency key, causing double-posted quantities on retry. - Treating the cached work order Table as the master and ignoring ERP changes after release. - Returning huge payloads to a tablet instead of narrow, paged functions. - Using an ERP admin credential in the connector. - Leaving error responses unhandled so operators think a post succeeded. ## Ai Angle An assistant grounded in the ERP and in an export of the Tulip Tables can answer which completions are stuck in ERROR, which orders were completed in Tulip but not in the ERP, and why a post was rejected, using the ERP's own message text. With ERPray it works read-only on live ERP data, shows the query behind each answer and respects ERP roles. It does not post to the ERP; reposting remains your integration layer or a human action. ## Faq ### Does Tulip have a prebuilt connector for my ERP? **Answer:** Tulip provides generic HTTP and SQL connectors and a library of Connector Functions, and may offer templates for some systems. Availability and depth vary by ERP and release, so confirm with Tulip or a partner. Many plants build a thin custom connector against their ERP's API. ### Do I need middleware between Tulip and the ERP? **Answer:** Not always. For simple read and post flows, Connector Functions calling the ERP API can be enough. Add middleware or an integration platform when you need queuing, transformation across several systems, heavy retry logic or monitoring beyond what Tulip provides. ### How do I stop duplicate completions? **Answer:** Generate a unique event key in the App when the operator completes a step, store it in the outbox Table, and send it to the ERP as a reference or idempotency value. The poster should skip any key already marked posted, and the ERP interface should reject duplicates where it can. ### Can Tulip run when the ERP is down? **Answer:** Yes if you design for it. Cache the released work orders in a Table and queue completions in the outbox. Operators keep working, and the posting process drains the queue once the ERP returns. Test this by deliberately blocking the ERP during a pilot. ## Search terms Tulip ERP integration, Tulip connector function, Tulip Tables work orders, Tulip on-prem connector host, Tulip SAP integration, Tulip NetSuite integration, Tulip frontline operations ERP, Tulip completion posting, Tulip MES ERP sync --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json