Search "nopCommerce API documentation" and you won't land on a single reference page the way you would with Stripe or Shopify. That's not a broken link on your end — it's a reflection of how nopCommerce is actually built, and it's the single biggest expectation mismatch we see when a team scopes its first integration.

This walkthrough covers both halves of the real picture: the internal plugin and service architecture that nopCommerce documents extensively, and the public REST API question that its own docs never quite answer. By the end you'll know exactly where to look, what you can realistically build, and when it's worth bringing in outside help.

Where nopCommerce's Documentation Actually Lives

nopCommerce's official documentation site and its open-source GitHub repository are organized around extending the platform from the inside — plugins, themes, and the service layer — rather than around a single public API reference.

The Three Places Developers Actually Look

None of these three sources alone is complete, but together they cover almost everything you'll need for a plugin-side integration.

The Internal API: Plugins, Services & Dependency Injection

This is the half of nopCommerce that's genuinely well documented, and it's worth understanding on its own terms before asking whether a public API exists.

We've walked through building one end-to-end in our full plugin development guide, but the short version matters here too: every nopCommerce plugin implements IPlugin and is wired into the same Autofac dependency-injection container the core platform uses.

Two Patterns Worth Knowing Before You Write Any Code

• The service layer (Nop.Services) — interfaces like IProductService and IOrderService are how the entire application, including the admin panel, reads and writes data. Anything you can do in the admin, a plugin (or a well-designed API layer) can do through these same interfaces.
• Event consumers (IConsumer) — nopCommerce publishes internal events (an order placed, a customer registered) that any plugin can subscribe to without touching core code, which is often a cleaner integration point than polling an endpoint you built yourself.

Figure 1: How nopCommerce's internal architecture maps against the external REST API gap.

Does nopCommerce Have a Public REST API?

Short answer: not out of the box. nopCommerce is architected as a server-rendered ASP.NET Core MVC application first — the admin panel and the storefront both run on the same MVC pipeline, not a decoupled backend consumed by a separate frontend.

That's a deliberate architectural choice, not an oversight. It's the same reason a platform like Shopify — built API-first from day one for a hosted, multi-tenant SaaS model — ships a public REST and GraphQL API, while a self-hosted, source-available .NET platform doesn't need to by default. We go deeper on that platform-level trade-off in our nopCommerce vs Shopify comparison.

The gap gets filled by the community instead. Several open-source API plugins exist that add REST endpoints for products, customers, and orders, typically secured with OAuth2 or JWT tokens. Before adopting one, vet it the same way you'd vet any other listing in the nopCommerce Marketplace — check maintenance activity, version compatibility, and how it handles authentication before it touches a production store.

Build vs. Buy: Comparing Your Options

Once you've accepted there's no default REST API, the real decision is which path gets you a reliable one fastest, without absorbing risk your team can't actually manage in-house.

A Practical Walkthrough: Exposing a Custom Endpoint

Here's the shape of the simplest realistic path: a small ASP.NET Core Web API controller, packaged inside its own nopCommerce plugin, that reads through the existing service layer instead of touching the database directly.

Registering it is no different from registering any other nopCommerce plugin — it plugs into the same dependency-injection container the storefront already uses.

[Route("api/custom/products")]
public class CustomProductApiController : Controller
{
    private readonly IProductService _productService;

    public CustomProductApiController(IProductService productService)
    {
        _productService = productService;
    }

    [HttpGet("{id}")]
    public async Task<IActionResult> GetProduct(int id)
    {
        var product = await _productService.GetProductByIdAsync(id);
        if (product == null || !product.Published)
            return NotFound();

        return Json(new
        {
            product.Id,
            product.Name,
            product.ShortDescription,
            product.Price
        });
    }
}

Integration Readiness Checklist

Run through this before your team — or ours — writes the first line of a custom endpoint.

Frequently Asked Questions

Final Thoughts

nopCommerce's documentation is genuinely strong once you understand what it's actually documenting: how to build inside the platform, not how to call it from outside. Knowing that distinction upfront saves weeks of misdirected research.

If your integration needs go beyond what a community plugin comfortably covers, that's exactly the kind of groundwork our team handles daily — reach out and we'll scope the shortest realistic path to a production-ready API.