One platform, 21 integrations: a shared auth and proxy layer for third-party APIs

Each integration was built separately, which meant re-implementing authentication, configuration, and API handling every time. Delivery was limited to about two integrations a month.

• ▸Many third-party CRM, ticketing, and chat systems, each with its own authentication scheme.
• ▸Several product modules (ticketing, chat, data-ingestion pipelines) that all needed integrations.

I designed and built the platform: an authentication and proxy service that connects to any third-party application, plus an SDK that product services use to call third-party APIs through it.

Most of the work in every integration was the same: connecting an account, handling the auth flow, managing credentials, and making authenticated calls. A common platform could own that shared part, so each module only had to build what was unique to it.

• ▸A general, configurable service that handles integration creation, integration-specific configuration, and third-party API calls.
• ▸A reverse-proxy design: child services call the platform's APIs, and it handles authentication for each provider in a scalable way.
• ▸One interface for Basic auth, OAuth, and OAuth 2.0 with PKCE.
• ▸An SDK so services can adopt the platform with minimal code.
• ▸Built as Java/Spring Boot and Node.js microservices.

Only the first integration of each type took real effort. After that, new integrations mostly reused the platform, and the team delivered 21 integrations in 5 months. Because it was simple to use, 5 product teams across the organization adopted the platform for their own third-party integrations.

• ▸Look for the repeated work before writing the next one-off. Spotting that every integration shared the same auth and API plumbing was worth more than speeding up any single integration.
• ▸Centralize the risky parts. With authentication and credential handling in one place, every security or reliability improvement reached all integrations at once.
• ▸A platform's adoption depends on how easy it is to use. Five teams picked it up because a simple SDK made the first integration quick.