SConnect by Martin & Associates

Available now

The Sage 100 API, over HTTP.

A REST API for Sage 100 that does not require your code to run anywhere near Sage. 47 readable entities across A/R, A/P, G/L, I/M, S/O and P/O, writes that survive a dropped connection, and an OpenAPI spec with a playground behind it. 

curl https://api.sage.sconnect.io/v2/records/AR_Customer/01-ABF \
  -H "Authorization: Bearer mk_live_..."

Read the docs Talk to us about access

Nothing opens in the customer’s firewall

There is no copy of the Sage database behind this API. A small Windows connector runs on the customer’s own Sage box and holds an outbound WebSocket to the cloud. Requests are dispatched down that connection and executed through the Sage business objects — the same ones the Sage UI uses. No inbound rule to request, no VPN to stand up.

  1. your code
  2. cloud API
  3. connector on the customer's Sage box
  4. Sage 100

What it does

Reads that do not always touch Sage

Single-record reads are read-through cached for ten minutes — X-Cache tells you which you got, and ?fresh=true forces a round trip when you need certainty. Pagination is keyset only: follow nextCursor until it is null. Document lines come back embedded with ?expand=lines, or read the detail tables directly when that is cheaper.

Writes that survive a dropped connector

Every create, update and delete is persisted as a job before dispatch. Most answer inline with 201; when a connector is offline you get 202 and a job id, and the queue drains when it reconnects. Idempotency-Key is honoured on every write, so a retry loop cannot double-post a sales order.

Callbacks, and files off the Sage box

Register a webhook once and stop polling — job results arrive signed with HMAC-SHA256. Separately, the connector watches drop folders on the Sage box and queues each file for your workers to claim and ack, which is the answer for the file-based integrations Sage shops still run.

Fields as your install actually has them

Record fields are the live column list resolved from Sage at runtime, including user-defined fields the customer added. There is no fixed schema per entity, because there is no schema that is right for every install.

The limits, before you find them

An ERP API has edges, and you will meet them in week two whatever a marketing page says. So here they are.

Your Sage license is the ceiling
Concurrency is the customer’s Sage user-license count, and it is often 2. Not a soft limit and not a tier you can upgrade here — it is how many Sage sessions they are licensed for. This is not an API to point fifty parallel workers at.
Sage is the only validator
Record bodies go to the business object untouched. Field errors are Sage’s own words, and nothing is written if any field or line fails — there are no partial documents.
The connector has to be online
If it is not, reads return 503 and writes queue as jobs. There is no cached-everything fallback, and you can check a connector’s state before starting something expensive.
Open documents read back only while unposted
Inventory transactions, both purchase-order receipts and cash receipts read in full, lines included — but only while they are still open. Once the register is updated in Sage the row leaves that table for history, which is a different entity and not one this API maps, so treat a read as “is this still in the batch” rather than a permanent lookup. Reading these four also depends on the connector’s Sage user holding rights to the matching maintenance task — if they error while everything else reads, that is what to check.
Batch documents are create-only
Invoices, inventory transactions and receipts enter a batch, but update and delete return 501 — the existing-batch select is not built. Posting through the API is not available either.

The docs carry the rest, including the ones that will irritate you — which status codes are safe to retry, and the one outcome you must never retry at all.

Questions people ask before the first call

Does Sage 100 have a REST API?
Not natively. Sage 100 exposes its data through the Business Object Interface — a COM library — and through ODBC, and both expect your code to be running on or beside the Sage server. This is a REST API in front of those same business objects, callable over HTTPS from anywhere.
Can it write to Sage 100, or only read?
Both. 47 entities are readable, and creates, updates and deletes go through the business objects rather than around them. Every write is persisted as a job before it is dispatched and honours Idempotency-Key, so a retry loop cannot double-post a sales order.
Do we have to open a firewall port or stand up a VPN?
No. The connector runs on the Sage box and dials out over a WebSocket, so the only connection is one your network already allows. There is no inbound rule to request and no port to explain to your security team.
Does it work with an on-premise Sage 100 install?
That is the case it is built for. Nothing is copied to the cloud and nothing about the Sage server changes — a small Windows connector runs alongside it and executes requests through the same business objects the Sage UI uses.
Does it return user-defined fields?
Yes. Record fields are the live column list resolved from Sage at runtime, so UDFs a customer added show up without anyone regenerating a schema. There is no fixed schema per entity, because no fixed schema is right for every install.
How is this different from reading Sage 100 over ODBC?
ODBC reads tables. This calls business objects, which means writes go through Sage’s own validation instead of around it, and a bad field comes back in Sage’s words. It also means there is no replica of the Sage database anywhere — the data is read from Sage when you ask for it.
How many concurrent requests can it handle?
As many Sage sessions as the customer is licensed for, which is often 2. That is a Sage licensing fact rather than a tier here, and it is the reason this is not an API to point fifty parallel workers at.
What does it cost?
Access is quoted per install, because it depends on the Sage environment and which entities you need — so it starts with a conversation rather than a card form. Talk to us.
Is this a Sage Software product?
No. It is not developed, endorsed or supported by Sage Software in any way. It is built and supported by Martin and Associates, a Sage partner that implements and integrates Sage 100.

Try it against the demo tenant

The reference has a playground on every endpoint, and there is a Bruno collection to download if you would rather drive it from your own machine. Neither needs a Sage install in front of you.

If what you are really looking for is somewhere for the resulting job to send its failure email, that is the Alerts API.

Read the docs Talk to us about access

Sage, Sage 100 and the Sage logo are trademarks of The Sage Group plc. This API is not developed, endorsed or supported by Sage Software. It is built and supported by Martin and Associates.