Case study
Designing an integration layer so each new client is configuration
Every new client integration with Tetra Consulting's PRISM platform was a bespoke build into its backend, and clients were queuing. For Tetra's 2026 tender we designed PRISM API v4 and Prism Connect, an integration layer where each third-party system is a monitored connector and a new client is configuration, not code.
2026
- 4
- Prism Connect implementations designed2026
- 8
- existing client integrations to move onto connectors2026
- ~1 day
- projected to onboard a client to an existing connectorprojected
The challenge
PRISM sits at the centre of Tetra's client delivery, and Tetra's clients want it connected to the systems they already run, such as MRI, Dwellant, DataStation and BlockPro. Every integration was a bespoke build into the PRISM backend, with no shared framework, no OAuth and no audit trail. The v3 API had no webhooks, retries or alerting, so integrations failed silently. Sales could not quote a timeline without engineering capacity and a release slot, and national and international prospects were setting security requirements at bid stage.
What we did
- April 2026 — mapped PRISM's current architecture and where integrations break, in response to Tetra's tender
- Phase 1, weeks 1–6 — rebuild the public API as v4: OAuth 2.0, webhooks, per-client rate limiting, audit logging, versioning and OpenAPI documentation
- Phase 2, weeks 7–12 — deploy Apache Camel as Prism Connect, with a route framework, retries, monitoring and dead-letter queues
- Phase 3, weeks 13–18 — build the MRI, Dwellant and DataStation connectors, move existing clients onto them, and support BlockPro integrating directly against v4
What we built
Two layers. PRISM API v4 becomes the stable, secure and observable foundation every integration depends on. Prism Connect moves integrations out of the PRISM backend entirely: each third-party system lives in its own connector that can fail, be redeployed or be upgraded without touching the core, while Camel handles routing, transformation, retries and error recovery. The hard-coded Dwellant integration would be rebuilt as a connector, and DataStation's overnight cron scripts replaced by a monitored route.
- OAuth 2.0 and SSO-ready public API
- Webhooks for real-time events
- Per-client rate limits and audit logging
- Versioning with OpenAPI documentation
- One deployable connector per third-party system
- Retries, monitoring and dead-letter queues
The result
The proposal sets out how onboarding a client to an existing connector would drop to around a day of configuration rather than a development cycle, how existing integrations would stop failing silently, and how Tetra would meet the OAuth, audit and versioning requirements that enterprise and international bids now set.
- Apache Camel
- OAuth 2.0
- OpenAPI
- MRI
- Dwellant
- DataStation
- BlockPro