Types of APIs and Use Cases: Open, Internal, Partner

Use two questions. Who may call? Open means outside developers under published terms; Internal means systems your organization owns; Partner means named companies under contract. How is the contract shaped? REST, GraphQL, SOAP, and gRPC answer that separate question.

One API can be Internal + REST. Another can be Partner + GraphQL. The travel flow below uses all three audience lanes, even though each call could use HTTP. Audience determines authentication, rate limits, SLAs, versioning pressure, and the cost of a breaking change.

An Open API (often called a public or developer API) is published for callers outside your employee network. Weather data, login with a third-party IdP, and product catalog fetch are classic cases. You still need keys, OAuth, quotas, and versioning — "open" means available under terms, not anonymous and unlimited.

REST dominates here: cacheable GETs, CDN edges, OpenAPI docs. GraphQL fits when many client apps need different field shapes from one product graph (feeds, custom dashboards). SOAP shows up when regulated industries still require XML envelopes and formal WSDL — bank transfers, insurance claims, government records — even when the marketing slide parks SOAP under "Open." Prefer REST/OpenAPI for greenfield public surfaces unless a partner mandate says otherwise.

Internal APIs connect systems you operate. Examples include payment sync between services, token checks between auth and checkout, stock updates, login requests, profile fetches, and live search. A browser may sit outside your network, but the product team still owns both sides of the contract.

A service-to-database call is usually not another API type. It is data access through a driver, ORM, or repository. Keep SQL behind the service that owns the table; otherwise every service becomes coupled to one shared schema.

Use REST or GraphQL for product clients and REST or gRPC between services. Authenticate internal callers with workload identity or mTLS. A private network is not proof that a caller should have access.

Partner APIs sit between Open and Internal. A named counterparty — hotel chain, airline, payment gateway, affiliate network — calls you (or you call them) under a contract. B2B booking feeds, commission tracking, and health/finance/logistics data sharing belong here. Credentials are per-partner, often mutual TLS or OAuth client credentials with narrow scopes.

Change management is the real cost: partners cannot absorb weekly breaking changes. Version paths, publish deprecation windows, and measure partner-facing error budgets, not only your internal SLOs. Affiliate click analytics and product-link APIs look "simple" until dispute reconciliation needs immutable request IDs.

An API type is only the boundary. A usable API also needs an operating contract: authenticate callers, document requests and errors, test compatibility, monitor failures, and retire old versions without surprising clients.

The controls differ by audience. Open APIs need OAuth or scoped keys, rate limits, browser CORS rules, and stable public docs. Internal APIs need TLS plus workload identity or mTLS—not trust based on network location. Partner APIs need per-partner credentials, audit logs, sandboxes, and agreed deprecation windows. See REST authentication methods, JWT validation, and NGINX as an API gateway for implementation depth.

Do not pick a branch by poster color. List caller classes for one product surface (browser, mobile, partner airline, public widget). For each class write: auth mechanism, expected QPS, PII exposure, and who pays when the contract breaks.

Promote Internal → Partner when a named company needs production access. Promote Partner → Open when you want a developer program and can staff abuse response. Pick REST vs GraphQL vs SOAP from the style comparison only after the audience lane is clear — style will not fix a wrong trust boundary.