API

An API (Application Programming Interface) is an agreed set of rules that lets two programs exchange data and run each other’s functions without knowing how the other side is built inside. Think of it as a contract: it states which requests you can send, in what format, which data is required and what the other side will send back. The most common form today is the web API, which runs over HTTP (the same protocol the web is built on). In these APIs, data is usually sent as JSON or XML.

How does an API work?

Most APIs follow a client–server model. The program asking for something (sending a request) is the client. The system that answers (the response) is the server. The client sends its request to a specific endpoint – a URL that points to a resource or an operation. The server processes the request and sends back a response together with an HTTP status code that tells the client how it went.

A typical web API request is made up of a few parts:

1. An HTTP method saying what we want to do: GET (read), POST (create), PUT/PATCH (update), DELETE (remove).
2. An endpoint and parameters that point to the resource (part of the URL, query parameters).
3. Headers, including credentials (e.g. Authorization) and the content format (Content-Type).
4. A request body (payload), usually in JSON, when we are saving or creating something.
5. A response: a status code (e.g. 200, 201, 400, 401, 404, 429, 500) and the result data.

What are the types of APIs?

APIs are grouped in two ways: by who can use them and by their style and protocol of communication.

By availability

• Private (internal) – used only inside one organization, to connect its own systems.
• Partner – shared with selected, trusted external companies under an agreement.
• Public (open) – available to outside developers, often after registration and with an API key.
• Composite – combine several calls to different services into a single request.

By style and protocol

• REST (Representational State Transfer) – the most popular web API style. It is stateless, meaning the server does not remember earlier requests – it treats each one on its own. It is built around resources and ordinary HTTP methods.
• SOAP – an older XML-based protocol with a rigid schema (WSDL), still found in enterprise and banking systems.
• GraphQL – a query language in which the client states exactly which fields it wants, so it fetches neither too much nor too little data.
• RPC (e.g. gRPC, JSON-RPC) – remote procedure calls, that is, running a function on another server. gRPC uses HTTP/2 and Protocol Buffers and works well for communication between microservices.
• WebSocket – a persistent, two-way channel for sending data and events live.
• Webhooks – the inverted model: the server itself sends an HTTP request to a client-defined URL when something happens.

What is an endpoint and API documentation?

An endpoint is the interface’s access point – a URL where a specific operation or resource is available. The full set of endpoints, together with their methods, parameters, formats and response codes, makes up the API contract.

That contract is written down as a specification, most often in the OpenAPI standard (formerly Swagger) for REST APIs. From the specification you can automatically generate documentation, ready-made code and tests. In GraphQL the contract is the schema; in gRPC it is the .proto files.

How are APIs secured?

An API is a part of the system exposed to the outside world, so it is an easily reachable target for attackers – it puts the application’s logic and data within reach. The main ways to protect it are:

• Encrypting the connection – communication over HTTPS (TLS) only, and turning off outdated versions (SSLv3, TLS 1.0/1.1). For higher-risk services, mTLS is used – both sides confirm their identity with a certificate.
• Authentication – proving who is sending the request: API keys, JWTs, OAuth 2.0 (short-lived access tokens), OpenID Connect, HMAC.
• Authorization – checking permissions on every request, for every object and every operation, following the principle of least privilege (each party can reach only what it truly needs).
• Checking input data – verifying type, length, range and format, rejecting oversized requests (code 413) and using parsers that resist the XXE attack.
• Rate limiting – capping the number of requests and replying with 429 to curb abuse, mass probing and DoS attacks.
• Response hygiene – generic error messages (without revealing how the system works), security headers (Strict-Transport-Security, X-Content-Type-Options: nosniff) and a restrictive CORS policy.

Why do APIs matter for security and monitoring?

APIs are now one of the main targets of attacks on applications. The OWASP API Security Top 10 list names BOLA (Broken Object Level Authorization) as the biggest risk. It means a client swaps an identifier in the request and reaches someone else’s data, because the server does not check who the resource belongs to. Other important risks include broken authentication, returning too much data in a response and having no limits on resource usage.

From the point of view of a security team (SOC), network threat detection systems (NDR) and monitoring, APIs matter in two ways:

• As a source of risk. API traffic must be watched for unusual behavior: sudden spikes in 401/403 errors (attempts to bypass access control), repeated probing of identifiers (a sign of a BOLA attack), unusually large data downloads (possible data theft) or calls from unexpected addresses. A common entry point is “shadow APIs” – forgotten or undocumented endpoints.
• As a source of data and an integration point. Monitoring systems themselves expose and use APIs to pull alerts, enrich events with context (for example data about assets or threat information), forward data to SIEM/SOAR systems and automate incident response. API access logs – with the time of the event, the IP address and the caller’s identity – are important evidence when analyzing an incident.

Learn more

• Secure Access Service Edge (SASE) — SASE often uses APIs to integrate security, networking, and identity services.
• Identity and Access Management (IAM) — IAM systems expose APIs for authentication, authorization, and user management.
• REST API — REST API is a common API style used for web-based data exchange.
• North-South vs East-West Traffic — APIs can carry both external north-south and internal east-west traffic.
• Cloud Security Posture Management (CSPM) — CSPM uses cloud provider APIs to check configurations and detect misconfigurations.
• SaaS / IaaS / PaaS — SaaS, IaaS, and PaaS commonly provide APIs for automation and integration.