How to Build an API with Zo

Every Zo account comes with zo.space — a personal website with full React pages and API routes. The API routes are Hono endpoints that go live the moment your Zo creates them. No hosting, no deploy step, no server configuration. You describe what you want the endpoint to do, and it's running at a public URL within minutes.

This makes Zo one of the fastest ways to go from "I need an API" to "here's the URL." No Vercel setup, no AWS Lambda cold starts, no Docker containers. Just a conversation.

Your first endpoint

Your Zo writes the route, deploys it, and gives you the URL:

https://yourhandle.zo.space/api/hello

Test it:

curl https://yourhandle.zo.space/api/hello

You get back something like:

{ "message": "Hello!", "time": "2026-03-09T14:30:00Z" }

That's a live API endpoint. It's public, it's fast, and it's yours.

Webhook receivers

One of the most practical uses for zo.space API routes is receiving webhooks from external services. Webhooks are how services like Stripe, GitHub, Shopify, and Slack notify you when something happens. They send a POST request to a URL you provide — and that URL needs to be publicly accessible, always on, and ready to handle the payload.

Your Zo handles all of that.

Stripe webhook handler:

Your Zo creates the endpoint, sets up signature verification, and handles the payload parsing. Save your Stripe webhook secret in Settings > Advanced, then register the URL in your Stripe dashboard.

GitHub webhook handler:

This pairs well with scheduled agents. Set up a webhook that saves incoming data, then an agent that processes it periodically:

Data APIs

Build endpoints that serve data from your workspace files, databases, or external sources.

Status API — share your availability:

Other tools and services can hit this endpoint to check your availability programmatically. Your portfolio page can read from it to show a live "available / busy" indicator.

Data endpoint from workspace files:

Aggregated data endpoint:

Authentication

Public endpoints are fine for webhooks and read-only data. For anything sensitive, add authentication:

Bearer token auth:

Save the secret in Settings > Advanced. Now requests need an Authorization: Bearer <token> header.

API key in query parameter:

For more complex auth (OAuth, JWT), describe what you need and your Zo implements the pattern. It has access to the full Node.js ecosystem on your server.

Rate limiting

If your endpoint is public, protect it from abuse:

Connecting endpoints to your Zo's tools

Your API routes run on the same machine as your Zo. They can read workspace files, access environment variables, and call external services. This means your endpoints aren't limited to static responses — they can do real work.

Form handler that sends you a notification:

Put this behind a contact form on your portfolio page and every form submission triggers a text to your phone.

Endpoint that triggers an automation:

Now you can trigger your weekly report from a button, a cron job on another service, or a Slack slash command.

Iterating on your APIs

Your Zo can modify endpoints after they're deployed. Changes go live immediately:

• "Add a category parameter to my /api/quotes endpoint"
• "Change the rate limit to 100 requests per minute"
• "Add CORS headers so my frontend can call this endpoint"
• "Log all requests to /home/workspace/Data/api-access.log"
• "Add error handling — return a 500 with a message if the data file is missing"

Each change updates the live endpoint. No redeploy, no downtime.

When to use zo.space APIs vs self-hosted tools

zo.space API routes are best for:

• Personal endpoints and side projects
• Webhook receivers for services you use
• Quick prototypes that need a public URL
• Backends for your zo.space pages

For more complex automation workflows with visual editors and hundreds of pre-built integrations, consider self-hosting n8n on your Zo. n8n is better suited for multi-step workflows that chain several services together. zo.space API routes are better for custom endpoints that need specific logic.

Getting started

Build something you'll actually use:

Then try a webhook receiver, a data endpoint, or a form handler. Every endpoint you build is one less external service you depend on.