HubSpot + Infor integration

Infor sells its ERP by industry rather than as one product. Infor LN runs discrete manufacturers in aerospace and defense, automotive, high tech and industrial manufacturing. Infor M3 serves distributors and fashion, food and beverage and chemical companies. SyteLine, which grew into the full cloud suite Infor calls CloudSuite Industrial, serves industrial manufacturers, many of them small and mid-sized. Their account managers increasingly work in HubSpot, and the ERP knows things about each customer that HubSpot does not.

The gap shows up in ordinary conversations. A rep promises a delivery date without seeing the open order, chases a customer whose invoice is already overdue, or quotes a part the plant no longer makes. The answer sits in the ERP, behind screens and licences built for planners and buyers rather than sellers, so the rep emails customer service and waits.

What sets Infor apart is that the integration layer already exists. ION, the integration platform inside Infor OS, carries changes between applications as business object documents, or BODs, and feeds the Infor Data Lake, while Infor’s API Gateway fronts the product APIs with OAuth 2.0. So the first questions are about people and access rather than the API: who administers ION for you, whether a data flow can be added, and whether the Data Lake already holds the objects you want.

Five BOD nouns carry the relationship. CustomerPartyMaster becomes a HubSpot company, ContactMaster becomes a contact, SalesOrder becomes a deal, Invoice lands on a custom object and ItemMaster becomes a product. These are standard Infor nouns, so the mapping holds whichever ERP publishes them, with differences in the fields each ERP fills.

A first build moves data one way only. The ERP owns the customer, the order and the invoice, and HubSpot shows them read only. A won deal that must become a sales order goes back in a later phase as a Process BOD, which the owning ERP answers with an Acknowledge, so a rejected order is visible rather than lost.

Keys come from the BOD, never from a name. Each record is written against the ERP’s own ID in a custom HubSpot property, together with the company or site that published it, so two sites can never overwrite each other’s records. People are matched differently: a contact keys on email, and the contact ID from the BOD settles a tie.

Events come first and a nightly sweep checks them, which is the house webhook queue pattern fed by ION. A data flow subscribes to the Sync BODs the ERP publishes and sends each one through an API Gateway connection point to our ingest endpoint. ION can call only an API that is registered in API Gateway with a Swagger or OpenAPI document, so the endpoint is registered as a non-Infor API suite before anything flows.

The endpoint writes each BOD to a queue before it answers. A consumer maps it and writes HubSpot in keyed batch upserts on the ERP IDs, then links orders and invoices to their company in a second pass. Our service keeps its own state: a link store from ERP ID to HubSpot ID, and a watermark per Data Lake object.

The sweep runs nightly. It queries the Infor Data Lake through Compass, using the infor.lastmodified() function to read only objects added since the last watermark, and repairs anything the flow missed. A replay is the same query over an older window. On M3 the balance shifts: Infor recommends the Data Lake for synchronizing M3 data to outside systems and says M3 keeps it updated close to real time, so there the Compass read runs every few minutes and carries most of the load.

On Infor the deciding question is who controls ION, more than which ERP you run. If your team or your Infor partner can add a data flow and register an API suite, a custom API integration gives you each change as it is published and a sweep that proves nothing was dropped.

Infor OS, with ION inside it, is also Infor’s own iPaaS, and an API Gateway connection point can call HubSpot directly once HubSpot’s endpoints are registered. That suits a one-way push of one or two objects, with the mapping kept in ION and no reconciliation beyond what you build there.

The third route is one of Commercient’s two Infor apps in the marketplace: a packaged sync for a standard customer and order feed, supported by Commercient rather than by your team.

1. Scope. We meet whoever administers ION, confirm which BODs your ERP and release publish, and check that the Data Lake holds the same objects.
2. Architect. We fix the nouns, the keys with their company or site, the data flow, the API suite registration and the sweep window, and write them down.
3. Build. The endpoint, queue, consumer and sweep are built against a non-production tenant and a HubSpot sandbox, with a portal allowlist from the first commit.
4. Validate. We replay a week of BODs, run a full Data Lake reconciliation, and walk every difference with the order desk.
5. Operate. We watch Confirm BODs, queue depth and sweep repairs, and recheck the flow whenever the ERP is updated.