Dynamics 365 Integration / Field notes
Use Retry-After to Pace F&O API Retries
When Finance & Operations returns HTTP 429 for a service protection limit, the Retry-After header gives the client a wait interval. A sound client respects that signal, limits additional work while waiting and makes the delay visible to operators.
Read 429 as a service protection response
Service protection limits help protect responsiveness and availability. A 429 response means the request should wait; sending the same workload faster can extend the wait interval and increase pressure on a shared environment.
Keep throttling separate from business validation. A 429 indicates a rate or resource condition; it does not explain whether the record values satisfy the receiving business process.
Use the server-provided wait interval
Microsoft's F&O retry guidance says the response includes Retry-After when a service protection API limit is reached. Use that interval before submitting again, and avoid a tight loop that discards the header. If the header is absent or unreadable, route the event through a bounded fallback policy and record that the expected guidance was unavailable.
Interactive screens should tell users that the service is busy and prevent repeated submissions while the earlier operation is still unresolved. Background workers can defer the item and continue with unrelated work.
- Parse Retry-After as a delay, not as permission to duplicate work
- Set a maximum attempt or elapsed-time boundary
- Keep the item visible while deferred
- Preserve the original business reference
Control concurrency and request shape
A retry header cannot compensate for an integration that repeatedly submits an unnecessarily large or bursty workload. Track throttles by environment, application identity, user identity and operation type. Smooth request rates and revisit the pattern if a synchronous API is being used for a workload better suited to batch processing.
Microsoft documents synchronous OData/custom-service patterns and asynchronous batch data APIs as different options. Choose based on required response timing, volume and processing behavior; the documented volume guidance is a rule of thumb rather than a system limit.
| Need | Candidate pattern | Operational check |
|---|---|---|
| Immediate result for an interactive action | Synchronous OData or custom service | Bound retries and user feedback |
| Large scheduled import/export | Batch data API / recurring integration | Poll job completion and inspect errors |
| Shared-data scenario across Dataverse and F&O | Evaluate dual-write where supported | Confirm maps, keys and company scope |
Measure recovery, not just request volume
A useful dashboard shows throttle counts, delay time, oldest queued item, retry outcome and unresolved business exceptions. A low request count is not success if work remains stuck or users have started to re-enter the same transaction manually.
Test a controlled 429 response in a representative environment and verify that the client waits, resumes once, preserves record identity and reports the final business outcome. Do not create artificial load against a production tenant as a test method.
Primary sources
Sources and further reading.
These platform references support the technical guidance. Available features, versions and implementation requirements should be checked against your environment.