HubSpot + Syspro integration

Syspro runs the back office of a mid-sized manufacturer or distributor: the customer account with its credit limit and terms, the quote that converts into a sales order, the blanket order with its call-offs, and the stock in each warehouse. It also ships its own Contact Management module, which syncs contacts with Outlook and hands converted prospects to sales order processing. So the question is rarely whether Syspro can hold customer data, and usually which team works in which system.

Marketing and sales tend to live in HubSpot: campaigns, sequences, the pipeline and the forecast. Without a Syspro login they cannot see what Syspro knows about an account: the orders still open, the credit position, what it bought last quarter, and whether the item a prospect wants is on the shelf. The costly mistakes are small ones, such as a delivery date promised against stock already committed to another order.

The other direction hurts too. A won deal becomes an order that somebody keys into Syspro by hand, retyping the lines and copying the customer’s purchase order number out of an email. Syspro applies its credit policies and contract pricing during order processing, so a useful integration hands the order to that logic instead of working around it.

Four objects carry most of the value. Customers from the ArCustomer table become HubSpot companies. Stock codes from InvMaster become products, with quantity on hand per warehouse read through InvWarehouse. Sales orders arrive as deals in an orders pipeline that follows each order’s status, and contacts come from Contact Management where the site uses it.

Direction follows ownership. Syspro owns the customer, the price and the stock, so those move one way and stay read only in HubSpot. The single thing HubSpot writes is a new sales order from a won deal, and only after a person approves it.

Keys are the codes Syspro itself uses, never names. Companies key on the customer code, products on the stock code, deals on the Syspro order number. One trap catches multi-company sites: every OData request names a company in its URL, and each company is its own database. Codes can therefore repeat across companies, so the key carries the company as well, or one company’s customer overwrites another’s.

The read side is a polling watermark sync. A service calls Syspro OData over HTTPS with basic authentication, as an OData operator whose generated SQL login can read only the tables the integration needs. Each call returns at most 5,000 rows, so the service pages with $top and $skip, narrows each read with $filter on a date column where the table has one, and checks $count before trusting a result. It then batch upserts into HubSpot on the Syspro codes and runs associations as a separate pass. Watermarks, per company and per table, live in the service.

The write side is a queue. An approved won deal becomes one entry, and an order writer logs on to e.net Solutions through the REST binding of the e.net Communications Load Balancer and gets a session UserID back. It posts the order as SO SALES ORDER IMPORT XML, reads the messages that come back, logs off, and records the outcome on the deal. A reconciliation pass compares Syspro and HubSpot counts on every run.

What decides the route here is licensing and release, well before budget. OData needs the Data Connector - OData module and SYSPRO 8 2021 R2 or later. Posting orders needs the e.net functional area that holds the sales order business objects. Confirm both before scoping anything else.

With both in place, a custom API integration reads through OData and writes through e.net, and it keeps Syspro’s own logic in charge of every order it writes. The marketplace app from Commercient is a third-party alternative for a standard mapping, with its runtime and roadmap in Commercient’s hands. Managed sync on Skyvia could read the SQL tables of an on-premises site cheaply, but Syspro Cloud ERP forbids direct database access, and Syspro positions OData as the replacement for it.

1. Scope. We confirm the release, the OData licence, the e.net functional areas, the company databases and whether the site runs on premises or on Syspro Cloud ERP.
2. Architect. We fix the keys per company, the tables and columns each read uses, the paging and date windows, and the approval rule for orders.
3. Build. The service is written against a test company, with its own OData operator, its own e.net operator and a portal allowlist from the first commit.
4. Validate. We reconcile counts per table and open order values against a Syspro report, then post test orders to see the messages Syspro returns.
5. Operate. We watch run counts and the order queue, re-check table access after every Syspro upgrade, and keep replay and reconciliation endpoints ready.