An integration can provide useful operational visibility before it can change anything. That boundary deserves a product decision of its own.
In a portfolio case, I describe a prepared marketplace ERP integration that exposes catalog and order reads through a protected proxy. The public case records the read-first design and credential boundaries. It does not provide a validated operational baseline or establish that a future write phase has been completed.
The interesting question is what a read-only phase lets the team learn while the authority to mutate business records remains closed.
Separate context from authority
An internal agent may need to know whether a product exists, which attributes are recorded, or how an order is represented. None of those needs automatically requires permission to create products, change stock, or edit prices.
Giving an agent a broadly privileged credential makes that distinction depend on every caller behaving correctly. A narrower proxy can express the intended boundary directly.
The documented pattern keeps OAuth credentials inside the automation layer and exposes a protected lookup surface to internal scripts or agents. Secrets and private endpoints are not part of the public case.
This remains an integration design, not a guarantee that all read access is harmless. Product and order data can still be sensitive. Authorization, data minimization, and access review belong in the read phase too.
Make the boundary observable
A useful read-first phase should establish which fields are available and how reliably they represent the operational source.
An entirely invented example illustrates the distinction. A lookup returns a product description that differs from an internal planning note. The integration can present both references for review. It should not infer that the planning note authorizes updating the source catalog.
That disagreement is valuable evidence. It reveals a data-contract question before an automated write would make it harder to untangle.
The first checks should include refusal of unauthenticated requests, success of an authorized read, and rejection of unsupported operations. A successful happy-path lookup alone would not demonstrate that the permission boundary holds.
Avoid designing a universal proxy
A proxy that forwards arbitrary paths and methods can recreate the original broad API surface under another name.
For a bounded integration, I would expose named operations with explicit request validation and constrained response fields. Catalog lookup and order visibility need their own contracts. Internal callers should not have to understand the upstream credential or receive fields unrelated to their task.
Errors also need interpretation. An unavailable source, an unauthorized request, and an item that does not exist are different states. Treating all of them as an empty result can make an agent invent an operational explanation.
These are design recommendations for the next review, not a claim that this public writeup contains a released production proxy.
Treat writes as a separate capability
Enabling writes changes the failure cost. A mistaken read may mislead a reviewer; a mistaken stock update can alter downstream work.
Before enabling a write phase, I would name the allowed mutation, its owner, preconditions, expected effect, and recovery procedure. Idempotency and readback become essential because a retry must not create another effect and a successful request does not necessarily prove the intended final state.
A review checklist for that transition is:
- What concrete task requires a write?
- Can its scope be narrower than the upstream API?
- Which source version or precondition must still hold?
- How will retries avoid duplicate effects?
- What readback will confirm the resulting state?
- Who can stop, reverse, or investigate an incorrect mutation?
No write-phase outcome, speed improvement, or prevented-error count is claimed here. Those require separate evidence.
The read-only ERP integration case describes the prepared boundary. Which information would let your users make progress before you grant the system authority to change it?
Top comments (0)