The Challenge

Surf Life Saving Australia's national systems hold the authoritative record of members, clubs and organisational entities. Four separate platforms we build and maintain need that data: the Operations app, Results, Beach Management and BeachSafe.

Integrated the obvious way, that means four implementations of the same OAuth2 handshake, four sets of guesses about response shapes, four pagination loops, and four places to fix it when the API changes. We had seen where that ends — and on a multi-platform, decade-long engagement, it ends badly.

The API also carries personal data about volunteers, including minors. Debug logging that captures raw responses is a liability, not a convenience.

The Solution

So we integrated once, as a private Composer package published to our own registry and installed as a dependency by each platform.

A real package, not a shared folder

The client is structured in three layers: a connector that owns authentication and transport, resource classes grouping endpoints by domain, and typed data objects for responses. Adding an endpoint means adding a request class, a typed response object and a resource method — a documented, repeatable process rather than an act of archaeology.

Consumers write against a facade. The platform code reads as a method call on a domain object; none of the applications know or care that OAuth2, pagination or retries are happening.

Authentication and pagination solved once

OAuth2 client-credentials authentication lives in the connector, including token lifecycle. Pagination is routed centrally, so an endpoint returning tens of thousands of members is iterated the same way everywhere — and correctly everywhere, which is the harder guarantee.

Typed responses instead of array guessing

Every response maps into a typed data object, translating the API's field naming into the conventions the platforms use, with nested structures mapped explicitly. Consuming code gets defined properties instead of nested arrays and hope. When the upstream API changes shape, it breaks in one place, loudly, rather than silently producing nulls in four applications.

Logging built for personal data

Every request and response is logged for support and audit — with sensitive fields masked on the way in. Masking is the package's responsibility, not each application's, which means it cannot be forgotten by the one platform that most needed it.

Verified against real traffic

The package ships a validator that checks its test fixtures against real captured API traffic. This closes the gap that makes SDK test suites misleading: fixtures that passed for two years while the live API quietly drifted away from them. If reality has moved, the tests say so.

The Results

One integration shared by four platforms instead of four implementations to keep in step
Distributed as a versioned Composer package on a private registry, so upgrades are deliberate and per-platform
Sensitive-data masking enforced centrally, not per application
Typed responses, so upstream changes surface as failures rather than silent nulls
Fixtures validated against captured production traffic, so the tests stay honest
A documented process for adding endpoints, so the client keeps pace with the API

Technology

A Laravel package built on Saloon, with an OAuth2 client-credentials connector, domain resource classes, typed data-transfer objects with explicit field mapping, centralised pagination, and a logging model that masks sensitive data before persistence. Ships its own service provider, configuration, migration and artisan commands. Published to a private GitLab Composer registry and consumed as a versioned dependency.

See also: SLSA Incident Reporting Integration — the SOAP half of the same integration story, and SLSA Results — one of the consuming platforms.

Related Nano Solutions services: Systems Integration · App Security · Software Development. WA government agencies can engage us directly through our CUAICTS2021 panel listing.