Which direction does data move between Sage 100 and BambooHR?

The flow is BambooHR into Sage 100. Employees, departments, and job information move from BambooHR into Sage 100 to keep its cost-center segments and headcount data current. BambooHR holds no vendors, invoices, or GL accounts, and Sage 100's documented surfaces hold no employee master, so ml-connector treats BambooHR as the people source and does not write HR data back.

Why does Sage 100 need a local agent instead of a direct connection?

Sage 100 is on-premises and has no cloud API, and its full Business Object Interface is a COM layer that cannot be called over HTTP. A lightweight Windows agent on the customer's server wraps that interface and exposes an HTTPS endpoint that ml-connector calls. ml-connector authenticates to the agent with an API key or mutual TLS and supports the self-signed certificates these servers often use.

How does the integration handle BambooHR webhooks and the per-customer subdomain?

BambooHR webhooks are intentionally lightweight, signaling a change and listing only the changed fields, so ml-connector verifies the HMAC-SHA256 signature with a timing-safe comparison and then reads the full employee record. Because BambooHR scopes both its API and its OAuth token URLs to each customer's subdomain, ml-connector stores that subdomain per customer rather than assuming a single shared host. A scheduled poll backfills any change a webhook missed.

Sage 100BambooHR

Sage 100 and BambooHR integration

Sage 100 runs finance and operations on a server in your building. BambooHR is the cloud system of record for your people. Connecting the two keeps the org structure behind your ledger in step with HR without anyone re-keying it. New hires, terminations, and department or location changes in BambooHR flow into Sage 100 so its cost-center segments and headcount data stay current. ml-connector handles the very different access models on each side and moves the data on the cadence you set.

How Sage 100 works

Sage 100 is on-premises only and has no cloud API. Its full Business Object Interface, which covers AP vendors, GL accounts, purchase orders, and AR customers, runs as a COM layer on the Sage 100 server and cannot be called over HTTP directly. The standard path is a local Windows agent on the customer's server that wraps the Business Object Interface and exposes an HTTPS REST endpoint, authenticated with an API key or mutual TLS. The older SOAP eBusiness Web Services surface only covers Sales Orders and Customers, so it is not used here. Sage 100 has no webhooks, so records are read by polling the DateLastUpdated fields.

How BambooHR works

BambooHR is a cloud HRIS that exposes employees, job information, employment status, compensation, and time off through a REST API over HTTPS on a per-company subdomain such as acme.bamboohr.com. New apps authenticate with OAuth 2.0 authorization code, and the authorize and token URLs are themselves scoped to that subdomain rather than a single global host. Employee fields must be requested explicitly with a fields parameter, and tables like job information and compensation are dated history rather than single values. BambooHR also pushes employee.created, employee.updated, and employee.deleted webhooks signed with HMAC-SHA256, carrying only the changed field names so the integration then reads the full record.

What moves between them

The flow runs from BambooHR into Sage 100. ml-connector reads employees and their job information, including department, division, and location, from BambooHR, and uses that org structure to keep Sage 100 aligned so finance postings reference cost-center segments that match the current HR layout. Headcount and department data feeds Sage 100 for labor and dimension tagging. Department and location values are mapped to Sage 100 segmented GL account keys so each side agrees on the same cost centers. Because Sage 100's documented surfaces hold no employee master and BambooHR holds no vendors, invoices, or GL accounts, ml-connector treats BambooHR as the people source and Sage 100 as the finance target, and does not write HR data back into BambooHR.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the BambooHR side it runs the OAuth 2.0 authorization code flow against the customer's own subdomain, requests the offline_access scope so it can refresh unattended, and refreshes the one-hour access token before it expires. On the Sage 100 side it calls the local agent's HTTPS endpoint, since Sage 100 cannot be reached directly from the cloud, and accepts a self-signed certificate where the customer's server uses one. BambooHR employee webhooks signal that a record changed and list only the changed fields, so ml-connector then calls GET on that employee to pull the current values; a scheduled poll backfills anything a webhook missed. Department and location are mapped to the matching Sage 100 GL segment before any write. BambooHR throttling returns 503 with a Retry-After header, which ml-connector honors, and Sage 100 record locks are retried with backoff. Webhook signatures are verified with a timing-safe HMAC-SHA256 comparison, and every record carries a full audit trail and can be replayed.

A real-world example

A regional construction supplier with about 200 employees runs Sage 100 on a server in its main office for AP, GL, and job costing, and uses BambooHR for hiring, departments, and pay. When someone moved between the warehouse, the yard, and the office, HR updated BambooHR but the change never reached Sage 100, so labor and overhead landed on stale cost-center segments and the controller corrected the ledger by hand at month-end. With Sage 100 and BambooHR connected, a department change in BambooHR fires a webhook, ml-connector reads the updated job information, and the matching Sage 100 GL segment is aligned automatically. The controller now starts close with cost centers that already reflect who works where.

What you can do

Sync BambooHR employees and job information into Sage 100 so finance reflects the current org structure.
Map BambooHR departments, divisions, and locations to Sage 100 segmented GL cost centers.
React to BambooHR employee webhooks and read the full record, while polling Sage 100, which has no push events.
Bridge BambooHR OAuth 2.0 on a per-customer subdomain with the Sage 100 local agent login over HTTPS.
Keep Sage 100 headcount and department data current with retries and a full audit trail on every record.

Questions

Which direction does data move between Sage 100 and BambooHR?: The flow is BambooHR into Sage 100. Employees, departments, and job information move from BambooHR into Sage 100 to keep its cost-center segments and headcount data current. BambooHR holds no vendors, invoices, or GL accounts, and Sage 100's documented surfaces hold no employee master, so ml-connector treats BambooHR as the people source and does not write HR data back.
Why does Sage 100 need a local agent instead of a direct connection?: Sage 100 is on-premises and has no cloud API, and its full Business Object Interface is a COM layer that cannot be called over HTTP. A lightweight Windows agent on the customer's server wraps that interface and exposes an HTTPS endpoint that ml-connector calls. ml-connector authenticates to the agent with an API key or mutual TLS and supports the self-signed certificates these servers often use.
How does the integration handle BambooHR webhooks and the per-customer subdomain?: BambooHR webhooks are intentionally lightweight, signaling a change and listing only the changed fields, so ml-connector verifies the HMAC-SHA256 signature with a timing-safe comparison and then reads the full employee record. Because BambooHR scopes both its API and its OAuth token URLs to each customer's subdomain, ml-connector stores that subdomain per customer rather than assuming a single shared host. A scheduled poll backfills any change a webhook missed.

Connect Sage 100 and BambooHR

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started