HubSpot + Passepartout integration

The situation we plan for is a parent company in Italy or San Marino that runs Mexal, and a sales subsidiary abroad that works in HubSpot. The parent posts orders, invoices and credit notes in Mexal, on a server of its own or in Passepartout’s hosted Live edition. The subsidiary’s sellers never see any of it, so they chase the office for order status and open balances, and quote accounts that finance is already worried about.

Passepartout sells Mexal only through its network of dealers, and it offers a CRM of its own for Mexal, with a pipeline, lead profiling and a shared agenda. So the question that reaches us is rarely which CRM to use. It is how to keep HubSpot, where the subsidiary already works, in step with the ERP the parent will not leave. That puts two parties in every project: the team that owns HubSpot, and the dealer who looks after the Mexal installation.

The documentation shapes the work as well. Passepartout’s public manuals are in Italian, and the full WebAPI manual sits in the developer area of its reserved portal rather than on the open web. We work from the public material, get the rest through the dealer, and write the mapping down in English for the team that will live with it.

Four objects carry the value. Mexal customer accounts become HubSpot companies, items become products, sales orders become deals, and invoices and credit notes land on a custom object associated to the company.

Keys come from Mexal, never from names. A customer keys on its Mexal account code, held in a custom HubSpot property, and an item on its item code. Sales documents need more care. Mexal issues quotes, orders, delivery notes and invoices as typed documents, keeps some archives per fiscal year, and a WebAPI request names its company and year in a header. A document key is therefore the document type and number scoped by company and year, never the number on its own.

The public material shows customer, item and document calls. The full list of resources on your installation comes from the WebAPI’s own HELP listing, and discovery settles whether invoices come through the WebAPI or, where it is licensed, from the MexalDB replica. Mexal owns the ledger and every document, so those stay read only in HubSpot. The one write back worth building first is a won deal creating the customer in Mexal.

The shape is a polling sync with a stored fingerprint per record. A service logs in as a dedicated WebAPI user, names the company and year it wants in Passepartout’s coordinates header, and pages through each resource using the next marker. Passepartout’s 2021 WebAPI training material sets a page at a hundred records, a size we confirm with the dealer. The public material documents no modified-since filter, so the service hashes every record it reads and compares the hash with the one it stored on the last run. Only changed records reach HubSpot, as batch upserts keyed on the Mexal codes, followed by a separate association pass.

State lives in the service: the last hash per record, the last good run per resource, and a replay endpoint that re-reads one resource on demand. On Live, calls go to Passepartout’s hosted WebAPI address and carry the cookie it requires there. On a local installation, they go to the address and port set in Mexal’s WebAPI configuration. Where the MexalDB replica runs, the same service can read SQL for the large collections and keep the WebAPI for the customer write back.

What decides the route here is where Mexal runs and which Passepartout modules the installation already licenses, not the object count.

A custom API integration over the WebAPI works everywhere, because the same calls answer on a local server and on Live. It is also the only route of the two Passepartout documents that can write, since MexalDB replicates Mexal’s archives outward.

Where Mexal runs on your own server with MexalDB, the replica turns Mexal into SQL tables that managed sync on Skyvia can read one way into HubSpot, with no service to host. What we steer away from is a general automation platform: the WebAPI’s own headers, the cookie on Live and paged reads make every flow expensive in steps.

1. Scope. The first call includes the Passepartout dealer. We confirm the Mexal version, local or Live, the companies and years in scope, and whether MDS and MexalDB are licensed.
2. Architect. We fix the keys, the year handling, the hash store and the customer write back, and write the mapping in English beside the Italian field names.
3. Build. The service is written against a test company on the dealer’s installation, with its own WebAPI user and 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 order totals against Mexal, company by company and year by year.
5. Operate. Cutover is a credential swap. We then watch the run history, keep the replay endpoint ready and re-check the mapping after each Mexal release.