Custom services and OData endpoints in F&O

Dynamics 365 Finance and Supply Chain integrates with external systems through several API surfaces. Two are particularly important for custom integration work: custom services (developer-built X++ services that expose specific operations) and OData endpoints (automatic REST endpoints generated from data entities). Knowing which to use for which scenario matters.

OData endpoints from data entities.

Every data entity in F&O — and most standard entities ship with the platform — is automatically exposed as an OData v4 endpoint:

https://<environment>.dynamics.com/data/Customers
https://<environment>.dynamics.com/data/SalesOrderHeaders
https://<environment>.dynamics.com/data/PurchInvoiceLines

Standard OData semantics apply — $filter, $select, $expand, $orderby, $top, $skip, with full CRUD operations via GET / POST / PATCH / DELETE.

Strengths:

• Zero developer work beyond enabling entities — generated automatically.
• Standard OData — broad tool support.
• Documented — the OData metadata is queryable.
• Versioned — data entities have versions; new versions add fields without breaking old consumers.

Weaknesses:

• CRUD-focused — fine for "create a sales order", less natural for "run a specific business operation".
• Side-effect operations are awkward — confirming an order, posting a journal, releasing a production order don't map cleanly to PATCH semantics.
• Performance — large bulk operations through OData are slower than equivalent custom services.

Custom services.

A custom service in F&O is a developer-built X++ service that exposes specific operations. The pattern:

1. Define a service contract — a class with [DataContract]-marked methods defining the operation's inputs.
2. Define a service implementation — the X++ class that executes the logic.
3. Define a service group — a deployment unit grouping related services.
4. Deploy the service group — F&O exposes the services at endpoint URLs.

The result: operations like PostSalesInvoice, ReleaseProductionOrder, CalculateCustomerBalance can be called from external systems as HTTP / SOAP / OData-style endpoints. Inputs are typed; outputs are typed; F&O handles authentication, serialisation, and error responses.

Strengths:

• Tailored to business operations — natural for action-oriented integrations.
• Encapsulation — internal logic is wrapped; external callers don't need to understand the internal data model.
• Performance — direct X++ execution; can be optimised for specific scenarios.
• Atomic transactions — multi-step operations run inside a single F&O transaction.

Weaknesses:

• Developer effort — must be written in X++ and deployed.
• Versioning discipline — service contracts evolve; consumers must adapt.
• Less discoverable than OData metadata.

Choosing.

• Read-heavy or simple CRUD → OData endpoints from data entities.
• Business-operation invocation (post, release, approve, calculate) → custom services.
• High-volume bulk operations → custom services with batch input.
• Reporting and analytics extraction → OData (or better: data lake / Synapse Link).

Authentication. Both surfaces authenticate via Microsoft Entra ID OAuth 2.0 — typically service-principal authentication for system-to-system calls. The same Entra app registration grants access to both OData and custom services.

Throttling. F&O API call limits apply to both:

• Priority-based throttling — non-priority calls slow down or queue when the tenant approaches limits.
• Burst limits — short-term spike capacity beyond sustained rates.
• Per-user limits — when calls are made as a specific user identity.

Heavy integration traffic should respect throttling — implement exponential backoff on 429 responses.

Operational considerations.

• Logging — both surfaces emit telemetry through Application Insights. Configure tracing for debugging.
• Versioning — data entities have built-in versioning; custom services need manual version management (often through deployment of new service variants alongside the old).
• Documentation — for custom services, maintain external API documentation; OData has self-describing metadata.

Modern alternatives for analytics workloads. For analytics consumption — extracting F&O data for reporting, BI, data warehousing — Synapse Link for F&O is the modern path. It streams F&O changes to OneLake near-real-time; consumers query OneLake instead of hitting F&O's API. Vastly more efficient for analytics; preserves F&O's interactive performance for operational users.

Common pitfalls.

• OData polling for change detection — chatty, throttling-prone. Use Synapse Link or business events instead.
• Custom services without versioning strategy — breaking changes cascade to consumers.
• No throttling handling on consumers — integration randomly fails under load.

Operational reality. Mature integrations use both: OData for entity access, custom services for business operations, Synapse Link for analytics. Each tool for its job.