Business Central API integration developers: define a reliable scope

Define the business exchange in plain language

“Connect our portal to Business Central” leaves most of the important decisions unanswered. Start with the business event: a customer submits an order, a supplier updates a delivery date or a warehouse confirms dispatch. Describe the record created or changed and what the user expects to happen next.

State which system is authoritative for each piece of information. The portal may collect an address while Business Central owns the approved customer record. Decide how discrepancies are resolved and whether users can change information after the exchange. Without this ownership, both applications may overwrite each other’s decisions.

When requesting Business Central integration developers, provide two or three representative exchanges and their exceptions. A developer can then assess whether the job is primarily endpoint work, middleware development, mapping or troubleshooting. This produces a much clearer resource discussion than a list of product names without transaction context.

Evaluate standard APIs before extending the surface

Microsoft describes the Business Central API stack as the preferred integration approach and provides built-in APIs alongside custom API options. The practical task is to compare the required business operation with what the environment exposes. A standard endpoint may cover the need; another requirement may justify an additional interface.

Ask the developer to document the reason for each custom component. What information or behavior is missing? Could the process use an existing endpoint safely? How will the custom API be versioned and maintained? This decision should be reviewable by your technical owner.

Do not confuse access to a table with a complete transaction design. A business document has validation, state and relationships that the interface must respect. The developer should discuss the intended operation and resulting application behavior, rather than propose exposing every field simply because an external system might request it later.

Write mapping rules that both system owners understand

A mapping sheet should explain meaning, not only pair field names. Record source and target definitions, formats, mandatory values, transformations, defaults and validation rules. Identify the owner who can resolve each ambiguity. Dates, units, currency and identifiers deserve particular attention because apparently similar fields may represent different concepts.

Use a hypothetical order exchange to test the mapping. What happens when the customer is unknown, an item is blocked or the requested unit is not recognized? Decide whether the transaction is rejected, held for review or resolved through an approved mapping. Avoid silent defaults that hide a data problem.

Review the sheet with functional owners before coding. Business Central functional consultants can help translate posting and document requirements into a usable contract. The integration developer then implements an agreed rule rather than becoming the accidental decision-maker for pricing, customer identity or inventory policy.

Specify failure behavior before the happy path is finished

Failures are normal operating conditions for connected systems. A request can time out, a service can be unavailable or a business validation can reject the transaction. Define how the integration distinguishes these cases and what action is appropriate for each.

Duplicate prevention is especially important when the sender cannot tell whether the first attempt succeeded. Agree a business identifier and a method to recognize prior processing. The exact design depends on the systems involved, but the requirement should be explicit: retrying an uncertain request must not quietly create duplicate commercial activity.

Ask the developer to demonstrate a failed transaction, its diagnostic record and its recovery. Microsoft’s API troubleshooting documentation describes error information useful for investigation. Your operational design should connect that information to a support process, including who can correct data and authorize replay. A red error icon without ownership is not an adequate recovery strategy.

Use a scope table to expose hidden work

Integration estimates often omit responsibilities outside the endpoint itself. Authentication setup, external vendor coordination, representative data and support ownership can consume significant effort. Put these items in the scope before comparing resource proposals.

The table below makes several common deliverables concrete. Tailor it to your architecture and avoid assigning a developer accountability for an external platform they cannot access or control. Where multiple suppliers are involved, name one coordinator who can resolve cross-system issues. Otherwise, each party may demonstrate its own component while the end-to-end transaction remains unreliable.

Assess performance using the actual workload

A successful single request says little about the real operating pattern. Describe daily volumes, peak periods, payload sizes and acceptable delay. Identify whether the integration is transactional, scheduled or event-driven, and explain which business activities are affected when it falls behind.

Ask the developer to propose a realistic performance test and explain how the design behaves under backlogs. The goal is not an unsupported promise of instant synchronization. It is an agreed service expectation backed by evidence and a plan for handling demand beyond the normal pattern.

Separate the interface’s processing time from business completion. An external system may accept a message while further validation is still pending. Users need an accurate status, especially where a portal displays order progress. For portal-led work, coordinate with Power Pages integration specialists so the customer-facing message reflects the actual transaction state rather than only the initial HTTP response.

Choose a resource model that matches ownership

Hourly Model suits a focused API assessment, mapping review or investigation of a failing connection. Provide traces, sample payloads and a description of the expected result. Agree what can be diagnosed within the available access and what requires another system owner’s involvement.

Project Based is appropriate for a defined exchange with stable rules, known endpoints and explicit acceptance tests. Include operational documentation and recovery demonstrations. Clarify dependencies on third-party vendors, test environments and customer decisions so the scope does not depend on invisible assumptions.

Dedicated Resource suits an ongoing integration roadmap or a large backlog across several systems. The developer needs a technical owner, a prioritized backlog and access to functional decision-makers. For teams spanning India, North America and Europe, arrange overlap with the external platform owners as well as the Business Central team. Cross-system debugging often needs both parties available at the same time.

Test the support handover as part of acceptance

Give the support team a controlled failure scenario and ask them to use the documentation. Can they identify the affected transaction, find its last known status and determine the next authorized action? If they need the original developer for every step, the handover is incomplete.

The runbook should cover routine monitoring, credential ownership, known limits, common validation errors and escalation contacts. Keep secrets out of the document. Record how configuration changes are reviewed and how a future release of either application will be assessed for impact.

Agree reconciliation frequency with the business owner. High-impact transactions may need prompt exception visibility, while another exchange can tolerate a daily review. Document the reasoning and name the reviewer. A dependable integration is a combination of code, agreed operating rules and people who can interpret the evidence when something unexpected happens.

• Business events and authoritative records agreed by both owners.
• Mappings, failure categories and replay authority documented.
• Support runbook and reconciliation demonstrated before acceptance.