How to Build Custom APIs in Business Central: Key Insights and Practical Tips

Working with Dynamics 365 Business Central, I’ve often found that the out-of-the-box (OOB) APIs don’t fully meet real-world integration needs. Whether it’s missing fields, unsupported entities, or the need for custom logic, many scenarios require more flexibility.

At Nearsure, we frequently help clients extend Business Central’s standard capabilities through custom APIs—addressing gaps in OOB functionalities and enabling seamless integrations with their ecosystems.

At Directions North America 2025 in April, I shared practical strategies for extending Business Central using custom APIs. In this blog post, I’ll walk you through what they are, how to build them, and how to use them effectively.

What are Business Central custom APIs?

Custom APIs in Business Central are REST-based endpoints that allow you to expose data from custom or extended tables or implement custom business logic, following Microsoft’s API architecture and conventions.

Think of it this way: while standard OOB APIs cover core entities like customers, vendors, and sales orders, custom APIs let you define exactly what data and behavior you want to expose externally. You do this through special API pages (PageType = API) and bound actions to trigger server-side logic when needed.

In simple terms, custom APIs are your way to "open the box" to securely and efficiently offer the API your integration scenarios need.

When to use custom APIs

Here are the most common scenarios we see at Nearsure:

• The OOB API doesn't expose the fields or tables you need.
• You've created or extended a table and need external access to it.
• You want to trigger custom logic from external systems via bound actions.
• You need more control over your API’s behavior, security, and evolution.

Common limitations of OOB APIs

Standard APIs have restrictions.

• You can't extend existing API pages with new fields.
• Custom tables require you to explicitly expose them via new API pages.
• Sometimes you need a more optimized or lightweight API than the generic OOB endpoints.

Setting up your development environment

A clean and well-prepared development environment is the foundation of building reliable APIs in Business Central.

Before you start coding, it’s essential to configure the tools, permissions, and test environment that will let you develop, test, and validate your APIs efficiently without impacting production data.

Prerequisites:

To build and test custom APIs, make sure you have:

• Azure Active Directory App Registration (for OAuth2 authentication)
• Application or delegated permissions configured in Azure
• A dedicated Business Central sandbox environment for development and testing

Tools I use:

These are the tools I typically rely on when developing custom APIs:

• Azure Portal: For app registration and managing permissions
• Visual Studio Code: With the AL Language extension for Business Central development
• Postman: for testing REST API calls
• Business Central Admin Center: to create and manage sandboxes

Once your environment is ready and your tools are installed, you're set to start creating your first API page. Let’s walk through that next.

How to create a custom API in Business Central

Now that your development environment is ready, let’s build your first custom API!

The good news is that creating a custom API in Business Central is straightforward once you understand the building blocks of AL tables, API pages, and optional bound actions.

By following these steps, you’ll create a REST-compliant API that external systems can easily consume using the same patterns as Microsoft’s standard APIs.

Here’s a step-by-step example.

1. Define the table (optional)

If you need to expose custom tables, you need to create them first:

‍
2. Create an API page

Now you define how this data will be exposed via REST. The API page serves as your contract with the external world:

‍Key points to remember:

• PageType = API is mandatory—don’t use other page types
• APIPublisher, APIGroup, and APIVersion define your API namespace
• EntityName and EntitySetName define the REST endpoint names

3. Add bound actions (optional)

If you need to expose server-side logic (to post a document, trigger workflow, etc.), you can define bound actions:

‍Bound actions support HTTP POST requests and allow external apps to trigger custom behavior.

4. Use the API endpoint

Once published, your custom API is automatically available via the standard Business Central API URL format:

‍‍5. Test with Postman

After authenticating using OAuth2, you can use Postman (or any REST client) to:

• Retrieve data (GET)
• Create records (POST)
• Update records (PATCH)
• Delete records (DELETE)

Pro tip: Always test edge cases (empty fields, special characters, date ranges). This helps avoid surprises when you move to production.

Once your basic API is working, you can start adding features like filtering, sorting, pagination, and versioning, which we’ll cover in the next sections.

Best practices for performance and security

When building custom APIs, performance and security should always be top priorities—especially if your APIs will be exposed to public or partner systems.

At Nearsure, we always prioritize performance and security when designing APIs, especially when they will be exposed to public or third-party systems.

Here are some key best practices:

• Use $select and $filter query parameters to limit the data returned—avoid over-fetching unnecessary fields or records.
• Take into account Business Central API rate limits and use batching or pagination for large data sets.
• Although you cannot use SUPER permission set for API access, always use the least-privilege approach when setting access.
• Sanitize and validate all inputs; never assume external systems will send “clean” data.
• Implement API versioning from day one to ensure backward compatibility as your API evolves.

Real-world use cases

At Nearsure, we regularly observe recurring scenarios where custom APIs in Business Central can unlock smarter integrations and more agile business processes. While every organization has its nuances, the following examples reflect common needs we’ve seen across industries.

E-commerce integration

One of the most common scenarios we observe is the integration between Business Central and e-commerce platforms. Organizations often need to expose product catalogs, dynamic pricing, and real-time inventory levels to their online storefronts. Custom APIs provide the flexibility to tailor this data exposure, enabling seamless synchronization between the ERP and digital sales channels while reducing the reliance on manual updates or third-party connectors.

Power Platform automation

Another frequent use case involves the Power Platform, where businesses look to trigger automated workflows or processes based on events in Business Central. By exposing specific entities or actions via custom APIs, it's possible to integrate Business Central with Power Automate or Power Apps, enabling low-code solutions that streamline operations, improve responsiveness, and reduce the need for custom development.

Mobile sales apps

We also see growing interest in supporting mobile sales teams with real-time access to business data. Field representatives often require lightweight, fast, and focused tools to retrieve customer information, check product availability, or register new orders. Custom APIs enable the development of mobile-friendly applications that connect directly to Business Central, providing the necessary data in an efficient and reliable format.

EDI with logistics partners

In logistics and supply chain operations, custom APIs are often considered to automate data exchange with external partners, such as third-party logistics providers. These APIs can facilitate the transmission of purchase orders, shipping confirmations, and inventory updates, improving communication and reducing manual intervention. By structuring this integration through custom endpoints, organizations can achieve better accuracy, faster turnaround times, and increased scalability in their fulfillment processes.

Expert tips from the field

Here are a few additional tips I always share with new API developers:

• Review the OOB API pages to see how they are built and use the same approach for your custom API pages.
• In some cases, you can use the OOB source code and add or modify what you need for your custom API. Remember that you cannot extend an API page, but you can copy the OOB source code and adapt it to your needs.
• Don’t forget to set the PageType = API.
• Define unique EntityName and EntitySetName values to avoid conflicts and confusion.
• Keep business logic minimal in the API layer. The API should be about exposing data and simple actions, not complex workflows.
• Test thoroughly in a sandbox before going live, covering both success and failure scenarios.
• Monitor API usage in production and review API telemetry for insights and optimization opportunities.

Conclusion

Custom APIs are one of the most powerful ways to extend Business Central’s capabilities. They open the door to real innovation by enabling modern, scalable integrations with internal apps, partner systems, and external platforms.‍

Building great APIs goes beyond just writing code. It’s about thoughtful design, solid performance, robust security, and long-term maintainability. If you’d like to explore this further, you can download the full slide deck from my Directions North America 2025 session.

If you want to accelerate your API projects or need expert guidance, consider partnering with Nearsure. Our team of seasoned Business Central developers and integration specialists can help you design and deliver enterprise-grade APIs that are tailored to your business and ready to scale.