Reliable Connector Design for Disparate APIs
3. Direct Answer
A reliable connector does not pipe data directly from Source to Destination. It requires an intermediate Canonical Data Model and a strict validation layer that halts the process if the vendor schema mutates.
4. Context
Vendor APIs update silently. When an endpoint changes its date format from YYYY-MM-DD to an ISO string, brittle connectors crash or worse, corrupt data silently.
5. Failure Scenario
A CRM adds a new mandatory field to their Contact schema. A direct connector receives a 400 Bad Request, drops the payload, and fails to notify the operations team.
6. Systems Involved
- Source Webhook/API
- Mapping Engine (The Connector)
- Destination API
7. Technical Model
The connector acts as a strict border guard. It validates the incoming payload against a known schema (e.g., using JSON Schema or strongly typed DTOs in PHP).
8. Normal Flow
- Receive Payload.
- Validate Payload against Source Schema.
- Transform to Canonical Model.
- Transform Canonical Model to Destination Schema.
- Transmit.
9. Failure Flow
If the validation step fails, the payload is immediately shunted to a failed_jobs table with a clear error: Validation Failed: Field 'email' missing. An alert is fired.
10. Controls
- Schema Validation rules.
- Alerting threshold.
- Replay capability.
11. Decision Options
- Direct Mapping vs Canonical: Direct mapping is faster to build but harder to maintain if connecting one source to multiple destinations.
12. Limitations
Requires constant maintenance of the validation schema. If a vendor adds an optional field you don't know about, it will be stripped unless dynamic schema expansion is enabled.
13. Checklist
- [ ] Is incoming data validated before mapping?
- [ ] Do failures trigger alerts?
- [ ] Can a failed payload be replayed?
14. Proof
See the Backend Reliability architecture.
15. Relevant Service
16. Sources
API integration projects 2022-2026.
17. Author
Anass Benameur