openElement's server layer is Hono. API routes use standard Request/Response semantics and are suitable for serverless or edge runtime deployment.
Use platform primitives. Prefer Fetch, Request, Response over framework-specific transports.
Validate at boundaries. Parse and validate request bodies before business logic sees the data.
Declare runtime explicitly. Static pages can call APIs, but the APIs need a serverless or edge deployment target.
Place API routes in app/routes/api. Default-export a Hono app for complex APIs, or a plain function (ctx) => Response for simple endpoints. The context has request, params, env, and platform.
// app/routes/api/posts.tsimport { Hono } from 'hono'; const app = new Hono(); app.get('/', (c) => c.json([{ id: 1, title: 'Hello' }])); app.post('/', async (c) => { const body = await c.req.json(); return c.json({ id: 2, ...body }, 201); }); export default app;// app/routes/api/health.ts — simple endpoint, no Hono neededimport type { OpenElementApiContext } from '@openelement/core'; export default function GET(ctx: OpenElementApiContext) {return Response.json({ ok: true, mode: ctx.env.MODE ?? 'production' });}openElement does not mandate a validation library. Zod with @hono/zod-validator is a practical default.
@openelement/rpc provides type-safe client/server calling conventions. See RPC Guide.
SSG output is static files. API routes are part of the generated Hono app, but static hosting won't execute them. Deploy API routes via serverless adapters or platform functions when runtime behavior is needed.