1. Define ownership and completion
For every field and business effect, decide which system owns the authoritative state. Define what proves completion: an accepted request, a confirmed external operation, a returned identifier, a webhook, or later reconciliation. Do not copy an entire external model into RevoEngine unless the application needs to own that data.2. Choose the integration boundary
3. Bind credentials through Secrets
Keep tokens, passwords, and private headers in Vault. Bind the appropriate instance, personal, or provisioned organization value to the exact Component or Agent plugin that needs it. Resolve it only for the outbound operation. Never place credentials in source, Agent instructions, plugin descriptions, logs, Inbox payloads, or workspace files.4. Design idempotency before retry
Create a stable business key before the first external mutation. Persist the external correlation identifier and the local operation identity. After a timeout, query the external system before repeating the effect. Transport retry and business retry are different decisions. A successful HTTP status can still represent a rejected business operation, while a failed connection can hide a completed mutation.5. Make work observable
Return or store safe identifiers that connect:- the RevoEngine execution;
- the business record;
- the external operation;
- the Job, Event, or webhook attempt;
- any generated Storage artifact.