REST API Integration Gateway

The problem

Almost every Dynamics 365 Finance & Operations programme ends up building the same plumbing three or four times. The first integration is a bespoke class that calls a partner API. The second copies it and changes the URL. By the fourth, there are four different retry behaviours, four different ways of storing an API key, four different logs, and no single place to answer the question "did the sales order from the web shop actually land, and if not, why?"

Meanwhile the platform's own limits start to bite. OData and the Data management framework are throttled by priority tier; a burst of calls returns 429 with a Retry-After header, and code that ignores it makes the throttling worse. Long-running imports need the DMF package API and its job status polling, not a synchronous call. Batch data API endpoints behave differently from row-by-row entity writes. None of that is hard, but it is easy to get subtly wrong, and each project relearns it.

What ECOSIRE builds

A single integration gateway inside F&O, delivered as an X++ extension model with no overlayering, that every inbound and outbound interface routes through. It is built to order around the specific systems you need to connect, and the reusable core comes with it.

Endpoint registry

A setup form registers each external system: base URL, authentication method (OAuth 2.0 client credentials, bearer token, API key header, or mutual TLS), timeout, concurrency ceiling, retry policy, and the legal entities it serves. Secrets are referenced by handle from a store your administrators control, never held in a transactional table. Adding an endpoint is configuration; only a genuinely new payload shape needs code.

Outbound calls

A gateway service class issues REST calls with correlation IDs, structured request and response logging, configurable header sets, and a circuit breaker that stops hammering an endpoint that is already failing. Retries use bounded exponential backoff with jitter and honour a Retry-After header when the remote system sends one. Idempotency keys are supported so a retried POST does not create a duplicate record downstream.

Inbound calls

Inbound traffic can arrive three ways, and the gateway covers all three consistently. Custom services written in X++ and exposed through the service registration framework handle operations that do not map to an entity — a pricing enquiry, a multi-step posting, a status check. Data entities and OData handle standard record CRUD. The DMF package API handles bulk file-based loads, with the gateway polling execution status and translating DMF staging errors into readable failures rather than a job ID and silence.

Mapping

A mapping layer translates between external payloads and F&O structures: field-to-field mapping, value translation tables (their status codes to your enums), default values, required-field validation, and legal entity resolution so a message carrying a company code lands in the right DataAreaId. Financial dimensions are handled explicitly, mapping incoming dimension values onto your ledger dimension structure instead of leaving them blank. Mappings are data, so a changed field name does not require a redeployment.

Queue, throttling and replay

Messages land in a durable staging table with a status lifecycle. A batch framework job drains the queue at a configured rate, which is what keeps you inside the platform's priority-based throttling limits instead of discovering them at month end. Failed messages hold their payload, their error, and their attempt count, and can be corrected and replayed individually or in bulk from the monitoring workspace. Nothing is silently discarded.

Monitoring

An operations workspace shows message volumes by endpoint and status, failures needing attention, average round-trip time, queue depth and circuit-breaker state. Each message can be opened to see the exact request and response, redacted for secrets, with its correlation ID. Alerts can be raised on failure thresholds. Where you already use Application Insights, the gateway can emit its telemetry there as well.

Power Platform and Dual-write

Where the right answer is not a custom call, we say so. If a scenario is better served by Dual-write to Dataverse or by a Power Automate flow against the F&O connector, the gateway registry records that route and the mapping and monitoring stay in one place rather than splitting your integration estate across tools nobody can see at once.

Who this is for

Organizations with three or more systems talking to F&O — an e-commerce platform, a WMS, a CRM, a payment processor, a freight provider — and no consistent integration layer. Also fits teams whose existing integrations work but are unsupportable: no logging, no retry, and a failure mode of a missing record that nobody notices for a week.

How delivery works

1. Scoping call. We list the systems in scope, the direction and trigger of each interface, expected volumes and peak windows, the entities and services involved, and the authentication each remote system uses. We ask for their API documentation. 2. Fixed quote. A written scope naming the gateway core plus each interface, with a fixed price and a delivery window. Typical lead time is two to four weeks from approved scope, depending on how many interfaces are in the first release. 3. Build. Developed in our F&O development environment against your target platform and application version, with checkpoints as interfaces come online. 4. Install in test. The deployable package goes into your sandbox via LCS. Endpoints are configured against the remote systems' test environments and we run the interfaces end to end with your team, including deliberate failure and replay tests. 5. Production. The same package is promoted through your release pipeline, production credentials are configured by your administrators, and we watch the first live cycles. 6. Support. A defect-correction warranty window after go-live, with optional ongoing support for new interfaces and platform updates.

What this is not

It is not middleware hosted by us, and no data passes through ECOSIRE infrastructure. It runs inside your F&O environment, calls your endpoints, and uses your credentials. It is not available for instant download — the core is reusable, but each build is scoped to the systems you are actually integrating.