web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Small and medium business | Business Central, N...
Suggested Answer

Best approach for exposing local Business Central APIs to Copilot Studio during development?

(2) ShareShare
ReportReport
Posted on by 4
Hi everyone,
 
I am currently developing an AI-powered inventory analysis solution using Dynamics 365 Business Central and Copilot Studio.
One challenge I encountered was exposing Business Central APIs running in a local Docker container so they could be consumed through a custom connector in Copilot Studio.
While researching different approaches, I found this Microsoft Learn documentation helpful:
 
https://learn.microsoft.com/connectors/custom-connectors?wt.mc_id=studentamb_621396
 
I experimented with:
- Custom Connectors
- Docker-hosted Business Central APIs
- Cloudflare Tunnel
- ngrok
- host.docker.internal
 
I would like to hear how others approach this scenario in development environments.
 
Do you typically:
- expose APIs through ngrok or Cloudflare Tunnel?
- deploy to a sandbox environment first?
- use another approach entirely?
 
Any recommendations, best practices, or lessons learned would be appreciated.
 
Thank you!
  • Subra Profile Picture
    2,478 Super User 2026 Season 2 on at

    Hi @CU04091158-0 

    Please move this question into correct forum. So that community members can help you on this.

  • Suggested answer
    ParthPatel249 Profile Picture
    220 on at

    Good breadth of options tried already. Here's how this is typically approached in practice, with tradeoffs for each:

    Short answer: tunnel for quick iteration, sandbox BC for anything beyond local dev

    1. ngrok/Cloudflare Tunnel, good for early iteration only Both work functionally for getting Copilot Studio's custom connector to reach your local Docker container, but treat this as throwaway dev-loop tooling, not something to build real testing confidence on:

    • Free-tier ngrok URLs rotate on restart, which breaks your custom connector's registered host every time you restart the tunnel, annoying if you're iterating frequently
    • Cloudflare Tunnel is generally more stable for this (named tunnels persist across restarts if configured), so if you're choosing between the two, lean Cloudflare for anything beyond a quick test
    • Neither reflects real network latency/auth behavior you'll see in production, so don't validate performance or OAuth flows this way, only functional request/response shape

    2. Sandbox BC environment, the better path once past initial prototyping Once your custom connector's request/response shapes are stable, move to a real Business Central sandbox environment (cloud-hosted, not Docker) as your dev target instead of tunneling to local:

    • Removes tunnel flakiness entirely from your dev loop
    • Lets you test actual BC API authentication (OAuth2/Azure AD app registration) exactly as it'll work in production, since local Docker BC often uses simplified/basic auth that doesn't match cloud BC's auth model
    • Custom connector registration against a stable HTTPS endpoint is what you'll ship anyway, so testing against it earlier surfaces auth/schema issues sooner

    3. Practical middle-ground some teams use: mock/stub layer If your Docker BC instance is mainly there for realistic sample data rather than testing actual BC business logic, consider standing up a lightweight mock API (Azure Function or simple Express/Flask app returning realistic JSON) that mirrors your BC API's OpenAPI schema. Point Copilot Studio's custom connector at that instead during early development. This decouples your Copilot Studio/connector development from Docker/tunnel stability entirely, letting you iterate on the AI/topic side without infrastructure flakiness, then swap to real BC endpoints once your connector schema is finalized.

    Recommended sequencing:

    1. Mock API or tunnel for initial connector schema/topic development (fast iteration)
    2. Move to BC sandbox once schema stabilizes (real auth, real data shape)
    3. Production BC endpoint for final validation before go-live

    This avoids the tunnel-stability problem entirely for the bulk of your development time, and gets your auth testing right earlier rather than discovering OAuth issues only when you finally point at a real BC environment.

     
     
  • Suggested answer
    YUN ZHU Profile Picture
    103,829 Super User 2026 Season 2 on at

    Due to various limitations with Docker and On-Premises environments, I now use the Partner Sandbox Early Access Preview version to test early features. Of course, this is not updated as early or as frequently as the Docker artifacts.

    For example,

    Thanks

    ZHU

  • Suggested answer
    OussamaSabbouh Profile Picture
    20,395 Super User 2026 Season 2 on at

    Hello,

    For development, I would prefer deploying the AL API to a Business Central online Sandbox and connect Copilot Studio using the standard Business Central Connector or MCP Server, because Microsoft’s documented Copilot Studio integration applies to Business Central online and supports custom API pages directly. If you specifically need to work against your local Docker BC instance, a custom connector + on-premises data gateway is the cleaner Microsoft-supported approach for a private API; Microsoft explicitly supports custom connectors to private network APIs through the gateway. I would use ngrok/Cloudflare Tunnel only for short-lived development/testing, not as the target architecture, because you are exposing the local BC endpoint publicly and must manage authentication, TLS, URL changes, and security yourself; host.docker.internal only helps communication between your local host and containers and cannot make the API reachable from cloud-hosted Copilot Studio. So my preference would be: local Docker for AL development → publish frequently to a BC Sandbox → test Copilot Studio there; use the gateway only when testing against the local instance is genuinely necessary. 

    Regards,
    Oussama Sabbouh

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Season of Sharing Community Challenge Winners!

Congratulations to our community stars!

Women in Power Builds Momentum

Expanding mentorship, skilling, and AI innovation

Leaderboard > Small and medium business | Business Central, NAV, RMS

#1
OussamaSabbouh Profile Picture

OussamaSabbouh 740 Super User 2026 Season 2

#2
YUN ZHU Profile Picture

YUN ZHU 531 Super User 2026 Season 2

#3
Grigorios Mavrogeorgis Profile Picture

Grigorios Mavrogeorgis 310 Super User 2026 Season 2

Last 30 days Overall leaderboard

Featured topics

Microsoft Training Manuals

Product updates

Dynamics 365 release plans