nopCommerce Web API: Official Plugin, Alternatives and Custom Endpoints

This guide is for developers and technical leads connecting nopCommerce 4.90 or 5.00 to another system or building an app on top of it. It explains what the platform includes, how the official Web API works, what the alternatives are, and when to skip a general API and build exactly the endpoints you need.

What nopCommerce includes

Out of the box, nopCommerce has no public REST API. In both 4.90 and 5.00, the Web API Frontend entry in Configuration → Local plugins is a placeholder: installing it adds a page that describes the official Web API plugin and links to nopcommerce.com to get it. It doesn’t add any endpoints.

What the core does include is everything an integration plugin needs: services for every entity, an event system, scheduled tasks and the Excel and XML import and export in the admin area. That is why many integrations don’t use a REST API at all.

The official nopCommerce Web API plugin

The Web API plugin is sold by the nopCommerce team. According to its documentation it follows the OpenAPI 3.0 specification and has two parts:

Scroll the table sideways to see every column.

After installation, the Swagger UI at /api/index.html on your store lists every method, with a drop-down to switch between the frontend and backend definitions. By default only the Administrators role has the “Access Web API Backend” permission. Multi-factor authentication isn’t supported through the frontend API, so customers with two-factor sign-in need another way in.

Getting a token

Every call that isn’t anonymous needs a JWT token. Generate a secret key on the plugin’s configuration page first; the server signs and checks tokens with it. Then request a token with an API customer’s credentials:

POST /api-backend/Authenticate/GetToken
Content-Type: application/json-patch+json

{
  "username": "erp-sync",
  "email": "erp-sync@example.com",
  "password": "••••••••"
}

The response contains the customer ID and the token. Send it on later calls as Authorization: Bearer <token>. The frontend equivalent is /api-frontend/Authenticate/GetToken. The plugin also has a developer mode that switches token checks off for testing; it must stay off on a live store.

Other nopCommerce API plugins

Several vendors sell REST API plugins for nopCommerce, including nopAccelerate, nopAdvance and nopStation, and older open-source API plugins exist on GitHub. They differ in which methods they cover, how they authenticate and how quickly they support new nopCommerce versions. Before choosing one, check:

• It has a build for your exact nopCommerce version, and a history of updating soon after new releases.
• It covers the specific calls your integration needs, including paging and filtering for large lists.
• Its authentication fits your setup, and its tokens expire.
• Whether source code is included or sold separately, in case you need to fix or extend it.

An unmaintained open-source plugin written for an old version isn’t a shortcut: porting it is often more work than writing the few endpoints you need.

Custom endpoints in a plugin

When one system needs a handful of operations, such as “update stock and price for these SKUs” or “list orders placed since a time”, a small plugin with its own API controller is often the better design:

• A narrow contract. The other system sees only the fields it needs, in its own terms, such as SKU instead of product ID.
• Less to secure. A few endpoints with one API key or token instead of a thousand methods.
• Business rules in one place. The endpoint can validate, log and reject data before it reaches the catalog.

Whatever the endpoint does, it should go through nopCommerce’s services rather than writing to the database directly. The services clear the cache and raise events; direct SQL leaves stale prices on the storefront and other plugins unaware of the change.

Webhooks and events

nopCommerce has no webhook settings, but it raises events a plugin can consume: an order being placed, and any entity being inserted, updated or deleted, such as a product or customer. A plugin can listen for these and notify another system.

Which option to use

Scroll the table sideways to see every column.

For a mobile app or headless storefront, the official frontend API is usually the right start. For an ERP, decide first which system starts each transfer; that choice matters more than which API plugin you buy. When several systems, such as an ERP, PIM and warehouse system, share the same records, plan it as one of our enterprise commerce integrations, with data ownership and sync direction documented for each.

API security checklist

• Use a dedicated API customer account for each integration, with only the permissions it needs
• Keep the backend API off for frontend apps: mobile apps only need the frontend API
• Store the secret key and API passwords in the server’s configuration, never in a mobile app or a script in a repository
• Turn developer mode off on production; it disables token checks
• Allow backend calls only from the integration’s IP addresses where you can, and serve everything over HTTPS
• Log calls and failed sign-ins, and page through large lists instead of requesting everything at once

Frequently asked questions

Next steps

Tell us which system you want to connect, which side owns each kind of data, and how fresh it has to be. We will recommend the official API, a custom plugin or a mix, and build it with logging and retries.