THE SHORT ANSWER
An application programming interface defines how software can request a capability and receive a response. A product might call APIs for payments, maps, email, CRM, AI models, identity or analytics. The API contract describes allowed operations and data; authentication, authorization and validation control whether a request should succeed.
Think REQUEST → SYSTEM → RESPONSE
| Step | Example | Product concern |
|---|---|---|
| Request | Create an email delivery | Valid recipient, template and permission |
| System | Email service processes the operation | Availability, limits and provider behavior |
| Response | Accepted, rejected or failed | What the product records and shows next |
| Later event | Delivery or bounce notification | Reconciliation and duplicate handling |
APIs connect product capabilities
A checkout may request a payment order, a booking flow may fetch maps, a product may add a contact to a CRM, and an AI feature may send approved context to a model service. Each connection creates a dependency with its own data, permissions, cost and failure modes.
An API can read from or write to a database behind another system, but the interface and the database are separate layers.
Evidence & context: MDN Web Docs
Record the integration contract
- Operation and business purpose
- Required request fields
- Expected response and error states
- Authentication method and permission scope
- Rate or usage limits
- Timeout and retry behavior
- Duplicate or idempotency handling
- Data sensitivity and retention
- Owner and fallback
Keep private credentials and sensitive validation on the server
A browser is controlled by the user and its code can be inspected. Do not expose private API secrets there. The server should validate consequential requests, confirm authorization and treat external responses and webhooks as untrusted until verified.
For agent-specific integration layers, read Agents, Tools, APIs and MCP. For identity and permissions, continue to authentication and authorization.
Evidence & context: OWASP Foundation · OWASP Foundation
Sources & further reading
- Introduction to web APIs
MDN Web Docs. Standards-oriented introduction to interfaces that expose capabilities. Product APIs vary in transport, authentication, limits and guarantees.
- How the web works
MDN Web Docs. Standards-oriented learning material on clients, servers, DNS, HTTP and browser rendering. It is a simplified conceptual introduction rather than a complete architecture guide.
- Authorization Cheat Sheet
OWASP Foundation. Security guidance emphasizing least privilege, deny-by-default behavior and authorization checks on every request. Implementation details depend on the application's threat model.
- Secrets Management Cheat Sheet
OWASP Foundation. Security guidance on secret creation, storage, distribution, rotation and revocation. It supports the principle that private credentials do not belong in public client code.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗