Integrating a customer portal with an ERP means agreeing which system owns the business record, which changes customers may request, and how the portal represents work that is still processing. Treat those decisions as part of the product specification, not just an API task.
This guide is for a product or operations lead planning a portal alongside an existing business system. It does not assume a particular ERP vendor or that every required operation is available through an API.
Separate viewing information from changing it
A portal that displays orders has different requirements from one that creates or changes them. List each operation separately and verify that the ERP supports it through an approved interface.
| Customer action | Ownership question | Failure to plan for |
|---|---|---|
| View an order | Which source provides the current status? | The portal shows an old value without indicating its age |
| Submit a request | Does this create a draft or a confirmed business record? | The user sees confirmation before the ERP accepts it |
| Change an address | Who validates the change and where is it stored? | The portal and ERP overwrite each other’s updates |
| Cancel an order | Which business states still permit cancellation? | A queued cancellation arrives after fulfillment starts |
These are hypothetical examples. The actual operations depend on your business rules and the interfaces your system exposes.
Decide what the portal is allowed to promise
Distinguish “request received” from “change completed.” If an internal approval or background transfer is still pending, tell the customer what remains to happen. Define whether they can edit or withdraw the request during that period.
For displayed information, agree an acceptable age. A document archive and an available-to-promise stock figure do not necessarily need the same update policy. Specify what appears when the source is unavailable and how staff can identify stale records.
Trace an uncertain result
Consider a request that reaches the ERP but whose response is lost. Blindly repeating the operation could create a second business action. The implementation needs a way to determine whether the intended action already happened before retrying it.
Ask the system owner what identifiers, lookup operations, or duplicate-handling features are available. Where the interface cannot support reliable automatic recovery, define a manual reconciliation path and make the uncertainty visible. The API integration checklist provides a broader review of retries and partial updates.
Assign ownership of correction
Create a recovery note for each important transfer: how a failure is detected, where an operator sees it, what information they need, and who is permitted to retry or correct the record. Avoid a design in which only a developer with database access can resolve everyday exceptions.
Keep a record of the original request and subsequent decisions appropriate to the application’s requirements. Agree retention and access with the people responsible for the data rather than assuming that every payload should be stored indefinitely.
What to bring to the scoping conversation
Provide the ERP’s actual interface documentation, a list of required operations, sample records with sensitive information removed, and the business owner for each workflow. Mark licensing, permissions, and vendor approval as open dependencies when they are not confirmed.
Start with a single journey and its recovery procedure. That gives the engineering team something concrete to investigate and gives your stakeholders a clearer basis for an estimate.
Put it into practice.
Explore our customer portal development service or send us the problem you are working on.