A serverless API is an HTTP endpoint whose application logic runs as on-demand functions instead of a continuously managed application server.
That model fits small teams when HTTP work is bounded, independently deployable, and able to keep durable state outside the function. The same HTTP function can serve a small API route, receive a webhook, handle a callback, or expose a lightweight internal endpoint without requiring the team to operate a full web server for that task.
The important decision is not whether HTTP is "serverless." It is whether the request can be handled as a clear unit of work. A webhook that validates a signature, records an event, and returns is function-shaped. A large application with many routes, long-lived connections, shared in-process state, and constant traffic may fit a persistent app runtime better.
At Raff, we use HTTP Functions as an event boundary: receive the request, authenticate or validate it, perform bounded work, write durable state, and return. This guide maps that operating model. The deeper implementation topics—webhook retries, API authentication, CORS, rate limiting, and choosing Function URLs versus an App Platform API—belong to their dedicated guides.
Serverless APIs turn HTTP requests into function invocations
A traditional application server stays running and listens for requests continuously. A serverless API maps incoming HTTP traffic to function execution.
Client / external service ↓ HTTPS URL ↓ HTTP Function ↓ Database / Object Storage / external API ↓ Response
The HTTP interface can still look like a normal API. Clients do not need to know whether the code behind the endpoint runs on a function, container, VM, or another compute model.
The difference is operational:
| Area | Serverless HTTP function | Persistent app runtime |
|---|---|---|
| Lifecycle | Runs from incoming demand | Process stays running |
| Scaling | Function instances scale with load | App replicas or servers scale |
| Idle capacity | Can scale down aggressively | Depends on app platform/runtime |
| OS/process management | Mostly platform-owned | More runtime ownership |
| State | Should be external/durable | Can reuse process state, but durable data still external |
| Best fit | Bounded endpoints and event receivers | Larger persistent applications |
A serverless API is therefore not a different HTTP protocol. It is a different execution model behind the HTTP boundary.
The Serverless vs Containers guide owns the broader lifecycle decision. This guide focuses specifically on HTTP APIs and webhooks built from functions.
HTTP APIs fit when requests are bounded and independent
A serverless HTTP endpoint is strongest when one request can be understood and completed independently.
Good candidates include:
- small REST-style endpoints;
- form submissions;
- API callbacks;
- webhook receivers;
- internal utility endpoints;
- lightweight authorization callbacks;
- metadata lookups;
- short data transforms;
- status-update endpoints;
- endpoints that trigger asynchronous work;
- low or irregular traffic APIs.
The common shape is:
request arrives ↓ validate/authenticate ↓ perform bounded work ↓ write durable state if needed ↓ return response
This works especially well when endpoints have different traffic patterns. A billing webhook, image callback, and internal admin endpoint do not need to share the same scaling profile simply because they belong to one product.
A function also creates a useful isolation boundary. External webhook retries or traffic spikes do not need to compete directly with the main application process.
However, splitting every route into a separate function is not automatically better. Each deployment unit adds configuration, ownership, logs, secrets, and failure modes. Keep related routes together when that makes the application easier to operate.
Webhooks are a specialized HTTP API workload
A webhook is an HTTP request sent by another system to tell your application that an event occurred.
Examples include:
- payment succeeded;
- subscription changed;
- Git event occurred;
- email bounced;
- CRM record changed;
- form was submitted;
- monitoring alert fired;
- document was signed.
Because webhooks are event-driven, they are a natural serverless workload. But webhook correctness requires more than exposing a URL.
A safe high-level flow is:
provider request ↓ validate sender/signature ↓ check duplicate event ↓ store durable event state ↓ acknowledge quickly ↓ process slow work separately
This connector guide deliberately does not own the detailed retry, signature, idempotency, replay, and durable-event design. Those belong to Webhooks on Serverless Functions.
The ownership boundary matters for SEO and for readers: this page explains where HTTP Functions fit; the webhook guide explains how to operate a webhook endpoint safely.
API state should live outside the function runtime
Serverless HTTP code should not depend on one execution environment surviving for the next request.
Durable state belongs in services designed to persist it:
- user and application records → database;
- sessions or durable tokens → appropriate persistent store;
- uploaded files and generated artifacts → object storage;
- job status → database;
- secrets → environment or secret management;
- long-running workflow state → database, queue, or workflow system.
A safe pattern looks like this:
HTTP Function ↓ Managed Database = durable records Object Storage = files/artifacts External API = third-party action
Warm execution environments may let code reuse initialized clients or connection pools temporarily, but correctness should never depend on that reuse.
This is one of the strongest architecture tests for serverless APIs: if the endpoint only works when local process state survives between requests, it is not cleanly function-shaped.
Authentication, CORS, and rate limiting are separate API controls
Putting an API behind a function does not remove normal HTTP security requirements.
Production endpoints still need decisions around:
- authentication and authorization;
- CORS policy;
- rate limiting or abuse controls;
- request size and validation;
- secret handling;
- logging sensitivity;
- tenant isolation;
- replay protection where relevant;
- API versioning;
- error behavior.
These controls should be designed per endpoint family. A public webhook receiver, browser-facing API, and internal service endpoint have different trust boundaries.
The roadmap's dedicated Serverless API Authentication, CORS, and Rate Limiting guide owns those controls in depth. This connector keeps them visible as architectural requirements without duplicating that future article.
A useful rule is: serverless changes who operates the runtime; it does not remove the responsibilities of an Internet-facing API.
Function URLs work best when the HTTP surface stays simple
A direct function URL can be a clean interface when a team needs one bounded HTTP service without a large routing layer.
Good examples include:
- one webhook receiver;
- one callback endpoint;
- a small internal API;
- a narrow public endpoint;
- a lightweight microservice with a few related routes.
As the HTTP surface grows, the decision becomes broader. Teams may want a persistent application runtime when they need:
- many tightly coupled routes;
- long-lived connections;
- extensive middleware;
- shared in-process caches;
- complex routing behavior;
- a continuously busy API;
- several coordinated background processes;
- a full application framework running as one service.
That next decision belongs to the planned Function URLs vs App Platform APIs guide. The point here is to avoid treating every HTTP endpoint as either "must be a function" or "must be a full app." The right boundary follows workload shape.
Serverless APIs still need latency and concurrency planning
HTTP functions can scale independently, but that scaling can move pressure downstream.
A burst of API requests may create more simultaneous:
- database connections;
- external API calls;
- object-storage operations;
- authentication checks;
- queue writes.
The function platform being able to scale does not prove every dependency can absorb that scale.
Use a capacity chain:
incoming HTTP traffic ↓ function scale/concurrency ↓ database / API / storage capacity
For latency-sensitive endpoints, cold-start behavior may also matter. Raff Functions supports scale-to-zero and optional warm capacity, so teams can choose between avoiding idle capacity and keeping latency-sensitive execution ready.
The Cold Starts, Concurrency, and Scale-to-Zero guide owns startup behavior. The Runtime Limits guide owns hard timeout and capacity limits. This page only establishes that HTTP API design must account for both.
Raff Functions provides a direct HTTP runtime
Raff Functions currently supports HTTP live URLs with automatic TLS, alongside cron, one-off, and object-storage triggers. HTTP code can use standard handler patterns including Python FastAPI/ASGI, Node.js standard HTTP, JavaScript Web Fetch, TypeScript, and Go net/http, with a Dockerfile escape hatch for custom runtimes.
That matters for API portability. The application can look like normal HTTP code rather than depending on a Raff-specific request/response signature.
Current Raff Functions also provides:
- scale-to-zero and load-based autoscaling;
- editable runtime settings;
- logs and metrics for invocations;
- live log tail;
- invocation count, p50, p95, and error-rate visibility;
- timeouts up to 1 hour by default and up to 24 hours on request;
- bindings to managed databases and object storage;
- a per-account spend cap that is on by default.
Those characteristics make HTTP Functions useful for small APIs and event receivers that need to run independently without the team operating a full server just for the endpoint.
They do not mean every API should become a function. A continuously busy application with a broad HTTP surface may be easier to operate as a persistent app or container runtime.