Define what the destination can prove
An adapter translates a bounded task into destination-specific reads and writes. Its contract should describe how to resolve a workspace, locate reference records, map fields, authorize an action and confirm the effect. The adapter also needs to explain where the destination offers weak guarantees, such as eventual consistency or a write endpoint without idempotency support.
ERP.AI provides the initial architectural reference through its record and workflow interfaces. For any destination, integration review needs to establish the supported operations, required credentials, field mappings and recovery behavior. A familiar API shape does not remove the need to test the complete business operation against that system.
Resolve access on the server
A caller-supplied table identifier is not sufficient authorization. Resolve the identity and workspace through a trusted boundary, then verify that the operation is allowed for the selected app, table and workflow. Preserve those restrictions across reference lookups, background execution, retries and evidence retrieval.
Credentials should be stored and used through a defined credential mechanism, with secrets kept out of task payloads and evidence. The task should reference a permitted connection, not carry an arbitrary endpoint and bearer token that a model can choose to use. Connection health and permission changes need visible failure states.
| Adapter responsibility | Question for integration review |
|---|---|
| Identity | Which workspace and account does this connection represent? |
| Mapping | How are types, units and reference identifiers translated? |
| Write semantics | Which effects are atomic, asynchronous or irreversible? |
| Recovery | How can an interrupted operation be reconciled safely? |
Test the failures around the happy path
A credible integration fixture set includes revoked credentials, rate limits, deleted references, schema drift, duplicate events and a timeout after an accepted write. Webhook delivery, when used, needs signature verification, event deduplication and a reconciliation path for missing notifications. A webhook is an observation, not an unrestricted instruction to act.
Choose the first destination based on access to representative data and an observable completion condition. Bring its authentication requirements, rate limits and write semantics into the scoping discussion. Confirm destination support and the required adapter work with us before planning a live rollout.
Missing a detail or found a problem?
Send a documentation question →