Build an API service
Ship a long-lived HTTP API, webhook handler, or scheduled job on FlareX — the patterns FlareX picks and how to iterate.
Updated
Ready-to-deploy starting points live in the APIs & backends category and automations category — public JSON APIs, signed webhook handlers, and scheduled syncs.
If your system is "a thing other software talks to" rather than "a thing a user clicks on," it's an API service. FlareX runs these the same way it runs websites and bots — one container, public URL, encrypted secrets, real logs.
Common shapes
| Shape | Example |
|---|---|
| REST API | GET /users, POST /users backed by Postgres, JSON in/out |
| Webhook handler | "Receive Stripe webhooks, post to Slack" |
| Scheduled job | "Every morning at 8 UTC, email me a summary" |
| Background processor | "Pick jobs off a Redis queue, do the work, write results to the DB" |
| AI proxy | "A /summarize endpoint that calls Claude, caches by hash, returns JSON" |
What FlareX picks for you
Default stack for an API service is Node + Fastify + Zod for request validation. No GraphQL, no microservices — one process serving HTTP, which scales to a surprisingly large workload before you need to think about it.
For scheduled jobs, FlareX wires up an in-process scheduler (cron-style strings, no external tool needed). For background processing, it pulls in BullMQ backed by the workspace Redis.
Prompt template — REST API
A REST API with the following endpoints:
- GET /todos — list all todos for the authenticated user
- POST /todos — create a todo
- PATCH /todos/:id — toggle completion
- DELETE /todos/:id — delete
Backed by Postgres (workspace-shared DB).
Auth via a static API key in the `Authorization: Bearer <KEY>` header.
JSON in, JSON out.
Validate inputs with Zod and return 400 on bad data.
Prompt template — webhook handler
A webhook handler that:
- POST /stripe/webhook — receives Stripe events, verifies the signature
with STRIPE_WEBHOOK_SECRET, and:
- on customer.subscription.created → posts a Slack message via SLACK_WEBHOOK_URL
- on invoice.paid → writes a row to the `payments` table
- POST /github/webhook — receives GitHub push events, posts a summary to Discord
via DISCORD_WEBHOOK_URL
See Webhooks for the full pattern, including signature verification.
Prompt template — scheduled job
A scheduled job that runs every weekday at 09:00 UTC and:
1. Queries the `signups` table for everything created since the last run.
2. Builds a markdown summary.
3. Emails it to me via SMTP_URL.
Track the last-run timestamp in a small `_jobs` table so we don't double-send.
Returning JSON cleanly
FlareX defaults to a consistent error shape:
{ "error": "invalid_input", "message": "Field 'email' is required" }
Successful responses are the bare resource — { "id": 1, "title": "…" } — not wrapped in { data: … }. Ask for a different shape if you have a convention to match.
Rate limits
For any public-ish endpoint, ask for rate limiting up front:
Rate limit /summarize to 10 requests per minute per API key.
Return 429 with a Retry-After header when exceeded.
FlareX wires this up using @fastify/rate-limit backed by Redis.
Background work + queues
If a request needs to do something slow (call an LLM, scrape a page, generate a report), don't block the response. Use a queue:
On POST /reports, enqueue a "generate-report" job and return 202 with a
report_id. Generate the report in the background and write the result
to the `reports` table when done. Add GET /reports/:id so clients can
poll for status.
Tailing logs
Deployments → Logs streams everything in real time. The free plan retains nothing past the session; paid plans retain 3–14 days. See Deployments for the full log story.
Iterating
"Add a
Cache-Control: public, max-age=60header to GET /todos." "Bump the rate limit on /summarize to 30/min." "Add idempotency-key support to POST /payments."
What's next
- Webhooks — receive and verify webhook payloads
- 3rd-party APIs — call out to other services
- Databases — Postgres schemas, scoped roles
- Secrets — API keys, signing secrets