Types of APIs: Open, Internal, and Partner

Audience axis: Open (anyone who meets published terms), Internal (your org’s systems), Partner (named counterparties under contract). That axis decides auth strictness, SLAs, rate limits, and how painful a breaking change is.

Style axis: REST, SOAP, GraphQL, gRPC, and others. Any style can appear on any audience — GraphQL is popular on public product APIs; gRPC is almost always internal. The slide’s Open branch listing REST/SOAP/GraphQL is a sample of styles, not a rule that those styles are "open APIs."

Skim before the deep sections. Upgrade surface area only when a new caller class appears — not because a tree has three pretty branches.

Open — public or developer-program callers; REST/GraphQL common; SOAP rare unless industry mandates it. Failure: scrape abuse, accidental PII exposure.

Internal — same company; FE→BE or service→service. Failure: treating the private network as enough security.

Partner — named B2B counterparty. Failure: sharing an open key instead of partner-scoped credentials.

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: backend→backend payment sync, token verify between auth and checkout, stock update between inventory and cart. Frontend→backend login, profile fetch, and live search are also internal from the company boundary’s view — even though the browser is on the public internet; the contract is owned by one product team.

The slide’s third child — Service to Database (user insert, profile update, report query) — is usually not an API type. That path is a driver, ORM, or repository. Exposing the database as a network API to every service recreates a distributed monolith. Prefer a service owning the table and exposing a real internal HTTP/gRPC API; keep SQL behind that boundary.

Prefer gRPC or REST+JSON for service meshes; keep FE→BE on REST or GraphQL. Authenticate with mTLS or workload identity even on private networks — VPN membership is not a substitute for least privilege.

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.

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](/blog/graphql-vs-rest-vs-grpc) only after the audience lane is clear — style will not fix a wrong trust boundary.