How do companies organize APIs across microservices?

Here's how companies typically organize APIs across microservices:

Domain-driven ownership

• Split services along bounded contexts (Domain-Driven Design) — each service owns a specific business capability (orders, inventory, billing) rather than being organized around technical layers.
• Each team owns the full lifecycle of the APIs their service exposes — design, versioning, deprecation — following a "you build it, you run it" model. Avoid organizing services around shared database tables; ownership boundaries should match data boundaries, not org chart convenience.

API gateway as the front door

A single API gateway (or a small number of them) sits in front of all services, giving external and internal consumers one place to authenticate, discover, and call APIs rather than hitting dozens of services directly.

• The gateway handles cross-cutting concerns — auth, rate limiting, request routing, response shaping — so individual services stay focused on business logic. Many companies layer a Backend-for-Frontend (BFF) on top of the gateway per client type (web, mobile, partner API) so each consumer gets a tailored API shape without forcing every service to handle every client's needs directly.

Internal vs. external APIs

Internal service-to-service APIs are often looser and higher-velocity (can change faster, less strict versioning) since both ends are controlled by the same organization.

• External/partner-facing APIs get stricter governance: formal versioning, SLAs, published docs, and a slower, more deliberate deprecation process — usually exposed through the gateway or a dedicated API management layer rather than directly from internal services.

API catalogs and registries

• Larger orgs maintain a central API catalog or developer portal (sometimes called a "service catalog") listing every API, its owner, spec, and status — so teams can discover what already exists instead of rebuilding it. Some pair this with a schema/contract registry (especially for event-driven or gRPC/protobuf APIs) to prevent breaking changes from slipping through.

Service mesh for east-west traffic

• For service-to-service calls (as opposed to client-to-service), many companies add a service mesh (Istio, Linkerd) on top of or alongside the gateway — handling mTLS, retries, load balancing, and observability for internal traffic without each service reimplementing that logic.
• The general pattern: gateway for north-south traffic (external clients calling in), mesh for east-west traffic (services calling each other).

Governance models

• Centralized governance: a platform/API team sets standards (naming, versioning, auth patterns) that all service teams must follow — common in regulated industries or large enterprises.
• Federated/self-service governance: platform team provides tooling and guardrails (linting, gateway policies, templates) but individual teams design and ship their own APIs within those guardrails — more common in fast-moving, product-led orgs.
• Most companies land somewhere in between: strict standards for things like auth and error formats, more team autonomy for resource design and business logic.

Grouping strategies people actually use

• By business domain (most common) — orders, users, payments, shipping, etc.
• By API type/audience — public/partner APIs, internal APIs, and admin/internal-tooling APIs often live in separate gateways or namespaces with different security postures.
• By versioned product line — larger platforms group APIs under product verticals, each with its own lifecycle, especially post-acquisition or in multi-product companies.

Let me know if you want this angled toward a specific vendor/tooling comparison for the next query.