Bespoke integration

Real integration estates are mixed. A client's stack might have a primary ecommerce platform on a clean REST API, an ERP that exposes both REST and SuiteTalk, a marketing platform that prefers webhooks, a warehouse that emits flat files on schedule, and one or two long-tail systems that pre-date their current vendor relationships and run on protocols nobody volunteered for in the kick-off meeting. Our bespoke integration practice is shaped around that reality.

The work spans REST APIs that nobody has written a connector for, SOAP services that pre-date most current commerce platforms, GraphQL endpoints that the vendor announced last quarter, EDI documents on schedules that the supplier negotiated in 2008, SFTP drops that the warehouse manager will not change because they have worked for fifteen years, webhook ingestion from marketing and operational systems, and the occasional direct database connection that nobody asked for at scoping but eventually has to be built. Each protocol has its own conventions, its own failure modes, and its own audit-trail expectations. We treat them on their own terms.

The first hour of a bespoke engagement is usually mapping the integration estate honestly. Which systems are on the Patchworks connector library and can use Blueprints. Which systems need custom connectors built on top of Patchworks. Which systems sit entirely outside Patchworks and need a separate integration design. Where the boundary actually is. Once that map is on the table, we can scope each integration on its own terms rather than pretending they are all the same shape.

We build bespoke integrations the same way we build platform-supported ones. Scoped against the operational reality, designed for failure modes we can name in advance, monitored from launch, owned under SLA after launch. Idempotency, retry semantics, dead-letter handling, partner-by-partner quirks, credential rotation, version pinning and the visibility a trading-partner programme actually needs. The protocol is incidental; the engineering discipline is the point.

Vendor APIs that did not exist when the project started are a recurring case. New platforms launch. Existing platforms add endpoints. The integration estate grows over the course of an engagement. The team is set up to absorb that and ship against it rather than treat it as scope change to be negotiated. If the systems exist, we will connect them, and we will connect them in a way that is still working when the systems change.