HubSpot + Panthera integration

Panthera is the ERP Sisthema builds for Italian industry. Its site describes thirty years of experience in industrial sectors behind it, production planning with MPS and MRP, and editions for tiles, textiles and jewellery, and six of the nine sectors it lists are manufacturing industries. It is written in Java, runs entirely in a browser, and is sold both on premises and as Panthera SaaS.

A manufacturer on Panthera that sells abroad through a HubSpot team meets a familiar gap. Quotes, orders and invoices live in Panthera, while the people selling to new accounts work in a CRM that cannot see them. Panthera has CRM and marketing functions of its own, including a module for sales agents, so connecting HubSpot makes sense when the sales and marketing team already runs on it and the ERP should feed it rather than replace it.

The facts an integration needs sit behind a login. Sisthema publicly lists a Web Services connector for Panthera, beside EDI and bulk loading, but documents Panthera only to its registered customers, through a library of module guides and technical documentation in the reserved area of the Panthera site. Nothing public says which protocol the connector speaks or how it authenticates, so this page assumes neither. A HubSpot project starts by getting those guides into discovery, because the public pages say what the connectors are, not how they are called.

Four objects carry the value. Customers become HubSpot companies, customer quotes become deals, and sales orders and invoices land on custom objects associated to the company. That split keeps the pipeline in HubSpot honest: a deal follows the quote, and the order that results sits beside it rather than inside it.

Keys come from Panthera, never from names. A customer keys on its Panthera code, held in a custom HubSpot property. Quotes, orders and invoices key on their document numbers scoped by company and year, so that numbering which restarts for a new year or a second company can never merge two documents.

Everything moves one way in a first build. Panthera owns the customer, the price and every document, so HubSpot shows them read only. A write back, such as a won deal creating a customer in Panthera, waits until the Web Services documentation confirms how writes are made and validated.

The expected shape is a polling sync over the Web Services connector, pending Sisthema’s documentation. A service calls the connector on a schedule, reads customers, quotes, orders and invoices changed since its last run where the connector allows a change filter, and upserts them into HubSpot as batches keyed on Panthera’s codes, followed by a separate association pass. Where the connector has no change filter, the service compares each record with a fingerprint it stored on the last run, so only real changes reach HubSpot.

State lives in the service: the last good run per object and a replay endpoint that re-reads one object on demand. On Panthera SaaS the connector is the only route, because the Panthera site’s explanation of SaaS rules out direct database access for the customer’s staff. On an installation you host, the service runs where it can reach the Panthera server.

What decides the route here is the Web Services documentation. Until it is read, nobody can say which protocol the connector uses, how it authenticates, which objects it exposes or whether it can filter by change date.

The deployment matters as well. On Panthera SaaS the connector is the only way in, because the customer’s staff get no direct access to the database, and on an installation you host, discovery settles where a service can run to reach the Panthera server.

Once the guides are read, a service we build is the route we would take on either deployment, and it can carry a write back later if the connector accepts writes. The HubSpot App Marketplace has no Panthera app to try first: the one result for the name is a generic ERP connector from another developer.

1. Scope. The first call covers the Panthera version, SaaS or on premises, and access to the reserved area’s Web Services guides.
2. Architect. We fix the objects, the keys, the change detection and the direction of each object, then write the mapping in English.
3. Build. The service is written against a test company, with a HubSpot portal allowlist in place from the first commit.
4. Validate. We reload every object into a HubSpot sandbox and reconcile counts and open quote totals against Panthera.
5. Operate. We watch the run history, keep the replay endpoint ready and re-check the mapping after each Panthera cumulative release.