How to Integrate with the Sage 50 API (US Edition)

Sage 50 US has no web API. Integrating with it means running code on a Windows machine where Sage 50 is installed, through a 32-bit .NET SDK that ships inside the product. Sage's own knowledge base puts it plainly: "This is a .NET SDK. A PHP SDK isn't currently available." Everything else in a Sage 50 API integration follows from that.

Sage 50 US is the desktop accounting product US small businesses knew as Peachtree until Sage renamed it in 2013. It comes in three editions, Pro, Premium and Quantum, from one user up to 40, and the current release is 2026.1 from July 2026. Sage only supports the current version: support for 2024 ended on 4 March 2026, and customers on an unsupported release stop getting program updates and lose Sage add-on services such as bank feeds and payroll eFiling. Expect customers to be on the current release, and test against it.

Sage 50 is a different product in every country

Before you scope anything, confirm which Sage 50 your customer runs. The name covers separate products, most of them acquired by Sage in different countries, each with its own integration technology. A Sage moderator on the Sage Developer Community put it this way: the SDK you need "is determined by which regional version of Sage 50 you wish to integrate with."

In Canada, Sage 50 is the former Simply Accounting, with its own SDK and its own version numbers, already at 2027.0. In the UK and Ireland, Sage 50 Accounts integrates through Sage Data Objects, a COM library sold through a paid developer programme, and Sage's UK FAQ states that "there currently is no RESTful API for Sage 50." In France, Germany and Spain, Sage 50 descends from Ciel, a separate German product line and ContaPlus, and Sage's developer portal lists none of them.

So a "Sage 50 integration" is really several integrations. Sage 50 US is the one described below; each of the others gets its own guide in this series, and our posts on untangling the Sage ecosystem and the Sage integration map cover how the brand got this way.

The Sage 50 API is a .NET SDK

The integration surface is the Sage 50 .NET API, documented in Sage's .NET API quick start guide (version 2026.0). The assembly, Sage.Peachtree.API, is installed with Sage 50 itself and registered in the Global Assembly Cache. The SDK download from the SDK portal adds documentation, samples and a help file that describes every class. Your application has to target .NET Framework 4.8 and compile as 32-bit; the guide documents no .NET Core or modern .NET path.

Every connection starts with a PeachtreeSession and an application ID. Sage issues one unique ID per third-party application on request to sdk.50us@sage.com. Without one, Begin("") still works, but only against Sage's sample companies such as Bellwether Garden Supply, which is enough to build against.

The connection sequence, using the names from the quick start guide:

using Sage.Peachtree.API;

var session = new PeachtreeSession();
session.Begin(applicationId); // "" connects to sample companies only

CompanyIdentifierList companies = session.CompanyList();
CompanyIdentifier companyId = companies.Find(c => c.CompanyName == targetCompanyName);

if (companyId != null)
{
    AuthorizationResult access = session.VerifyAccess(companyId);
    if (access != AuthorizationResult.Granted)
        access = session.RequestAccess(companyId); // Pending until a Sage 50 user approves

    if (access == AuthorizationResult.Granted)
    {
        Company company = session.Open(companyId);
        // read and write through the company object
    }
}

RequestAccess returns Pending the first time. The app gets access only after a Sage 50 user opens that company in Sage 50 and approves the prompt. The other values of AuthorizationResult tell you why a connection didn't go through: Denied, CompanyLocked (the company is in single-user mode, so try again later), LoginRestricted, NoCredentials and CorruptedOrTampered. None is only the initial value. The guide adds two preconditions. A company must have been opened in Sage 50 at least once before your application can connect, and Sage 50 itself does not need to be running.

Permissions on the customer's side

Approval is only one of three settings that decide whether your app can connect. Under Options, Global, the Sage Partners tab sets a security level: Low lets all partner applications run, Medium (the default) warns first, and High blocks them. In User Security, the SDK Data Access area should be set to Full, because with No Access "you will not be able to run Sage Partner applications." Add these to your onboarding checklist, since a customer who tightened security years ago will see your app fail without an obvious reason.

Once approved, the app sees everything. The quick start guide says it directly: "There is no security model. If your application has access to a Sage 50 company, it will have access to all available areas of that company." Treat the approval as full access in your security review.

Reading and writing data

The guide points to the help file in the SDK for the full object model. It names sales and purchase invoices, receipts, payments, quotes, sales orders and contacts in its list of known issues, and that list is worth reading before you promise write-back to a customer.

In release 2026.0, cash-basis companies cannot create, edit or delete sales or purchase invoices, or receipts and payments applied to invoices. The same goes for transactions involving serialized inventory or retainage jobs. Transactions with units of measure can't be edited or deleted. Sales invoices created through the SDK generate no Audit Trail entries, which matters to accountants who rely on that trail. There is no List method for contacts. And an application "can only access one company at a time," so a customer with several companies means sequential sessions.

Check each customer's accounting method during onboarding. A cash-basis customer can still use a read-only integration, but write-back of invoices and payments is off the table.

Running it: an agent on the customer's machine

The SDK runs only where Sage 50 is installed, so a cloud product needs a component on the customer's side: a Windows service on the machine or server that holds the Sage 50 data, which opens a session, reads or writes, and syncs with your backend. A Sage team member on the Sage community forum warned that creating a session, opening the company and closing it again "might be rather lengthy for a normal web request/response cycle" and suggested background processing. Design the agent to sync on a schedule, with no live calls from your web app.

The agent has to live with Sage 50's file locking. Backups, restores, closing the fiscal year, posting and purging take an exclusive lock on the company, and they fail if anyone else has the company open, which will likely include your agent's session. Close sessions promptly, retry on CompanyLocked, and expect a restored backup to roll data back under your sync.

Two other routes exist. Sage documents ODBC access for reporting, but it is read-only and does not work with 64-bit programs. CSV import and export is built into Sage 50 and fails if the file's fields don't exactly match the order and number Sage 50 expects. CSV import and export is a manual step a user runs in Sage 50. ODBC can be automated, but only for reads, and it needs a separate data-access password set up in Sage 50, so neither replaces the SDK for a two-way sync.

Sage 50 Cloud changes the picture

"Sage 50 Cloud" now means Sage hosts the desktop application for the customer on Microsoft Azure. For integrations that matters a lot: Sage lists seven third-party apps that work with Sage 50 Cloud, and anything else starts as a request to Sage's product team. Don't assume your agent can run next to a Sage-hosted company until Sage has enabled your app there. Ask every prospect whether they run Sage 50 on their own machines or on Sage 50 Cloud before you quote.

Yearly releases and testing

Sage ships a major release roughly once a year, plus updates, and the year in the name is not the release year: Sage published the 2026.0 release notes in October 2025, there was no 2025 release, and 2026.1 followed in July 2026. The API assembly ships inside each release, and opening a company on a new release triggers a data conversion. Sage's release notes tell customers to check with third-party vendors that their product "is fully compatible with this release." The quick start guide lists no API changes from 2024.0 to 2026.0, but plan to test each release before your customers upgrade.

Sage offers the SDK for free, though Sage staff on the community forum say access can require a Sage ID tied to a Sage 50 licence or a partner application. Support from Sage's SDK team comes with a Sage 50 development partner plan. The quick start guide lists Gold and Silver tiers that include not-for-resale software for testing and five or one SDK support incidents. To join, apply as a Sage partner and choose ISV and Sage 50. Recompiling your application requires the customer's admin to authorize it again, according to Sage staff on the community forum, so treat every release of your agent as a customer-facing event.

Building it yourself or waiting for the connector

If Sage 50 US is the only accounting system your customers use, the path above is workable: an application ID, a Windows agent, a sync loop that tolerates locks and yearly upgrades. If Sage 50 US is one of several systems on your list, the agent, its upgrades and its support load repeat for every desktop product you add, and the best practices for API integrations only cover the part that runs in the cloud.

Apideck's Sage 50 US connector is in development. It will sit behind the same Accounting API that already connects QuickBooks Desktop and dozens of cloud ledgers through one normalized REST API. If Sage 50 US is on your roadmap, tell us on the connector page and start building against the Accounting API for the systems it already supports.