API backend for a multi-client product

An API backend for a multi-client product is a single server-side system that a web app, a mobile app and, often, partner integrations all call against, instead of each client implementing its own version of the same business logic. It fits companies that already have, or are about to build, more than one client surface and need consistent data and behavior across them: the same order state, the same pricing rule, the same permission check, no matter which client asked. FreyreSoft designs these around clear authentication and authorization, explicit API versioning so existing clients don't break when new ones are added, and a relational database schema built to hold up under concurrent access from multiple sources rather than one built around a single app's convenience. The goal is a backend that partner developers and internal teams alike can integrate against without reverse-engineering undocumented behavior.

What problem does this solve?

Once a product has more than one client, business logic tends to get duplicated: the mobile app calculates a discount one way, the web app another, and a partner integration a third, because each was built against a database or an old endpoint directly rather than a shared contract. Bugs then show up inconsistently across clients, fixes have to be applied in multiple places, and adding a new client means reverse-engineering how the existing ones behave. Authentication is often the first place this shows: sessions built for a website don't translate cleanly to a mobile app or a third-party integration, and without versioning, a change made for one client silently breaks another that's already in production.

How we approach it

The backend is built as the single source of truth for business logic, with every client, web, mobile or partner, calling the same versioned API rather than talking to the database directly or duplicating rules client-side. Authentication typically uses token-based auth (JWT or OAuth2) suited to stateless mobile and partner clients, with scopes controlling what each client type can do. Versioning is planned from the start, usually through the URL path or a header, so existing integrations keep working while new capabilities roll out. The database, usually PostgreSQL for its concurrency handling and constraint support, or MongoDB when the data model is genuinely document-shaped, is designed around the domain rather than any one client's screens. Node.js, Go or Ruby get used depending on throughput needs and the team's existing tooling. Rate limiting and structured logging are part of the initial build, not an afterthought once traffic grows.

Technology we typically use

• Node.js, Go or Ruby
• PostgreSQL or MongoDB
• JWT or OAuth2 authentication
• Versioned REST or GraphQL API
• Rate limiting middleware
• Structured request logging

What a project like this usually involves

1. Designing the authentication and authorization model across client types
2. Defining an API versioning strategy that won't break existing clients
3. Modeling the database around the domain rather than any single client's needs
4. Setting up rate limiting and logging to handle real concurrent traffic
5. Writing API documentation partner developers can integrate against directly

← Back to use cases