The decision
Identify the exact ERP product, deployment, company scope and customization model first. Prove one representative workflow in the customer’s environment before estimating the rest of the integration.
Name the actual product and environment
“Microsoft Dynamics” is not a precise API target. Establish whether the customer uses Business Central or a different Dynamics application, and whether it is cloud or on-premises. Record the environment, company selection and permissions needed for the workflow.
Do the same for NetSuite: identify the account, role and records involved. A successful login proves access to an environment, not authorization for every subsidiary, custom record or action your product needs.
Choose the API surface deliberately
NetSuite SuiteTalk REST exposes record operations, metadata and query capabilities. Business Central documents standard REST APIs and custom API development; its documentation says adding fields to an existing standard API requires a custom API rather than simply extending it. These differences affect discovery and maintenance.
Separate common fields from customer customization
Create a mapping document that shows source entity, company context, external ID, required fields and ownership. Mark each custom field explicitly. For an order workflow, check customer identity, item identity, units, tax treatment, dimensions and status transitions before designing a single generic payload.
Preserve the distinction between absent, empty and unavailable fields. If a role cannot see a field, do not silently replace it with a default that changes the business meaning. Agree with the customer on how incomplete records are handled.
Treat a customer rollout as a migration
Start with a limited read and compare it with the ERP UI. For writes, use a test environment and an agreed sample transaction. Define a rollback or correction procedure before enabling scheduled production jobs.
The acceptance record should include the exact product, environment, role, customization assumptions and tested operation. Re-run it when those assumptions change. Track API-version and customization changes independently from your application releases so support can distinguish a code regression from a changed ERP configuration.
Your next step
Use these checks in a bounded proof of integration.
- Identify product, environment, company scope and role.
- Inventory standard and custom fields.
- Validate a realistic read/write workflow in a test environment.
- Agree on reconciliation, correction and rollout ownership.
Profiles to inspect: QuickBooks · Xero · NetSuite
Sources and editorial scope
Product statements refer to the publisher sources below, reviewed on 2026-10-21. The decision criteria and checklists are API Tracker’s editorial analysis. They are not compatibility certifications or benchmark results. API Tracker is built by Apideck.
Suggest a correction →