HubSpot + iRely integration

Many businesses running iRely’s i21 trade with the same people in both directions. A grain elevator buys a producer’s crop on a purchase contract, then sells that producer feed, seed or fuel on account. The i21 data model allows for it: one entity record can carry customer and vendor flags at once, with its contacts, locations, credit terms and salesperson attached. The commercial history is complete, and very little of it reaches the people doing outreach.

What those people ask for is specific. Marketing wants to segment producers by line of business without asking the office for an export. Originators want open contracts on the company record before they call. Sellers want the receivables balance and the credit hold flag before they promise a delivery. Each of those fields is documented in the i21 REST API, on entities, customers, contracts and invoices. The work is carrying them across, not finding them.

i21 also has its own CRM, with leads, opportunities, campaigns and logged calls. That makes the first scoping decision one of ownership. i21 stays the book of record for contracts, scale tickets, orders and invoices whichever way it goes. HubSpot takes marketing and the web forms, and it takes the pipeline only if the business decides the i21 opportunity list should stop being the one people update.

Six objects carry what sellers and marketers ask for. Customers become HubSpot companies and entity contacts become contacts. Commodity contracts, sales orders and invoices land as custom objects on the company. Opportunities become deals only where the i21 CRM keeps running the pipeline.

Every row keys on the id the API documents as unique, never on a name. Customers key on the entity id, which invoices and contracts reference too, so their associations resolve without a lookup. The customer number is what sellers recognize, so it rides along as a label rather than a key. A contract carries the entity id of its customer or vendor, so a producer’s contracts land on one company whichever side of the trade they sit.

Everything moves one way on the first build. The customer, entity and opportunity resources are read only in the API, so HubSpot cannot create an i21 customer or turn a closed deal into an i21 opportunity. The API does accept new quotes, sales orders and activities. A won deal raising a draft quote for the office to review is the write-back worth scoping second.

The pattern is a polling watermark sync, because the public i21 reference documents no webhooks. A service logs in with an API username, a password and a company code, and holds the bearer token it receives. It renews that token with the refresh token rather than logging in again.

Each resource then reads on its own schedule. Customers accept dateFrom and dateTo on their last update, and contracts, sales orders and opportunities carry a dateLastUpdated field the dynamic filter can compare. Entity contacts and invoices document no such date, so the service re-reads them and compares a hash of each row with the last one it sent.

Deletions come from the timestamp endpoints. Given the ids the service already holds, they return created, updated and deleted dates, and deletedRecordsOnly narrows the answer to deletions. Writes into HubSpot are batch upserts on the i21 ids, then a separate association pass. A watermark per resource lives in the service, so a restart resumes instead of reloading.

The question that decides the route for i21 is how much of the contract book HubSpot has to be trusted with. For one narrow flow, such as new customers into a marketing list, an iPaaS with a generic HTTP step can call the i21 API and prove the value quickly.

That flow gets fragile once six resources need their own watermarks, deletions need a sweep and the token needs refreshing mid run. A custom API integration keeps that state in one place, replays a resource on request and reports its counts after every run. The HubSpot App Marketplace offers no third route, since nothing there is published for iRely or i21 by HubSpot or by iRely. The choice is between a quick automation that proves the value and a keyed service a sales team can forecast from.

1. Scope. We confirm API access and its permissions with iRely, settle which system owns the pipeline, and list the fields sellers actually use.
2. Architect. Entity id as the company key, a watermark per resource, a timestamp sweep for deletions, and full re-reads for contacts and open invoices.
3. Build. Whether iRely offers a test company for the API is not public, so we ask during discovery. The first build only reads from i21, and it writes to a HubSpot sandbox portal behind an allowlist that fails closed.
4. Validate. A full backfill, counts per resource compared with i21, and the unmatched sales orders walked through with the office.
5. Operate. We watch counts and 4xx responses on every run, keep a replay endpoint per resource, and recheck the mapping when the i21 changelog records a new version.