Loading…
Every managed integration platform — Apigee X, Google Cloud Application Integration, Kong — ships with a library of pre-built connectors. Those connectors cover the most common enterprise applications. They don't cover the ERP system that was customized so heavily it no longer resembles the vendor's standard API. They don't cover the legacy application that communicates via flat files dropped to an SFTP server. They don't cover the vendor portal that has a web interface but no documented API. They don't cover the mainframe system that exposes data through a proprietary binary protocol.
We document the target system's integration surface: what API or data access methods exist, what authentication it supports, what the data model looks like, and what the volume and frequency requirements are. No design begins without this.
Design document for the custom connector: authentication flow, request/response structure, error classification scheme, retry policy, and the hosting model (Cloud Run, Cloud Functions, or embedded in the integration platform).
Connector built against the architecture document. Unit tests for authentication, happy-path data flow, and all documented error scenarios — including network timeouts, authentication failures, and malformed responses from the source system.
Bring us the constraint. We'll bring the team.
These are integration gaps — and they exist in every enterprise system landscape. Custom integration work fills the gaps that standard platforms can't reach.
For systems with documented or discoverable APIs that don't have a managed connector, we build purpose-built connector components: authentication handling, request formatting, response parsing, error classification, and retry logic. These connectors are built to be maintainable — not one-off scripts that only the original developer can read.
Receiving and processing inbound webhooks from third-party systems: payload validation, signature verification (HMAC-SHA256 or platform-specific schemes), idempotency handling, and routing to downstream systems or queues. Deployed on Cloud Run or Cloud Functions for serverless operation.
For systems that still exchange data via flat files — CSV, XML, fixed-width, EDI — we build automated pipelines: SFTP polling, file format validation, transformation and mapping, loading to target systems (database, API, BigQuery), and archival with audit trail. These are common in finance, logistics, and manufacturing integrations.
Connecting event-producing systems to event-consuming systems when there is no native event channel between them: polling-based change detection, database trigger-based CDC (Change Data Capture), or API-polling with deduplication — forwarding events to Pub/Sub, a message queue, or directly to consuming services.
Direct database-level integration for systems that expose no API: read-only query-based extraction with scheduled refresh, or CDC-based streaming integration using database transaction logs. Used for reporting integrations, data warehouse pipelines, and legacy application monitoring scenarios.
End-to-end testing against the actual source system in a non-production environment. Volume testing to confirm the connector performs correctly at the expected throughput and frequency.
Production deployment with monitoring configured, runbook written, and source code handed over to the team responsible for ongoing maintenance. Documentation covers the connector's design decisions — not just its operation.