Does Microsoft Dynamics GP have a REST API?

Yes. Microsoft Dynamics GP has shipped a REST API since GP 2015, called Service Based Architecture, or SBA, and it is still in the current release, GP 18.8, today. The catch is that SBA runs inside your network, authenticates against your Windows domain one user at a time, and its object list stopped growing in 2015. It cannot read or write general ledger journal entries, sales orders, or purchase orders. If you need those, or you need to reach GP from anything that lives outside the customer's LAN, SBA on its own will not get you there. That gap is what ERPSpan exists to close.

Last updated: July 18, 2026.

So the honest version of the "does GP have an API" question is not yes or no. GP has an API. It is just a narrow, local one that Microsoft built and then stopped extending. Most teams who go looking find SBA, try to point a cloud app at it, hit the wall, and conclude GP is a black box. It is not. You just need something in front of it.

Four ways to get data in and out of GP

The table is the whole argument in miniature. Everything below is why each row reads the way it does.

What SBA actually gives you, and where it stops

SBA is a real REST service. Microsoft added it so developers could hit GP over HTTP instead of writing Dexterity or eConnect code, and for simple lookups on the local network it works fine. If your integration lives on the same domain as GP and only touches customers, vendors, and items, SBA can carry it.

The problems show up the moment your requirements get slightly more ambitious.

It is LAN scoped. SBA runs on the customer's own IIS and authorizes each caller as a Windows or GP user with access to a specific company. There is no Microsoft hosted public endpoint you can point a cloud app at with one key. To reach it from outside you are into VPNs, reverse proxies, and firewall exceptions, which is exactly the kind of thing a customer's IT team does not want to sign off on.

Its object list is frozen. SBA's coverage was set at the GP 2015 RTM feature line and never moved. There is no endpoint for general ledger journal entries, none for sales order processing, none for purchase order processing. For a lot of real integrations, those three are the entire point. An AP automation tool that cannot post to the GL is not an AP automation tool.

It runs on a limited process pool. SBA uses Dexterity processes on the session host server, capped by default at 30 concurrent processes, and each process handles one request at a time. When SBA and the GP Web Client run on the same server, heavy SBA traffic competes with Web Client users for that server's memory and CPU. Push it hard and you can slow down the people trying to do their jobs.

And Microsoft has stepped back from it. There is no published OpenAPI description and no steady stream of new objects. GP itself is in a long wind down: Microsoft has announced end of support, with mainstream support running to the end of 2029 and security updates to April 2031, and it is steering customers toward Dynamics 365 Business Central. Plenty of companies will keep running GP well inside that window, but Microsoft is not going to improve SBA, so the gaps you see today are the gaps you will still have in 2029. You can read the object list and setup on Microsoft's Service Based Architecture documentation. The short read: SBA works, but it is finished, not evolving.

None of that makes SBA useless. It makes it a floor, not a ceiling.

The real problem is not reachability, it is credentials

Reachability is the symptom people notice first, but it is not the thing that actually sinks GP integration projects. Credentials are.

Picture a customer with three GP companies and a handful of integrations. With the local tools, each integration needs its own path in: a Windows service account, the right SQL permissions, a spot in the domain, and separate configuration for each company and sometimes each object. You end up managing a grid of endpoints times certificates times Active Directory identities, and every one of them is a thing that expires, gets rotated, or breaks when someone reorganizes the domain. Multiply that across every customer you onboard and the integration is no longer software, it is a standing IT project.

ERPSpan collapses that grid to a single row. One API key. One connection id that points at a specific GP install. One company header when you want to switch between companies. The customer installs a small agent once, and after that your app talks to a normal REST endpoint the way it would talk to Stripe or Twilio. That collapse, from a credential matrix to one key, is the part that actually saves the weeks.

What ERPSpan is

ERPSpan is a REST and MCP API for Microsoft Dynamics GP, backed by a lightweight agent that the customer runs next to their GP database.

You call https://api.erpspan.com with a bearer key and a connection id, plus an optional company header to pick a GP company, and you get canonical JSON back. Reads are parameterized and paginated. Writes go through the same clean surface. You do not touch Dexterity, you do not learn eConnect's XML, and you do not host anything yourself. The object reference lists what you can hit, and authentication covers the header model.

The MCP part matters more than it looks. ERPSpan also speaks the Model Context Protocol, so an AI agent, including Claude, can query and update GP directly through the MCP server without a human writing glue code for every question. "What did we invoice this vendor last quarter" becomes a tool call, not a two week reporting ticket.

Why the agent only makes outbound connections

The agent that sits next to GP never accepts inbound connections. It dials out to ERPSpan and holds the link open, which means the customer opens zero ports and pokes zero holes in their firewall. From a security review's point of view that is the difference between a quick yes and a long maybe. There is no public listener on the GP network, nothing new exposed to the internet, and the customer can see and cut the connection whenever they want.

This is the quiet reason integrations that stall on the local tools tend to clear ERPSpan's review fast. You are not asking IT to trust a new inbound path. You are asking them to allow an outbound one, which they already allow for a hundred other things.

The objects you can actually read and write

This is where the frozen SBA list stops mattering. ERPSpan covers more than 20 GP objects, and it includes the ones the built in API skips. Customers, vendors, and items, yes, but also general ledger entries, AR invoices and payments, AP invoices and payments, sales orders, purchase orders, checkbooks, fiscal periods, and the reference data around them.

If your product posts journal entries, syncs open receivables, or pushes purchase orders into GP, those are first class here rather than something you have to reach around the API to reach. The full, current list lives in the docs, and it is generated from the same definitions the API serves, so it does not drift from what actually works.

What it costs, and how that compares

ERPSpan is 99 dollars per connection per month, with a sandbox that is free forever so you can see it return real GP rows before you pay anything.

For context, not as a takedown of anyone: the integration platforms that connect to GP, like eOne's SmartConnect, are capable tools, but they are priced and shaped like platforms, with monthly fees that climb into the four figures once you add connections, and they are built for scheduled mapping jobs more than for an app making live API calls. Unified accounting API vendors will give you a clean cloud endpoint, but their GP coverage tends to be shallow, so the objects you most need are often the ones they did not map. And a DIY build on eConnect and web services can do anything, in the sense that you will be doing all of it, usually for the tens of thousands of dollars it costs to build and then keep maintaining.

The point of the comparison is not that the others are bad. It is that they cluster at the extremes, either heavy platforms or shallow endpoints or a blank editor, and the specific gap ERPSpan fills is a full coverage cloud API for GP that a developer can wire up the same day.

When ERPSpan is the wrong choice

It is worth being straight about this. If your integration lives entirely on the customer's LAN, only touches customers and items, and will never need to run from the cloud, SBA is free and already installed, so use it. If you are a GP hosting provider who already owns the servers, the certificates, and the domain, you may be better off wrapping SBA yourself than paying per connection. And if you genuinely need a batch mapping tool with a visual designer for non developers, an integration platform is a better fit than an API.

ERPSpan is for the case in the middle, which happens to be the common one: a modern app, running somewhere other than the GP box, that needs reliable read and write access across the whole GP data model without turning every customer onboarding into a domain project.

FAQ

Does Dynamics GP have a built in API?

Yes. GP includes Service Based Architecture, a REST API, from GP 2015 through the current GP 18.8. It handles basic lookups over HTTP on the local network. Its limits are that it is LAN scoped, tied to Windows domain auth, and its object list has not grown since 2015, so it excludes GL journal entries, sales orders, and purchase orders.

Can I reach Dynamics GP data from the cloud?

Not with SBA alone, because it only listens on the customer's own network and authenticates against their Windows domain. To reach GP from a cloud app you either build and host your own bridge, or you use a service like ERPSpan, which runs a small outbound only agent next to GP and exposes a normal bearer authenticated REST endpoint you can call from anywhere.

Can I post GL journal entries through an API?

Not through SBA, which never added a general ledger journal entry endpoint. This is one of the most common reasons teams outgrow the built in API. ERPSpan does expose GL entries, along with AR and AP invoices and payments, sales orders, and purchase orders, so accounting and AP automation tools can post where they actually need to.

Do I have to open firewall ports to use ERPSpan?

No. The agent that sits next to GP only makes outbound connections to ERPSpan and keeps that link open. The customer opens no inbound ports and exposes no public listener on the GP network. For most security reviews that is the difference between a fast approval and a stalled one.

How is this different from an integration platform like SmartConnect?

Integration platforms are built for scheduled mapping jobs configured in a visual designer, and they are priced as platforms. ERPSpan is an API. You make live REST or MCP calls from your own application and get canonical JSON back, with full object coverage including the GL. If you want a batch tool for non developers, a platform fits better. If you are building software, an API fits better.

Can AI agents query Dynamics GP through ERPSpan?

Yes. ERPSpan speaks the Model Context Protocol, so an AI agent such as Claude can read and write GP through the MCP server as tool calls, without a developer hand coding an integration for every question. This is what turns a reporting request into something an assistant can answer directly against live GP data.

How long does it take to connect?

Same day. The customer installs the outbound agent once, you get a key and a connection id, and you are making authenticated calls against real GP data. You can try the whole path against a free sandbox first, so the first rows you see are real before any commitment.

Published by ERPSpan. ERPSpan is a REST and MCP API for Microsoft Dynamics GP that lets your app read and write the full GP data model over one endpoint and one key. Start on the free sandbox in the docs.