Sage 50 US .NET API: getting an Application ID, and the .NET Core trap

Last checked 15 September 2026. Every claim on this page links to the Sage page it came from.

The Sage 50 U.S. Edition SDK is a real, free, ungated .NET library — but almost nothing about it is written down in one place, and two things stop most people before they write a line of working code: getting an Application ID, and discovering the API will not run on modern .NET. This page covers both.

1. What the SDK actually is

It is a .NET assembly that talks to a locally installed copy of Sage 50 US. It is not a cloud API, and there is no hosted endpoint. Your code, the SDK and Sage 50 itself all run on the same Windows machine.

The namespaces you will work in are Sage.Peachtree.API and Sage.Peachtree.Domain — Peachtree being what Sage 50 US was called before the rename. Sessions start with:

Sage.Peachtree.API.PeachtreeSession.Begin(applicationIdentifier)

Sage's knowledgebase is explicit that this is the only language binding: "This is a .NET SDK. A PHP SDK isn't currently available."

Source: Sage KB 220924550010687 — How to access the Software Development Kit

2. How to get the SDK

There are two separate things people conflate, and conflating them is why the forum has years of stuck threads:

• The SDK download itself — available from Sage's SDK download portal. You need to sign in with a Sage ID attached to an account holding a Sage 50 US licence.
• The Application ID — a separate string Sage issues you, which PeachtreeSession.Begin() takes as its argument. Without it you can open the sample company and nothing else.

You request one by emailing sdk.50us@sage.com, the address given in the Sage 50 .NET API — Quick Start Guide that ships with the SDK installer. Note that a separate Sage knowledgebase article points applicants at the Developing Partner form; the community answer above is the more recent and more specific of the two, but if email goes unanswered the partner form is the documented fallback.

3. The .NET Core trap

This is the one that costs people a day. The SDK targets .NET Framework and will not run on .NET Core or modern .NET, because it depends on System.Windows.Forms internally — even if your own application has no user interface at all.

The failure looks like this:

System.IO.FileNotFoundException: Could not load file or assembly
'System.Windows.Forms, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'

   at Sage.Peachtree.Domain.GlobalContextExternal.GetDBNServer()
   at Sage.Peachtree.Domain.GlobalContextExternal.PreOpen()
   at Sage.SBD.ACS.Framework.BusinessLogic.ContextBase.OpenTemplateMethod(...)
   at Sage.Peachtree.API.GlobalContext.Open()
   at Sage.Peachtree.API.PeachtreeSession.Begin(String applicationIdentifier)

If you see that stack, nothing is wrong with your code — you are on the wrong runtime. Target .NET Framework, and if the rest of your system is modern .NET, put the Sage-facing part behind a small Framework process and talk to it over a local channel.

Source: Sage Community Hub — ".NET Core Compatibility with Sage 50 US SDK/API"

4. What this means if you are planning an integration

• It is Windows-only and machine-local. Anything you build has to run where Sage 50 runs, which usually means a small always-on agent on the customer's machine or server.
• It is per-installation. There is no tenant model — you are connecting to one company file at a time on one machine.
• Regional editions are not interchangeable. The US, UK and Canadian versions of Sage 50 are different products with different integration paths. Code and connectors written for one will not work against another.
• Start the Application ID request early. It is free, but it is a human step with a turnaround, and it blocks all work against real company data.

Further reading: the Sage 50 US SDK forum is the only active place these questions get answered.