Calling an External API From a Dynamics 365 Plug-in When the Sandbox Blocks You

What does the plug-in sandbox actually allow when calling an external API?

In Dynamics 365 and Dataverse online, every custom plug-in runs in sandbox isolation. It is not a setting you can switch off for an online environment, so the design has to fit inside it. The rules below are the ones that trip developers up most often; Microsoft revises the details, so confirm them in the current Dataverse documentation on plug-in isolation and accessing external web resources before relying on any single figure.

• Set an explicit, short timeout on the HTTP client rather than relying on the default, so a slow API fails fast inside the execution limit.
• Avoid keep-alive connections to external hosts from plug-ins, which Microsoft lists as a plug-in best practice, and create the HTTP client in a way that does not exhaust connections under load.
• Never hard-code credentials. Use environment variables, including secret types backed by Azure Key Vault, secure step configuration, or managed identity for plug-ins where it is available to your tenant.
• Log the call outcome, with a correlation identifier, through the tracing service; how to make those traces useful in production is covered in our guide to plug-in logging and diagnostics.

When is a short synchronous call from a plug-in the right choice?

Only when the save genuinely depends on the answer and nothing is written to the other system. Typical examples are validating an address or a tax number before a record is saved, or reading a reference value the user must see before the transaction completes. In those cases the call is a read, a failure can safely block or warn the user, and nothing has to be undone if the save later rolls back.

Keep it short and predictable: one call, a timeout of a few seconds, no retries inside the plug-in, and a clear error message or a deliberate fallback when the API is down. If the business cannot accept saves failing whenever the API is unavailable, the call does not belong in the transaction at all.

The call that must never be synchronous is the one that writes: creating an order, a shipment or an invoice in another system from inside the save. If the external call succeeds and the Dataverse transaction then rolls back because a later step fails, the other system has an order Dynamics 365 does not. If the call times out after the other system accepted it, you do not know whether to resend. Both are how orders go missing or appear twice.

Asynchronous step, webhook, service endpoint or outbox: which pattern fits?

Once the call leaves the transaction, there are four supported ways to get the data out. They differ mainly in where the code runs, what happens when the external API is down, and whether a failure is visible to anyone.

• The outbox is the default because it is the only pattern where "the record was saved" and "a message must be sent" are committed together. If the save rolls back, the outbox row rolls back with it.
• The worker sends through one adapter per external API, upserts on a business key or sends an idempotency key, and marks the row sent only after the API confirms.
• The outbox table design, retry with backoff, circuit breaking, Service Bus peek-lock and idempotent consumers are set out in our guide to rationalising point-to-point integrations and are not repeated here.
• If the integration actually needs external systems to read Dynamics 365 data on demand, rather than Dynamics pushing to them, that is a different design, covered in our guide to exposing Dynamics 365 data through an API gateway.

Orders were lost when the plug-in call failed silently: how do you recover them?

Silent loss usually has one of three shapes. The plug-in caught the exception and carried on, so the save succeeded and the order was never sent. An asynchronous step or webhook failed and sat in System Jobs where nobody looked. Or the call succeeded and the save then rolled back, leaving an order in the other system that Dynamics 365 does not have. Recover in this order, and do not resend anything until step four.

• Step 1, make new orders recoverable now: add a status column such as "sent to external system", set only after a confirmed response, or start writing outbox rows, so the loss stops growing while you recover the backlog.
• Step 2, define the failure window: find the first failure from plug-in trace logs, failed System Jobs, Application Insights or the external API logs, and take the window from a little before it to now.
• Step 3, compare both systems by business key: export orders created or changed in the window from Dataverse and from the external system, and list the orders missing on each side. Missing externally means lost; present externally but not in Dataverse means a rolled-back save.
• Step 4, check idempotency before resending: confirm the external API upserts on the order number or accepts an idempotency key, or check existence per order first, so a replay cannot create duplicates.
• Step 5, replay in a controlled batch: send a small batch through the new outbox or worker, check it in the external system, then send the rest, logging each order and response.
• Step 6, reconcile and close: rerun the comparison until both sides match, resolve orphaned external orders with the business, tell anyone affected, and move the integration permanently to the outbox pattern with alerts on failures and on silence.

How do you stop a plug-in integration failing silently again?

Make every failure visible to a person who owns it, and make every success provable. That is design rather than tooling, and most of it can be added to an existing integration without rewriting it.

• Never swallow an exception from an external call inside a plug-in. Either fail the operation deliberately or hand the work to an outbox that records the failure.
• Alert on failed system jobs for the integration steps, and on silence: no orders sent in a period when orders were created.
• Reconcile daily by business key between Dynamics 365 and the external system, with an owner for every difference.
• Keep secrets and endpoints in environment variables with expiry tracking, so a rotated key does not quietly stop the integration.
• Give each integration a business owner who knows what a day of failure costs, and a technical owner who can fix it.

Who should build and rescue a plug-in integration like this?

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

Production integration rescue is senior development work: reading trace logs and system jobs under pressure, reconciling two systems by key, replaying safely and then moving the integration onto a pattern that cannot lose data. Our senior consultants and full-stack developers, with 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery, write C# plug-ins, custom APIs, Azure Functions and Service Bus consumers, and can join your team as described on our Dynamics 365 developer page. We work on the Dynamics 365 side and the integration layer; we integrate with ERP and order systems rather than implementing them.