API PLATFORMBuild your API once. Let Stack53 grow with it.
An API that grows with your application.
Build your application’s backend and APIs on Stack53. Start with a prototype, and keep the same API as you reach production, thousands of users and high-concurrency workloads — without redesigning your infrastructure.
View architecture →ONE API · EVERY STAGEapi.acme.com
- 1 Prototype APIDatabaseAuth
- 2 First users Custom domainTLSStorage
- 3 Production DeploymentsLogsMetrics
- 4 Thousands of users CacheWorkersRate limits
- 5 High concurrency QueuesMore API instances
- 6 Large scale Private servicesDedicatedRegions · Planned
Same API. Same project. The platform underneath grows.
BUILT FOR
Application backendsMobile appsSaaS productsMarketplacesEcommerceAI applicationsInternal systemsPublic APIsPartner APIsMachine-to-machineWebhook receiversHigh-traffic apps
DESIGNED AROUND
Low latency Short request paths
High concurrency Many requests at once
Scalability Grow without rebuilding
Reliability Health-checked releases
Security Identity at the edge
Observability Logs, metrics, traces
Simplicity One project, one model
WHAT IT PROVIDES
An API never lives alone.
Stack53 connects your API to everything it depends on — identity, data, processing and operations — inside the same project.
TRAFFIC API endpointsApplication routingAPI versioningRate limitingCustom domains
IDENTITY AuthenticationAuthorizationAPI keysService accounts
DATA Database accessStorage accessCaching
PROCESSING FunctionsBackground jobsQueuesWebhooks
OPERATIONS DeploymentEnvironment variablesSecretsLoggingMetrics
ONE API ACROSS YOUR APPLICATION
Your API is the front door to your backend.
Authentication, database, storage, cache, functions, jobs and webhooks are all parts of the same Stack53 project. Your API is the interface your application uses to reach them — one consistent backend model, managed in one place.
How projects are organized →PROJECT · STOREFRONTproduction
Your application
APIapi.acme.com/v1
Authentication
Database
Object Storage
Cache
Functions
Jobs
Webhooks
LOW LATENCY
Short paths for every request.
Most response time goes to hops, lookups and waiting. Stack53 keeps the path from request to response short and moves everything else out of the way.
Conceptual PROJECT · STOREFRONT
Clientweb · mobile
Edgeapi.acme.com TLSAuthRate limit
Your API/v1/orders · /v1/users
Cachefrequent reads
Databasepooled connections
Queue
Workers
HTTPScheckedslow work 123456 Latency depends on your code, data and region. Stack53 does not publish latency guarantees.
Conceptual
Clientweb · mobile
1HTTPS
Edgeapi.acme.com TLSAuthRate limit
2checked
3PROJECT · STOREFRONT
Your API/v1/orders · /v1/users
4
Cachefrequent reads
5
Databasepooled connections
6slow work
Queue
Workers
Latency depends on your code, data and region. Stack53 does not publish latency guarantees.
1Efficient routing Requests take a direct path to your API.
2Edge checks TLS, auth and rate limits run before your code.
3Close to its data API, database and cache share one project.
4Cached reads Frequent reads come from cache, not the database.
5Connection reuse Pooled connections skip setup on each request.
6Work off the path Slow tasks go to a queue; the response returns first.
HIGH CONCURRENCY
Built for many requests at once.
Launches, promotions and notifications bring many users at the same moment. Stack53 spreads that load across your project so one busy minute doesn’t stall the API.
WHERE BURSTS COME FROM
Flash salesEveryone checks out at once
LaunchesTraffic jumps at a set time
Mobile push spikesOpens after a notification
Webhook burstsProviders deliver in batches
Real-time dashboardsMany clients polling steadily
Partner integrationsMachine traffic all day
HOW STACK53 HANDLES IT
Multiple API instancesHorizontal scaling[confirm availability]Connection poolingCachingQueuesRate limitsHealth-checked routing
Health-checked routing
APIhealthy
APIhealthy
APIstarting
Connection pool
Database
FIVE WAYS TO MEASURE LOAD
Total requests Everything received over a period, added up.
Requests per second How many arrive within each second.
Concurrent requests Requests in flight at the same moment.
Long-running requests Stay open longer and hold resources meanwhile.
Background jobs Work queued and finished outside the request.
TRAFFIC SPIKES
Stay steady when traffic jumps.
Spikes are normal. The goal is to keep responses flowing while extra load is absorbed, buffered or spread out.
Cache what many users read.Move slow work to a queue.Set rate limits per key or client.Load test before a big launch.
REQUESTS OVER TIMEIllustrative IncomingServedQueued work
1Rate limits protect the API
2Cache absorbs repeated reads
3Queue buffers slow work
4More instances, when configured
REQUESTS OVER TIMEIllustrative IncomingServedQueued work
- 1Rate limits protect the API
- 2Cache absorbs repeated reads
- 3Queue buffers slow work
- 4More instances, when configured
SCALABILITY
Grow without rebuilding.
Start with the basics and add what you need as usage grows. Your API code, endpoints and project stay where they are.
STAGE 1BuildGet a working backend up.
APIDatabaseAuthStorage
API · api.acme.com/v1
BUILD
STAGE 2LaunchPut it in front of real users.
Custom domainTLSDeploymentsLogs
API · api.acme.com/v1
LAUNCH
BUILD
STAGE 3GrowHandle more users and more work.
CacheWorkersQueuesRate limitsMetrics
API · api.acme.com/v1
GROW
LAUNCH
BUILD
STAGE 4ScaleServe heavy, steady demand.
More API instancesPrivate networkingDedicated resources Additional regions Planned
API · api.acme.com/v1
SCALE
GROW
LAUNCH
BUILD
api.acme.com/v1 Same API · same endpoints · same project — what changes is the infrastructure underneath. View architecture →
ARCHITECTURE
How a request moves through Stack53.
Every request takes the same short path: through the edge, past the gateway’s checks, into your API — which reaches data and processing inside your project.
REQUEST PATH · GET api.acme.com/v1/orders/:idConceptual — simplified for illustration
01Users & apps Web appMobile appPartnersServices
02 · EDGEEdge DNSTLSCustom domains
03 · GATEWAYAPI Gateway RoutingAuth checksRate limitsCORS
04 · YOUR APIAPI instances api · instanceapi · instanceapi · instance storefront · production
05 · DATA DatabaseCacheObject Storage
05 · PROCESSING QueuesWorkersJobsFunctions
06 Observability LogsMetricsTraces
ENDPOINTS & CUSTOM ROUTES
Define the routes your app needs.
Path params, query params, custom routes and grouped routes — each route with its own auth requirement and rate-limit policy.
METHODPATHHANDLERAUTHRATE LIMITSTATUS
/v1/orders · group
GET/v1/ordersorders.listRequiredstandard Live
POST/v1/ordersorders.createRequiredwrites Live
GET/v1/orders/:idorders.getRequiredstandard Live
PATCH/v1/orders/:idorders.updateRequiredwrites Live
DELETE/v1/orders/:idorders.cancelRequiredwrites Draft
custom routes
POST/hooks/storefrontwebhooks.receiveSignaturewebhooks Live
stack53.routes.group('/v1/orders', { auth: 'required', rateLimit: 'standard', }, (r) => { r.get('/', 'orders.list', { query: ['status', 'limit'] }) r.get('/:id', 'orders.get') r.post('/', 'orders.create', { rateLimit: 'writes' }) }) // Custom route outside the group stack53.routes.add('POST', '/hooks/storefront', 'webhooks.receive')
Illustrative — see the API reference for exact syntax.
VERSIONS & ENVIRONMENTS
Change safely. Version clearly.
Run versions side by side while clients migrate, and test every change in its own environment before production sees it.
API VERSIONSapi.acme.com
/v0DeprecatedSunset on [date] · clients warnedDEPRECATED
/v1StableDefault for all current clientsSTABLE
/v2BetaOpt-in while the contract settlesBETA
ENVIRONMENTSproject · storefront
develop → promote → release
development api-dev.acme.com Own variablesDev database
staging api-staging.acme.com Own variablesStaging database
production api.acme.com Own variablesProd database
CUSTOM DOMAINS & CORS
Your domain. Your browser rules.
Serve your API from your own domain, and decide exactly which web apps may call it.
api.acme.comACTIVE
DNS RECORDCNAMEapi→ [target from dashboard]
TLS CERTIssued automatically [confirm availability]
ENVIRONMENTproduction · /v1
ALSO ATTACHEDapi-staging.acme.com → staging
CORS POLICY · api.acme.comproduction
ALLOWED ORIGINShttps://acme.comhttps://app.acme.com+ origin
METHODSGETPOSTPATCHDELETEPUT
HEADERSAuthorizationContent-TypeX-Request-Id
CREDENTIALSAllow credentials (cookies, auth headers)
SCALING Only features shown as available are live today.
Scale the parts that need it.
API instances, workers and cache are sized independently, so you add capacity where traffic actually lands.
API instances · size · workers · cacheAVAILABLE NOW
Autoscaling[confirm availability]
Additional regions / multi-regionPLANNED
API instancesMIN[min]±MAX[max]±
Instance size[Supported sizes]
Autoscaling[confirm availability]
Workers[count]±
Cache size[Supported sizes]
AUTHENTICATION
Know who is calling.
Every request to your API arrives with an identity Stack53 has already checked. Your handler reads the caller — it doesn’t parse tokens.
User sessions and tokensAPI keysService accountsOAuth providers [Supported providers][confirm availability]
FROM SIGN-IN TO REQUESTConceptual
1User signs inStack53 Auth
2Receives a tokeneyJhbGciOi…
3Calls your APIapi.acme.com
4API verifies→ user identity
export const listOrders = stack53.api.route('GET /v1/orders', async (req) => { const user = req.auth.user // already verified by Stack53 if (!user) return req.unauthorized() return stack53.db.orders.list({ userId: user.id }) })
Illustrative — see the API reference for exact syntax.
API KEYS
Keys you can see and revoke.
For partners, scripts and machine-to-machine calls. Every key has an owner, a scope and a last-used time.
API keysstorefront · api.acme.com
+ New keyNAMEKEYENVIRONMENTSCOPESCREATEDLAST USEDACTIONS
storefront-web sk_live_4f… production orders:read orders:write Jan 12 2 min ago
partner-feed sk_live_9c… production orders:read Feb 03 Yesterday
ci-smoke-tests sk_test_2a… staging orders:read Mar 21 1 hour ago
Scoped keysSeparate keys per environmentKey rotationRevoke instantly Full key shown once, at creation [confirm availability]
SERVICE ACCOUNTS & INTERNAL APIS
Services that call services.
Give background workers their own identity, and keep internal APIs off the public internet.
billing-workerService account
ActiveENVIRONMENTproduction SCOPESorders:readinvoices:write USED BYbilling-service SIGN-INNone — machine identity only
PROJECT · STOREFRONT · PRIVATE NETWORK [confirm availability] Conceptual no public route
Internet
api.acme.comPublic API
orders-serviceinternal only
billing-serviceruns as billing-worker
Internet
PROJECT · STOREFRONT · PRIVATE NETWORK
Conceptualapi.acme.comPublic API
orders-serviceinternal only
billing-serviceruns as billing-worker
no public route [confirm availability]RATE LIMITING
Protect your API from overload.
Set limits by caller or by route. Over the limit, callers get a clear 429 instead of a slow API.
RATE LIMIT POLICY · PRODUCTION+ Add rule
LIMIT BYAPPLIES TOLIMITWINDOWON
Per IP all routes [limit] [window]
Per API key all routes [limit] [window]
Per user all routes [limit] [window]
Per route POST /v1/orders [limit] [window]
HTTP/1.1 429 Too Many Requests Retry-After: 30 Content-Type: application/json { "error": "rate_limited" }
Illustrative — see the API reference for exact syntax.
SECRETS
Secrets stay out of your code.
Never committed to your repositoryInjected into your API at runtime Rotate without a redeploy [confirm availability]
storefront · variables & secrets
DATABASE_URL •••••••••••• secret
PAYMENTS_API_KEY •••••••••••• secret
SESSION_SECRET •••••••••••• secret
LOG_LEVEL info variable
Encrypted at rest[confirm availability]Values are masked after saving
CACHING
Serve repeated reads from cache.
Put a managed cache in front of your database. Popular reads come straight back from cache, and your database only handles what it needs to.
Explore Cache →CACHE FLOW · CONCEPTUALGET /v1/products
Request
cache? HIT Return from cacheFast path · no database call
MISS Database
Store in cache
Response
TTLExpire entries on your schedule
Invalidate on writeClear stale data when it changes
Per-route rulesDecide which endpoints cache
Cache keysKey by path, params or user
BACKGROUND PROCESSING & QUEUES
Move slow work off the request.
Accept the request, answer right away, and let workers finish the heavy lifting in the background — in the same project as your API.
REQUEST → QUEUE → WORKERSapi.acme.com
Client
Your API
Queue
Workers
- POST /v1/orders
- 202 Accepted · right away
- enqueue job
- worker picks up job
WORKERS RUN Send emailGenerate invoiceResize imageCall webhook
QUEUE MONITORIllustrative
QUEUEWAITINGACTIVEFAILEDRETRIES
emails ——
invoices ——
images
webhooks —
Automatic retries for failed jobs Dead-letter queue [confirm availability] Scheduled jobs · Jobs & Cron →
DATABASE & STORAGE INTEGRATION
Your data, one call away.
Database and Object Storage live in the same project as your API, so your handlers reach them without extra wiring.
DatabaseDatabases →
// POST /v1/orders on api.acme.com export async function createOrder(req) { const order = await stack53.db.query( 'insert into orders (user_id, total) values ($1, $2)', [req.user.id, req.body.total]) return { status: 201, body: order } }
Managed database, same projectConnection poolingMigrations with your deploys Engines: [Supported engines]
Object Storage · signed uploadsStorage →
Your app
Your API
Database
Object Storage
- 1 ask for URL
- 2 signed URL
- 4 ref
- 3 upload file directly
Large files skip your APIAPI keeps the file reference
WEBHOOKS
Webhooks guide →Receive events. Send events.
IncomingFROM EXTERNAL SERVICES
Payment provider
Git provider
Verify signatureReject unsigned calls
Your handlerPOST /webhooks/payments
Signature verification with a secret stored in your project Hand work to a queue and acknowledge fast; senders retry on failure
OutgoingTO YOUR CUSTOMERS' ENDPOINTS
EVENTENDPOINTSTATUS
order.createdhttps://hooks.example.com/acme200
order.paidhttps://shop.example.net/hooks500
order.paidhttps://shop.example.net/hooksretrying
Illustrative delivery log. Failed deliveries are retried.
BRING EXTERNAL SERVICES
Keep the services you already use.
Store their keys as secrets and call them from your API.
Payments
Email
SMS
Search
Analytics
AI model APIsexternal calls
Your APIapi.acme.com/v1
Keys stored as secrets
LOGS
See every request.
Every call to your API is logged with its route, status and request ID. Filter by environment, status or route, then open a line to see what happened.
Logging in the docs →Environment production Status all Route /v1/* Search path, request ID or message
TIMEMETHODPATHSTATUSDURATIONREQUEST ID
14:02:31.418 GET /v1/orders/ord_8x2k 200 req_7f3a9c21
14:02:31.402 POST /v1/orders 201 req_7f3a9b0e
14:02:31.377 GET /v1/users/me 200 req_7f3a9a55
14:02:31.351 GET /v1/orders/ord_00zz 404 req_7f3a99c2
14:02:31.329 POST /v1/checkout 500 req_7f3a98f1
ROUTEPOST /v1/checkout
RELEASEv42
INSTANCEinstance 2
CALLERstorefront-web
DURATION— ms
Error: payment step failed · unhandled exception in checkout handlerView trace →Open release →
14:02:31.304 GET /v1/products?page=2 200 req_7f3a97d8
14:02:31.288 PATCH /v1/users/usr_4k1 200 req_7f3a96aa
METRICS
Know how your API is behaving.
Environment productionRange last hourIllustrative
Requests per secondILLUSTRATIVE
−60m −30m now
Concurrent requestsILLUSTRATIVE
−60m −30m now
Latency p50 / p95 / p99ILLUSTRATIVE
— p50— p95- - p99now
Error rateILLUSTRATIVE
−60m v42 deploy now
Cache hit ratioILLUSTRATIVE
−60m −30m now
Queue depthILLUSTRATIVE
−60m batch import now
TRACING[confirm availability]
Follow one request end to end.
A trace breaks a single request into the steps it took, so you can see where the time went — auth, cache, database or your own code.
SPAN
startend
TIMErequest
— ms
auth check — ms
cache lookupmiss — ms
db query
SELECT … FROM orders
— mscache write — ms
serialize response — ms
Bar widths are relative — illustrative, not measured.Opened from log line req_7f3a9c21
HEALTH CHECKS
Only healthy instances get traffic.
Stack53 calls your health endpoint on every instance. Unhealthy instances are removed from rotation until they pass again.
HEALTH CHECK
path /healthz expect 2xx interval [default interval] timeout [default timeout] unhealthy after [n] failed checksIllustrative configuration.
INSTANCES · PRODUCTIONrelease v42
instance 1Healthyin rotation
instance 2Healthyin rotation
instance 3Healthyin rotation
instance 4Failing /healthzremoved
Alert when an instance fails[confirm availability]
DEPLOYMENTS & ROLLBACKS
Ship often. Roll back fast.
Every push becomes a numbered release. Test it on staging, promote it to production, and go back to the previous release in one step.
Pushmain · a1f3c9e
Buildimage built
Testchecks passed
Deploy to staginghealth checks pass
Promote to productionsame build, no rebuild
RELEASES · PRODUCTION
v42 Add checkout retries Current · production
v41 Paginate product listing Previous
v40 Cache order lookups Previous
v39 Add PATCH /v1/users/:id Previous
$ stack53 deploy --env production # ✓ release v42 live on production $ stack53 rollback --to v41 # ✓ production: v42 → v41 # ✓ previous build reused, no rebuild
Illustrative — see the API reference for exact syntax.
RUNTIME & GATEWAY
Your code. Our gateway.
Your API runs as your own code. Requests reach it through a gateway that handles routing and protection first.
RUNTIME
[Supported runtimes][Supported runtimes][Supported runtimes]Containers [confirm availability]
DATABASE_URL•••••••• secret
CACHE_URL•••••••• secret
LOG_LEVELinfo
GATEWAY
RoutingAvailable*
Auth checksAvailable*
Rate limitsAvailable*
CORSAvailable*
Request transformationPlanned
API products & plansPlanned
MICROSERVICES & API-FIRST
One public door. Private rooms behind.
Expose a single API to the world and keep every other service on a private network — then design that API first and let every client build against it.
MICROSERVICES · PROJECT ACME
PUBLIC APIapi.acme.com
internet-facing PRIVATE NETWORK · NO PUBLIC ADDRESS
orders
billing
notifications
services talk privatelyAPI-FIRST DEVELOPMENTapi.acme.com/v1
GET/v1/orderslist ordersPOST/v1/orderscreate orderGET/v1/users/:idfetch user
01Design routes
02Build
03Test
04Deploy
CONSUMED BY Web appMobile appPartners
USE CASES
One API shape, many products.
iOS appmobile client
Android appmobile client
Your APIapi.acme.com/v1
Authentication
Database
Object Storage
Jobs
STACK53 PIECES IT USES
AuthenticationSign-in and sessions for app users, verified at your API.
DatabaseProfiles, content and app data behind your routes.
Object StoragePhoto and file uploads from the device.
JobsSend notifications and sync work in the background.
DEVELOPER EXPERIENCE
Four ways in.
Click, type, call or import — every surface manages the same projects.
Illustrative — see the API reference for exact syntax.Dashboardapp.stack53.com
acme / storefront
CLIstack53
$ stack53 deploy
✓ live on staging
$ stack53 logs
Platform APIapi.stack53.com/v1
GET /v1/projects
POST /v1/deployments
Bearer $STACK53_TOKEN
SDKs[Supported languages]
stack53.projects
.list()// wraps Platform API
COMING API testing in the dashboard Planned OpenAPI docs generation Planned
PLATFORM API vs APPLICATION API
Two APIs. Two different jobs.
One manages Stack53. The other is the product you build on it.
STACK53 PLATFORM APIYou call it
api.stack53.com/v1 PURPOSEManage your Stack53 resources
MANAGESProjects, deployments, databases
AUTHStack53 tokens
CALLED BYYou — scripts, CI, the CLI and SDKs
YOUR APPLICATION APIYour users call it
api.acme.com/v1 (your domain) PURPOSEThe API you build and host on Stack53
SERVESYour routes — orders, users, anything
AUTHWhatever you choose — user sessions, API keys
CALLED BYYour web app, mobile app, partners
Don’t confuse them. Your users never call api.stack53.com — and a Stack53 token never
belongs in your app. Your application API lives on your own domain.
SCALE WITH YOU
Same API from idea to scale.
You never migrate to a different platform. Stack53 adds what each stage needs, underneath the API you already have.
ILLUSTRATIVE · TRAFFIC OVER TIME
1 IDEA Create a project with an API, database and auth. APIDatabase
2 PROTOTYPE Deploy from your repository to staging. Environments
3 LAUNCH Custom domain, TLS and production. DomainsTLS
4 GROWTH Add cache, background jobs and rate limits. CacheJobs
5 HIGH CONCURRENCY More API instances and queues for bursts. InstancesQueues
6 MULTI-REGION Run in additional regions. Planned
Build your API once.
Let Stack53 grow with it.