Use the simplest viable integration
A standard connector is preferable when it supports the required entities, mappings, frequency and exception handling. Middleware becomes justified when several systems own different fields, channel rules diverge, workflows need orchestration or failures require custom recovery.
Define contracts at every boundary
Document payloads, identifiers, version, authentication, permitted values and error behaviour. OpenAPI can describe HTTP API contracts, but a schema alone does not define business ownership or recovery. Record both technical and operating contracts.
Design for distributed failure
An update may succeed in one system and fail in another. Use idempotent operations, durable state, controlled retries and—where a database write must lead to an event—patterns such as a transactional outbox. Treat duplicate messages as expected and make consumers safe to repeat.
Protect credentials and data
Use least-privilege scopes, managed secrets, signature verification and auditable access. Validate incoming payloads before processing. Do not expose platform credentials to browsers or logs.
Operate, not just deploy
Monitor throughput, latency, rejection reasons, retry queues and reconciliation differences. Maintain runbooks for token expiry, rate limiting, schema changes, downtime and replay. Version mappings so a change can be traced and rolled back.