Sage 300 and Cin7 integration

What moves between them

The main flows are bidirectional. Sage 300 purchase orders sync into Cin7 as incoming purchase records for inventory and cost tracking. Sage 300 inventory item masters sync to Cin7 so sales orders reference valid stock. Cin7 sales orders, sales payments, and receipts sync back into Sage 300, posting GL journal entries to cost centers and accounts, and updating Sage 300 inventory quantities. Cin7 chart of accounts is read-only, so account structures are validated but not modified. All sync happens on a schedule you control, typically aligned with order cycles or end-of-day operations.

How ml-connector handles it

ml-connector runs scheduled polls against both systems. On the Sage 300 side, it handles HTTP Basic Auth by encoding uppercase credentials per Sage 300 requirements, routes requests to your self-hosted IIS hostname, and filters transactions by date using OData $filter and pagination with $skip and $top to manage large result sets. It creates an API user if you provide admin credentials, or uses a pre-created user if you prefer. On the Cin7 side, it sets the required custom API key headers on each request and reads purchase and sales records. Before writing Sage 300 GL batches from Cin7 sales, ml-connector validates that GL accounts and cost centers exist in Sage 300 and maps them accordingly. For purchases flowing into Cin7, it validates that supplier and product records exist. IIS AppPool timeouts are mitigated by limiting concurrent requests. Every record carries a full audit trail, and if a Sage 300 POST or Cin7 API call fails, the job is retried with backoff on the next schedule cycle.

A real-world example

A mid-sized distributed manufacturing company runs Sage 300 on-premise for finance and inventory across three plants and a head office, and uses Cin7 Core in the cloud for order and inventory management across all locations. Before the integration, the operations team exported purchase orders from Sage 300 daily, manually keyed them into Cin7, then exported completed sales and receipts from Cin7 back into Sage 300 to post GL entries and update inventory. The cycle took three hours each morning and introduced data entry errors. With Sage 300 and Cin7 connected, purchase orders flow automatically from Sage 300 into Cin7 for fulfillment, and completed sales post back into Sage 300 GL and inventory with zero manual steps, freeing the operations team for higher-value work.

What you can do

• •Sync purchase orders and item masters from Sage 300 into Cin7 for order fulfillment and inventory management.
• •Sync Cin7 sales, sales payments, and receipts back into Sage 300 general ledger, allocated to the correct GL accounts and cost centers.
• •Keep Sage 300 inventory balances in sync with Cin7 receipts and completed sales.
• •Validate suppliers, products, and GL accounts exist in both systems before writing records, with full audit trails for every transaction.
• •Poll Sage 300 and Cin7 on your schedule with automatic retries and per-record error recovery if a downstream call fails.

Questions

How does ml-connector handle Sage 300 HTTP Basic Auth and the uppercase credential requirement?

ml-connector encodes your Sage 300 username and password as uppercase strings (as required by Sage 300), then base64-encodes them in the Authorization header on every request. You provide the self-hosted IIS hostname, and ml-connector routes all calls to your instance. If you do not have a pre-created API user, ml-connector can create one for you with admin credentials.

What direction do purchase orders and sales flow between Sage 300 and Cin7?

Purchase orders flow from Sage 300 into Cin7 for inventory and fulfillment tracking. Cin7 sales orders and receipts flow back into Sage 300, where they post GL entries and update inventory balances. Item masters sync from Sage 300 to Cin7 so sales and receipts reference valid stock.

How does ml-connector handle IIS AppPool timeouts and the lack of webhooks in Sage 300?

ml-connector polls Sage 300 on a schedule you control (e.g., hourly or daily) rather than relying on webhooks, which Sage 300 does not offer. It uses OData pagination and date filters to manage large result sets and limits concurrent requests to avoid triggering IIS AppPool timeouts from high load.