DEV Community: Jbee - codehooks.io

I Pointed Claude Code at My Hackathon API. It Built the Public Website

Jbee - codehooks.io — Tue, 03 Mar 2026 07:10:11 +0000

Part 2 — Using Claude Code CLI to add a public-facing hackathon website to the admin dashboard from Part 1. Participant signup, event browsing, project submissions — all inside the same project.

In Part 1, we used it to build Hackathon HQ — a hackathon management platform with six interconnected collections: events, teams, participants, submissions, judges, and scores. Five minutes from zero to a deployed admin dashboard.

But participants don't care about your admin panel. They want a website. A place to browse upcoming events, sign up, join a team, and submit their project.

The good news: the admin panel already has a complete REST API with auto-generated OpenAPI documentation. We're going to point Claude Code at that spec and let it build public-facing pages — right inside the same project.

The react-admin-dashboard template for Codehooks.io lets you spin up a complete admin panel for any domain — CRM, project management, inventory, ticketing, you name it. Describe your data to an AI, paste the JSON datamodel, and you get a production app with authentication, role-based access, dynamic forms, file uploads, related collections, and auto-generated REST API docs. One JSON file drives the entire stack: React frontend, serverless backend, NoSQL database.

What We're Adding

Public pages alongside the existing admin dashboard — same project, same backend, same deploy:

Public landing page — hero section, grid of open events (read-only, via API key)
Event detail page — event info, teams, schedule
Participant signup & login — external users create accounts and sign in
Submission form — authenticated participants submit their projects

Admins keep using the admin panel at /admin. Participants get a clean public site at /. One Codehooks project serves both.

┌──────────────────────────────────────┐
│  Hackathon HQ (one Codehooks project)│
│                                      │
│  /admin/*  → Admin dashboard (Part 1)│
│  /         → Public site (Part 2)    │
│                                      │
│  Public reads use x-apikey           │
│  Participant writes use JWT (login)  │
└──────────────────────────────────────┘

Screenshot of the finished website:

Prerequisites

The Hackathon HQ project from Part 1 (deployed and running)
At least one event created in the admin panel with status other than "Planning" (e.g. "Registration Open") — otherwise the public site will have nothing to show
Claude Code CLI installed (npm i -g @anthropic-ai/claude-code)
Node.js 18+

Step 1: Create an API Key for Public Read Access

Note: Throughout this article I use hackathonhq as my project name. Replace it with whatever you named your project in Part 1.

The public landing page needs to fetch events without requiring users to log in. Codehooks has built-in API key support. Create a token:

cd hackathonhq
coho add-token --readonly --description "Public website read access"

This key lets the public site fetch events and event details. Authenticated actions (signup, login, submitting projects) still go through the JWT auth system.

Step 2: Feed the OpenAPI Spec to Claude Code

Start Claude Code inside the hackathonhq project:

claude

First, let Claude Code understand the existing API:

> Read the OpenAPI spec at https://hackathonhq.api.codehooks.io/dev/openapi.json
  and summarize the available API endpoints. I want to add public-facing pages
  to this project for hackathon participants.

Claude Code fetches the spec and comes back with a full understanding of your API:

Events: GET /api/events with query filters and sorting
Teams: GET /api/teams with lookup references to events and participants
Submissions: POST /api/submissions with status tracking
Auth: POST /auth/login, POST /auth/logout, GET /auth/me
Query format: q for MongoDB-style filters, h for sort/limit/offset

It didn't hallucinate an API. It read the real one. Every field name, every enum value, every relationship — straight from your running backend.

Step 3: Add a Registration Endpoint

The admin panel from Part 1 only has login — admins create user accounts manually. For the public site, participants need to register themselves. Ask Claude Code to add it:

> Add a POST /auth/register endpoint to backend/index.js that lets new users
  sign up with username, email, and password. It should create a user with
  role "user", hash the password using the existing hashPassword function,
  check for duplicate usernames, and return the user info with a JWT cookie
  (same as the login endpoint). Make sure /auth/register is covered by the
  existing public auth bypass so it doesn't require authentication.

Claude Code reads the existing auth code in backend/index.js, sees the hashPassword function, the findUserByUsername helper, and the JWT cookie pattern from the login endpoint — then generates a registration endpoint that follows the exact same conventions.

Important: After adding this, deploy the backend so the endpoint is live:

npm run deploy

Step 4: Restructure the Routes

The admin dashboard currently lives at /. We need to move it and make room for public pages:

> I want to add public pages to this React app for hackathon participants.
  Move the existing admin dashboard routes under /admin/* (keep the existing
  Layout with sidebar). Add new public routes at the root:
  / → public landing page
  /events/:id → public event detail
  /signup → participant registration
  /login → participant login
  /submit → submission form (authenticated only)
  Create a PublicLayout component with a top navbar (no sidebar).
  Update App.jsx with both route groups.

Claude Code reads the existing App.jsx, Layout.jsx, and routing structure, then restructures everything. The admin dashboard keeps working exactly as before — just under /admin now. Public pages get their own clean layout.

Important: Make sure all admin routes are fully updated — including collection detail views. Links like /:collection/:id need to become /admin/:collection/:id, otherwise clicking into a record from the admin panel will land you on the public site. Tell Claude Code explicitly:

> Double-check that all internal navigation links in the admin dashboard
  (sidebar, list rows, breadcrumbs, detail views, "New" buttons) use the
  /admin prefix. A detail view at /:collection/:id should be
  /admin/:collection/:id. Test by clicking through from the admin sidebar
  to a collection list, then into a record detail.

After this change, the admin panel login moves to /admin/login. Bookmark it — you'll need it to manage events and review submissions.

Step 5: Build the Landing Page

> Create the public landing page at frontend/src/pages/public/LandingPage.jsx.
  Hero section with "Hackathon HQ" title and tagline. Below it, a responsive
  grid of event cards fetched from GET /api/events. Filter out events where
  status is "Planning" — show all other events (Registration Open, In Progress,
  Judging, Completed). Use an x-apikey header for authentication (the key is
  stored in an environment config). Each card shows name, dates, location,
  status badge, and a "View Details" link. Use shadcn Card components.
  Make it look great.

Claude Code generates the page. Notice what it gets right because it read the spec:

// Public reads use the API key — no login required
const res = await fetch('/api/events?' + new URLSearchParams({
  q: JSON.stringify({
    status: { $ne: 'Planning' }
  }),
  h: JSON.stringify({ $sort: { startDate: -1 } })
}), {
  headers: { 'x-apikey': API_KEY }
});

No guessing. No placeholder endpoints. The actual API format from your OpenAPI spec. The x-apikey header gives read access without requiring login. The filter excludes "Planning" events so only published events appear — everything from "Registration Open" through "Completed".

Tip: If the landing page shows no events, check your admin panel — make sure at least one event has a status other than "Planning".

Step 6: Event Detail Page

> Create an event detail page at frontend/src/pages/public/EventPage.jsx.
  Route: /events/:id. Fetch the event from GET /api/events/:id using the
  x-apikey header. Display name, description, dates, location, prizes
  (render as markdown), and banner image. Below the details, fetch teams
  for this event using GET /api/teams with query {"event._id": "<eventId>"}.
  Show teams as cards with team name, track, and member count.
  Add a "Sign up to participate" call-to-action.

Claude Code understands the lookup relationship format (event._id) because it saw the x-lookup definitions in the spec. It builds the page with the correct query structure, markdown rendering for the prizes field, and responsive team cards.

Step 7: Participant Signup and Login

Now we need authenticated actions. Participants sign up and log in through the auth system:

> Create a signup page at frontend/src/pages/public/SignupPage.jsx and a
  login page at frontend/src/pages/public/LoginPage.jsx. Signup calls
  POST /auth/register with username, email, and password. Login calls
  POST /auth/login. Both use credentials: 'include' for the httpOnly
  JWT cookie. On success, redirect to the landing page. Create an
  AuthContext that checks GET /auth/me on mount and provides user state.
  Update the public navbar: show Login/Sign Up buttons when logged out,
  show username + Logout when logged in.

One prompt. Claude Code creates:

AuthContext.jsx — wraps the app, checks session on load
SignupPage.jsx — registration form with validation
LoginPage.jsx — login form matching the app's style
Updated PublicNavbar.jsx — auth-aware navigation

Participants sign up and log in at /signup and /login. Admins use /admin/login to access the admin panel. Same auth system, different entry points.

Step 8: Submission Form

> Create a submission page at frontend/src/pages/public/SubmitPage.jsx.
  Only accessible when logged in — redirect to /login otherwise. The form
  posts to POST /api/submissions with: title, description, event (dropdown
  fetched from /api/events), team (dropdown filtered by selected event),
  track (enum from the spec), demoUrl, repoUrl, videoUrl. Use the JWT
  cookie for authentication (credentials: 'include'). Reference the
  Submission schema from the OpenAPI spec for field types.

Claude Code reads the Submission component schema from the spec and knows every field, every enum value (Draft, Submitted, Under Review, Finalist, Winner, Honorable Mention), and every URL format. The event dropdown filters teams dynamically — pick an event, the team dropdown updates.

A participant submits their project here. An admin sees it immediately in the admin dashboard at /admin. Same data, two interfaces.

The Iterative Part

AI coding is not one prompt and done. Here's the back-and-forth that made it real:

> The event cards need a badge showing the event status. Use the shadcn
  Badge component with different colors for each status.

> Add a countdown timer to events that are "Registration Open" — show
  days until startDate.

> The submit page should show a success message after submission with
  a link back to the event page.

Each time, Claude Code reads the existing files, understands the context, and makes targeted changes. It doesn't start over. It builds on what's already there.

Step 9: Test and Deploy

Test locally:

cd frontend
npm run dev

Open http://localhost:5173. Here's your test checklist:

Landing page — events with status other than "Planning" should appear. No login needed.
Event detail — click an event card, see details and teams.
Sign up — create a participant account at /signup.
Submit — log in, go to /submit, submit a project.
Admin panel — visit /admin/login, log in as admin/admin, verify the submission appears.

When it looks right, deploy — same command as always:

cd ..
npm run deploy

One project. One deploy. Both the admin dashboard and the public site go live together.

Project: hackathonhq-jvel  Space: dev
Deployed Codehook successfully! 🙌 

Check your logs with: coho logs --follow

What We Built

One project, two interfaces:

	Admin Dashboard (Part 1)	Public Website (Part 2)
Routes	`/admin/*`	`/`
Login URL	`/admin/login`	`/login`
Purpose	Manage hackathon data	Participant-facing site
Read access	JWT (admin/user roles)	API key (no login needed)
Write access	JWT (admin role)	JWT (participant login)
Built with	JSON datamodel	Claude Code + OpenAPI spec
Time	5 minutes	~30 minutes

Visitor browses events ──→ x-apikey ──→ Read-only access
Participant submits    ──→ JWT login ──→ Write access
Admin manages data     ──→ JWT login ──→ Full admin access

Key Takeaways

OpenAPI specs are AI multipliers. Your backend already generates API docs. Point an AI coding tool at them and it writes frontend code that actually calls the right endpoints with the right parameters. The spec is more accurate than anything you'd type in a prompt.

Same project, two audiences. The admin panel and the public site live in the same codebase, share the same backend, and deploy together. API keys handle public reads. JWT handles authenticated writes. Clean separation, zero duplication.

Claude Code is iterative. It's not a magic "build my app" button. It's a conversation. Describe, generate, review, refine. Each round it reads what it already built and adds to it. The OpenAPI spec keeps it grounded in your real API.

Get Started

The admin dashboard template is open source:

GitHub: react-admin-dashboard

npm i -g codehooks @anthropic-ai/claude-code
coho create hackathonhq --template react-admin-dashboard
cd hackathonhq
claude

Part 1 gives you the admin panel. Part 2 — you, Claude Code, and an OpenAPI spec. Same project, new audience.

Missed Part 1?

This article builds on the admin backend from Part 1. If you haven't read it yet, start there — in five minutes you'll have a deployed hackathon management platform with a full REST API, and you'll be ready to follow along here.

Read Part 1: I Asked AI to Design a Hackathon App. 5 Minutes Later It Was in Production.

What would you add next? A public leaderboard? Real-time score updates? A sponsor portal? Drop your ideas in the comments.

I Asked AI to Design a Hackathon App. 5 Minutes Later It Was in Production.

Jbee - codehooks.io — Sun, 01 Mar 2026 10:36:04 +0000

Hackathon season is here and you've volunteered to organize one. Now you need a system to track events, teams, participants, submissions, judges, and scores. You could spend a week building it. Or you could describe it to an AI, paste some JSON, and have a production app running in five minutes.

I chose five minutes. Here's how.

What We're Building

Hackathon HQ — a complete hackathon management platform with six interconnected collections:

Events — hackathon details, dates, tracks, and banner images
Participants — hackers with skills, experience level, GitHub handle, and T-shirt size
Teams — linked to an event, with multi-select member assignment
Submissions — projects linked to teams and events, with demo URLs, screenshots, and status tracking (Draft through Winner)
Judges — assigned to events, with expertise areas and bios
Scores — judges rate submissions on innovation, execution, impact, and presentation

An event's detail page shows its teams, submissions (with "Winners" and "Finalists" filter buttons), and assigned judges. A submission shows all its judge scores. Everything is cross-linked, searchable, and sortable.

Se the above screenshot of the finished hackathon admin dashboard.

The react-admin-dashboard template for Codehooks.io lets you spin up a complete admin panel for any domain — CRM, project management, inventory, ticketing, you name it. Describe your data to an AI, paste the JSON datamodel, and you get a production app with authentication, role-based access, dynamic forms, file uploads, related collections, and auto-generated REST API docs. One JSON file drives the entire stack: React frontend, serverless backend, NoSQL database.

Prerequisites

Node.js 18+
A free Codehooks.io account
Any AI assistant (ChatGPT, Claude, Gemini — they all work)

Step 1: Scaffold the Project (2 minutes)

Install the Codehooks CLI and create a new project from the template:

npm i -g codehooks
coho login
coho create hackathonhq --template react-admin-dashboard
cd hackathonhq
mv config.json backend

Set the JWT secrets (used for authentication):

coho set-env JWT_ACCESS_TOKEN_SECRET $(openssl rand -hex 32)
coho set-env JWT_REFRESH_TOKEN_SECRET $(openssl rand -hex 32)

Install dependencies:

npm run install:all

Update frontend/vite.config.js with your project URL (run coho info to find it):

const BACKEND_URL = 'https://YOUR_PROJECT.api.codehooks.io/dev';

Deploy the template with the default datamodel:

npm run deploy

Get your project URL from your YOUR_PROJECTe.g. hackathonhq-jvel

coho info --projectname hackathonhq-jvel --space dev

In my project I see these endpoints:

API endpoints: 

https://serendipitous-canyon-61e2.codehooks.io
https://hackathonhq-jvel.api.codehooks.io/dev

You now have a working admin dashboard at your project syntetic URL (serendipitous-canyon-61e2). Log in with admin / admin.

The name: Project Management is just the default template that is installed when starting a new project.

Step 2: Ask AI to Design Your Hackathon App (1 minute)

This is the magic part.

Open your deployed app, navigate to the Datamodel page (admin only), and click the "Copy Prompt" button. This copies a detailed prompt to your clipboard that describes the entire datamodel format — field types, relationships, validation rules, everything the AI needs to generate valid output.

Now open your favorite AI assistant and paste the prompt. Add your request:

Design a hackathon management system. I need: Events (name, description, status pipeline from Planning to Completed, dates, location, max teams, prizes as markdown, banner image). Participants (name, email, GitHub username, primary skill enum, experience level, photo, t-shirt size). Teams belong to an event with multi-select members from participants, a track enum (Web, Mobile, AI/ML, DevTools, Open Innovation, Social Impact), repo URL, and project description. Submissions belong to an event and team, with project title, description, demo/repo/video URLs, screenshot upload, submitted timestamp, and status (Draft through Winner). Judges belong to an event with expertise area and bio. Scores link a judge to a submission with 1-10 ratings for innovation, execution, impact, presentation, plus a total and notes. Events should show related teams, submissions (with Winner and Finalist filter buttons), and judges. Submissions should show their judge scores. Make the json string easy to copy to clipboard.

The AI returns a complete JSON datamodel. Here's the key part — look at how relationships are defined:

{
  "app":  {
    "title":  "Hackathon Management",
    "subtitle":  "Manage events, participants, teams, submissions, judges and scoring",
    "icon":  "trophy"},
  "collections":  {
    "events":  {
      "label":  "Events",
      "icon":  "calendar",
      "schema":  {
        "type":  "object",
        "required":  [
          "name",
          "status",
          "startDate",
          "endDate"],
        "properties":  {
          "name":  {
            "type":  "string",
            "title":  "Event Name",
            "minLength":  1
          },
          "description":  {
            "type":  "string",
            "title":  "Description",
            "format":  "textarea"},
          "status":  {
            "type":  "string",
            "title":  "Status",
            "enum":  [
              "Planning",
              "Open for Registration",
              "In Progress",
              "Judging",
              "Completed"],
            "default":  "Planning"},
          "startDate":  {
            "type":  "string",
            "title":  "Start Date",
            "format":  "date"},
          "endDate":  {
            "type":  "string",
            "title":  "End Date",
            "format":  "date"},
          "location":  {
            "type":  "string",
            "title":  "Location"},
          "maxTeams":  {
            "type":  "integer",
            "title":  "Max Teams",
            "minimum":  1,
            "default":  50
          },
          "prizes":  {
            "type":  "string",
            "title":  "Prizes (Markdown)",
            "format":  "textarea"},
          "banner":  {
            "type":  "string",
            "title":  "Banner Image",
            "format":  "image",
            "x-accept":  ".jpg,.jpeg,.png,.webp"}
        }
      },
      "listFields":  [
        "name",
        "status",
        "startDate",
        "endDate",
        "location",
        "maxTeams"],
      "searchFields":  [
        "name",
        "description",
        "location"],
      "defaultSort":  {
        "startDate":  -1
      },
      "relatedCollections":  [
        {
          "collection":  "teams",
          "foreignKey":  "event._id",
          "title":  "Teams",
          "displayFields":  [
            "name",
            "track",
            "repoUrl"],
          "sort":  {
            "name":  1
          },
          "allowCreate":  true
        },
        {
          "collection":  "submissions",
          "foreignKey":  "event._id",
          "title":  "Submissions",
          "displayFields":  [
            "projectTitle",
            "team",
            "status",
            "submittedAt"],
          "sort":  {
            "submittedAt":  -1
          },
          "allowCreate":  true,
          "filters":  [
            {
              "field":  "status",
              "value":  "Finalist",
              "label":  "Finalists",
              "active":  false
            },
            {
              "field":  "status",
              "value":  "Winner",
              "label":  "Winners",
              "active":  false
            }
          ]
        },
        {
          "collection":  "judges",
          "foreignKey":  "event._id",
          "title":  "Judges",
          "displayFields":  [
            "name",
            "expertiseArea",
            "email"],
          "sort":  {
            "name":  1
          },
          "allowCreate":  true
        }
      ]
    },
    # CLIPPED JSON CONTENT HERE
}

Three things to notice:

x-lookup on the event field creates a searchable dropdown linking teams to events
members as an array with x-lookup creates a multi-select — search participants by name or email, add multiple to a team
relatedCollections with filters on the event gives you toggle buttons to show only Winners or Finalists

Switch to the JSON tab in the datamodel editor, paste the AI-generated JSON, and click Save.

That's it. Your hackathon organizer is live. No redeployment. No backend changes. Just JSON.

Step 3: Explore What You Got

Refresh the page. The sidebar now shows six collections — Events, Teams, Participants, Submissions, Judges, Scores — each with its own icon.

Let's walk through what the template auto-generated from that JSON.

Dynamic Forms with Validation

Click "+ New" on Events. You get a full form: text inputs, an enum dropdown for status, date pickers, a markdown textarea for prizes, and an image uploader for the event banner. Required fields are marked, validation runs on save.

Multi-Select Team Members

Open a team form. The Members field lets you search participants (add some here first) by name or email and add multiple people. Each member shows as a tag with their name and primary skill. This comes from defining members as an array with x-lookup — the template handles the rest.

Searchable Lookups

On the submission form, the Event and Team fields are searchable dropdowns. Start typing and it live-searches the target collection. This comes from x-lookup in the schema — zero extra code.

Related Collections with Filters

Open an event's detail page. Below the event details, you see three sections: Teams, Submissions, and Judges. Submissions has toggle buttons for "Winners" and "Finalists" — click one to filter instantly. Each section has a "+ New" button that pre-fills the event reference.

Judge Scores on Submissions

Open a submission. Below the project details, you see Judge Scores — every score entry from every judge, with their individual ratings and totals. This is another relatedCollections definition, and it required zero code to set up.

Activity Log

Every action across all collections is automatically logged. Navigate to the Activity page to see who created which teams, when submissions were updated, and who assigned scores.

Auto-Generated API Documentation

Navigate to https://your-app-url.codehooks.io/docs to get a full Swagger UI with interactive API docs — generated automatically from your datamodel. Every collection has documented CRUD endpoints. Need to build a public submission form or a participant registration page? The API is already there.

Dark Mode

Toggle the theme in the sidebar. Because every hackathon needs a dark mode.

How It Works

The architecture is straightforward: one JSON drives everything.

Your datamodel defines collections, field schemas, relationships, and UI configuration. The backend validates all writes against the schema. The frontend fetches the datamodel at runtime and renders forms, lists, and relationships dynamically.

The datamodel lives in the database — not in a file. The initial datamodel.json seeds the first deployment. After that, every change goes through the visual editor or API, with full version history and one-click rollback. Schema changes never require redeployment.

datamodel.json (seed) ──> Database (versioned)
                              │
                    ┌─────────┴─────────┐
                    ▼                   ▼
              Backend               Frontend
         (validates writes)    (renders UI dynamically)

Tech stack: React 18, Tailwind v4, and shadcn/ui on the frontend. Codehooks.io serverless Node.js with a NoSQL datastore on the backend. JWT auth with httpOnly cookie sessions. One command deploys everything.

Ready-Made Examples

The template ships with example datamodels:

Example	Collections	Highlights
Hackathon	Events, Teams, Participants, Submissions, Judges, Scores	Multi-lookup, filters, cross-references
CRM	Companies, Contacts, Deals, Activities	Lookups, related lists, stage filters
Project Management	Members, Projects, Milestones, Tasks	Tree view, multi-lookup teams
Product Catalog	Categories, Suppliers, Products, Parts	Nested tree views, bill of materials
Product CMS	Pages, Products, Features	Page hierarchy, content management

Copy any JSON into your datamodel.json, deploy, and you have a working app.

Get Started

The full template is open source:

GitHub: react-admin-dashboard

npm i -g codehooks
coho create myapp --template react-admin-dashboard

Five minutes from now, you could have a production admin dashboard running. No CRUD boilerplate. No auth plumbing. No form builders.

Describe what you need. Let AI write the JSON. Ship it.

What would you build with this? I'm curious what datamodels people come up with. Drop your ideas in the comments.

I Vibe Coded a Full-Stack React App in 90 Seconds — Here's Why the Stack Matters

Jbee - codehooks.io — Thu, 12 Feb 2026 09:08:02 +0000

I opened a terminal, described what I wanted to an AI agent, and 90 seconds later a full-stack todo app was live on the internet. React frontend, REST API, database, Swagger docs — all deployed to a single URL.

No boilerplate repos cloned. No config files hand-written. I just talked to Claude Code, and it built the whole thing.

But here's what I learned: vibe coding is only as fast as the stack allows it to be. The AI agent was fast. What made it instant was that the platform eliminated the usual friction points.

What is vibe coding?

You describe what you want in natural language. An AI agent writes the code, runs the commands, tests the result, and iterates. You steer — it executes.

My prompt was simple:

"Build a todo app. React frontend, Codehooks backend with a CRUD API. Deploy everything."

The agent planned the approach, generated 6 files, installed dependencies, built the frontend, and deployed — all without me writing a single line of code. I watched it happen in real time.

One thing that made this seamless: I'm using the Codehooks plugin for Claude Code with the codehooks-backend skill. The plugin gives the agent full knowledge of the Codehooks.io API — routing, database operations, static hosting, queues, cron jobs — so it generates correct, deployable code on the first try without hallucinating APIs that don't exist.

But the interesting part isn't the AI. It's what happens when you pair vibe coding with a stack that has almost zero ceremony.

The friction that kills vibe coding

Most full-stack setups fight against the speed that vibe coding enables:

Separate frontend/backend repos — the agent has to context-switch between projects
CORS configuration — the agent generates code, deploys it, hits a CORS wall, debugs, redeploys
Docker + CI/CD — every deploy takes minutes, breaking the flow
Infrastructure config — Terraform, nginx, environment variables pointing services at each other

The AI can handle all of this. But every layer of ceremony adds time, and time is the enemy of the vibe. You want the agent to spend its cycles on your app, not on gluing infrastructure together.

What zero-friction looks like

I used Codehooks.io — frontend and backend deploy together, same origin, same command. Here's the entire backend the agent generated:

import { app } from 'codehooks-js';
import { z } from 'zod';

const TodoSchema = z.object({
  title: z.string().min(1),
  completed: z.boolean().default(false)
});

app.crudlify({ todos: TodoSchema }, { prefix: '/api' });

app.auth('/*', (req, res, next) => next());

app.static({ route: '/', directory: '/static',
  default: 'index.html', notFound: '/index.html' });

export default app.init();

From that Zod schema, crudlify() auto-generates six REST endpoints with validation. app.static() serves the React build. One deploy command puts both live on the same URL.

The agent didn't have to:

Configure CORS (same origin — it doesn't exist)
Set up a reverse proxy (static files and API share one server)
Write a Dockerfile (serverless — there's nothing to containerize)
Create a CI pipeline (one coho deploy, 5 seconds to live)

That's why 90 seconds was enough. The agent spent all its time on the app, not the platform.

The vibe coding session, in real time

Here's how the prompts flowed:

Prompt 1: "Build a todo app with React and Codehooks"
The agent planned, generated the backend (Zod schema + crudlify), built the React frontend (add, toggle, delete todos), and deployed. First deploy: under 90 seconds.

Prompt 2: "Add OpenAPI docs and Swagger"
One line added — app.openapi(). Since the API was already schema-driven, Swagger docs were auto-generated. Deployed in 5 seconds.

Prompt 3: "Add a cron job that empties todos every hour"
Two lines:

app.job('0 * * * *', async () => {
  const conn = await Datastore.open();
  await conn.removeMany('todos', {});
});

No external scheduler. No crontab. Just deploy.

Prompt 4: "Add a link to the docs as a footer"
The agent edited the React component, rebuilt, redeployed. Done.

Each iteration followed the same loop: prompt → generate → deploy → verify. The deploy step never took more than 5 seconds, so the feedback loop stayed tight.

Why the single-origin architecture matters for vibe coding

When the AI agent generates a fetch('/api/todos') call in React, it just works — in local dev (Vite proxy) and in production (same origin). There's no moment where the agent has to stop and think about which URL to use, whether CORS is configured, or whether the frontend and backend are on the same version.

This sounds minor. It's not. Every eliminated decision point means fewer failure modes for the agent, which means fewer retry loops, which means faster results.

The same principle applies to schema-driven APIs. When the agent defines a Zod schema, it gets validation, REST endpoints, and API docs from that single source of truth. There's no drift between what the code does and what the docs say, because they're generated from the same place.

The final result

~200 lines of code. 6 files. One URL.

What	Where
Todo app	luminous-grove-f487.codehooks.io
API docs	luminous-grove-f487.codehooks.io/docs

The takeaway

Vibe coding doesn't just change how you write code. It changes what you should optimize for in your stack. The old trade-offs — "this framework has more features" vs. "this one is simpler" — shift when an AI is doing the typing.

What matters now:

Low ceremony — fewer config files means fewer places the agent can get stuck
Fast deploys — tight feedback loops keep the vibe alive
Same origin — eliminates an entire class of bugs the agent would otherwise have to debug
Schema-driven — one definition, multiple outputs (API, validation, docs)

The best stack for vibe coding isn't the one with the most features. It's the one with the least friction between "I want this" and "it's live."

Stop Writing OpenAPI Specs by Hand

Jbee - codehooks.io — Mon, 02 Feb 2026 13:10:45 +0000

Writing API documentation sucks. You build an endpoint, then spend 20 minutes writing YAML that's outdated by your next commit.

What if your docs wrote themselves?

The Problem

OpenAPI/Swagger is great for API consumers. But maintaining specs manually means:

Duplicating schema definitions
Docs drifting out of sync with code
Tedious YAML editing for every endpoint

The Solution: Generate from Code

With Codehooks.io, define your schema once and get full OpenAPI 3.0 docs automatically:

import { app } from 'codehooks-js';
import { z } from 'zod';

const todoSchema = z.object({
  title: z.string().min(1).max(200),
  completed: z.boolean().default(false),
  priority: z.enum(['low', 'medium', 'high'])
});

// Enable OpenAPI + Swagger UI
app.openapi({
  info: { title: 'Todo API', version: '1.0.0' }
});

// Auto-generate CRUD endpoints
app.crudlify({ todos: todoSchema });

export default app.init();

Deploy, then visit /docs — you get a fully interactive Swagger UI with all 8 CRUD endpoints documented.

Custom Routes? No Problem

For endpoints beyond CRUD, use the openapi() middleware:

import { app, openapi } from 'codehooks-js';

app.get('/stats',
  openapi({
    summary: 'Get statistics',
    tags: ['Analytics'],
    responses: {
      200: { description: 'Stats retrieved' }
    }
  }),
  async (req, res) => {
    res.json({ total: 42 });
  }
);

You can even pass Zod schemas directly — they auto-convert to JSON Schema:

app.post('/users',
  openapi({
    summary: 'Create user',
    requestBody: {
      content: {
        'application/json': { schema: UserSchema }
      }
    }
  }),
  handler
);

Key Features

Zod, Yup, JSON Schema — all supported
Swagger UI at /docs — with authentication support
Filter endpoints — hide internal routes from public docs
Zero duplication — one schema for validation AND documentation

Try It

npm install codehooks-js@latest

Add app.openapi() before app.crudlify(), deploy with coho deploy, and your docs are live.

No more YAML. No more drift. Just code.

Full docs: codehooks.io/docs/openapi-swagger-docs

What's your current approach to API documentation? Do you maintain OpenAPI specs manually or generate them? Let me know in the comments!

Stop Fighting Stripe's Usage API: Build Simple Metering That Just Works

Jbee - codehooks.io — Fri, 16 Jan 2026 13:09:26 +0000

TL;DR: Stripe's usage-based billing API is overcomplicated. Instead of wrestling with meters, meter events, and usage records, just capture your own usage data and create invoices directly when the billing period ends.

The Stripe Usage API Pain

Don't get me wrong - Stripe is fantastic. Their payment processing, subscriptions, and checkout are best-in-class. I've used Stripe for years and recommend it to everyone.

But their usage-based billing API? That's where things get weird.

If you've ever tried to implement usage-based billing with Stripe, you know the frustration.

First, there's the terminology soup: Meters, Meter Events, Usage Records - three different concepts just to track "customer used X". Wait, there's also "Usage Reporting" and the "Billing Meter Events API". Which one do you use? The docs bounce you between these pages like a pinball machine, and half the examples are deprecated.

Then you discover the aggregation limitations. Stripe meters only support sum and count_distinct. Need max for peak storage billing? avg for response time SLAs? min for guaranteed minimums? You're on your own.

Here's what really hurts: events are write-only. Once you send a meter event, you can't query it back. Made a mistake? Sent duplicates? You won't know until the invoice looks wrong. And when a customer disputes a charge, good luck - aggregation happens in Stripe's black box with zero visibility into how totals are calculated.

Deduplication is entirely your problem. Network hiccup caused a retry? You might double-bill your customer. Stripe's idempotency keys help, but you're responsible for generating and managing them.

Want weekly billing cycles? Custom 30-day periods? Real-time usage dashboards for your customers? The API isn't built for that. And don't even think about changing a meter's configuration - want a different aggregation? Create a new meter. Rename an event? New meter. It's append-only all the way down.

A Better Way: Own Your Metering

What if you just:

Captured usage events in your own database
Aggregated them your way (hourly, daily, monthly - whatever you need)
Created Stripe invoices when you're ready

No mysterious black box. No "why is this number wrong?" No vendor lock-in on your core business data.

And here's the kicker: this pattern works with any payment provider - Stripe, PayPal, Paddle, LemonSqueezy, or even your own invoicing system. You own the metering, you choose where to send the bill.

The Solution: Self-Hosted Usage Metering

I built a serverless metering template that does exactly this:

Your App  →  Metering API  →  Webhook  →  Invoice

Configure What to Track

Define your metrics and aggregation in systemconfig.json:

{
  "periods": ["monthly"],
  "events": {
    "api.calls": { "op": "sum" },
    "storage.bytes": { "op": "max" },
    "compute.seconds": { "op": "sum" }
  },
  "webhooks": [{
    "url": "https://your-app.com/webhooks/create-invoice",
    "secret": "whsec_your_secret",
    "enabled": true
  }]
}

That's it. Three metrics, monthly aggregation, webhook when the period ends.

Capture Usage

Now your app sends usage events as they happen:

// Single event
await fetch('https://your-metering.codehooks.io/usage/api.calls', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json', 'x-apikey': API_KEY },
  body: JSON.stringify({
    customerId: 'sub_ABC123',  // Use Stripe subscription ID!
    value: 1
  })
});

// Or batch for high-volume
await fetch('https://your-metering.codehooks.io/usagebatch', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json', 'x-apikey': API_KEY },
  body: JSON.stringify([
    { eventType: 'api.calls', customerId: 'sub_ABC123', value: 1 },
    { eventType: 'storage.bytes', customerId: 'sub_ABC123', value: 50000 }
  ])
});

Pro tip: Use the Stripe subscription ID as customerId. This makes invoice creation trivial.

Get the Webhook

When a period completes (e.g., end of month), you get a webhook:

{
  "type": "aggregation.completed",
  "customerId": "sub_ABC123",
  "period": "monthly",
  "data": {
    "periodStart": "2025-01-01T00:00:00.000Z",
    "periodEnd": "2025-01-31T23:59:59.999Z",
    "events": {
      "api.calls": 15420,
      "storage.bytes": 1073741824,
      "compute.seconds": 3600
    }
  }
}

Creating the Stripe Invoice

Now the easy part - turn that webhook into an invoice. Here's a Node.js example, but this works in any language - Python, Go, Ruby, whatever your stack uses:

// webhook-handler.js (Node.js example)
const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

app.post('/webhooks/create-invoice', async (req, res) => {
  // Verify webhook signature (HMAC-SHA256)
  if (!verifySignature(req)) {
    return res.status(401).send('Invalid signature');
  }

  const { customerId, period, data } = req.body;

  // customerId IS the Stripe subscription ID
  const subscriptionId = customerId;

  // Get subscription to find the customer
  const subscription = await stripe.subscriptions.retrieve(subscriptionId);

  // Add fixed monthly plan fee
  await stripe.invoiceItems.create({
    customer: subscription.customer,
    amount: 4900,  // $49.00 base plan
    currency: 'usd',
    description: "`Pro Plan - ${data.periodStart.slice(0,7)}`"
  });

  // Add usage-based charges
  const pricing = {
    'api.calls': 0.001,           // $0.001 per call
    'storage.bytes': 0.00000001,  // $0.01 per GB
    'compute.seconds': 0.0001     // $0.0001 per second
  };

  for (const [metric, value] of Object.entries(data.events)) {
    const amount = Math.round(value * pricing[metric] * 100); // cents

    if (amount > 0) {
      await stripe.invoiceItems.create({
        customer: subscription.customer,
        amount,
        currency: 'usd',
        description: "`${metric}: ${value.toLocaleString()} units`"
      });
    }
  }

  // Create and finalize the invoice
  const invoice = await stripe.invoices.create({
    customer: subscription.customer,
    auto_advance: true,  // Auto-finalize and send
    collection_method: 'charge_automatically'
  });

  console.log(`Created invoice ${invoice.id} for ${subscriptionId}`);
  res.json({ invoiceId: invoice.id });
});

That's it. No meters. No meter events. No usage records. Just data you control and invoices that make sense.

Why This Is Better

Stripe Usage API	Self-Hosted Metering
Data lives in Stripe	Data lives in YOUR database
Limited aggregation (sum only)	7 operations: sum, avg, min, max, count, first, last
Fixed periods	Flexible: hourly, daily, weekly, monthly, yearly
Hard to debug	Query your events anytime
Vendor lock-in	Portable - it's just JSON
Complex setup	Deploy in 5 minutes

Get Started

First, create a free account at codehooks.io if you don't have one.

# Create your metering backend
npx codehooks create mymetering --template saas-metering-webhook
cd mymetering

# Configure your events
vim systemconfig.json

# Deploy
npx codehooks deploy

# Start sending events
curl -X POST https://your-project.codehooks.io/usage/api.calls \
  -H "x-apikey: YOUR_KEY" \
  -d '{"customerId":"sub_ABC123","value":1}'

The full template includes:

Batch event capture (POST /usagebatch)
Configurable aggregation periods and operations
HMAC-signed webhooks
Event querying API
Cron-based batch processing

Check out the full source code and stop fighting with Stripe's usage API.

What's your experience with usage-based billing? Drop a comment below - I'd love to hear your war stories!

Built with Codehooks.io - Deploy serverless micro backends in seconds

I Built My Own Mailchimp Alternative in 200 Lines of Code

Jbee - codehooks.io — Wed, 31 Dec 2025 13:03:06 +0000

Ever looked at your Mailchimp bill and thought "I could build this"?

I did. And I was right.

The Problem

I needed drip emails for my SaaS. Simple 3-step onboarding sequence. Mailchimp wanted $85/month for 5k subscribers. ConvertKit wanted $79/month. ActiveCampaign wanted... let's not talk about it.

For what? Sending time-delayed emails. That's it.

The Solution

Built my own with Codehooks.io (serverless Node.js platform). Total cost: $39/month for infrastructure + email sending. And I own everything.

Here's the entire architecture:

// 1. Config file defines your sequence
{
  "workflowSteps": [
    {
      "step": 1,
      "hoursAfterSignup": 24,
      "template": {
        "subject": "Welcome! 🎉",
        "heading": "Hi {{name}}!",
        "body": "Thanks for signing up..."
      }
    },
    { "step": 2, "hoursAfterSignup": 96, ... },
    { "step": 3, "hoursAfterSignup": 264, ... }
  ]
}

// 2. Cron job finds subscribers ready for next email
app.job('*/15 * * * *', async (req, res) => {
  const conn = await Datastore.open();

  for (const stepConfig of workflowSteps) {
    const cutoffTime = new Date(now - stepConfig.hoursAfterSignup * 60 * 60 * 1000);

    // Stream subscribers (constant memory usage)
    await conn.getMany('subscribers', {
      subscribed: true,
      createdAt: { $lte: cutoffTime }
    }).forEach(async (subscriber) => {
      if (!subscriber.emailsSent?.includes(stepConfig.step)) {
        // Atomically mark as sent
        const updated = await conn.updateOne(
          'subscribers',
          { _id: subscriber._id, emailsSent: { $nin: [stepConfig.step] } },
          { $push: { emailsSent: stepConfig.step } }
        );

        if (updated) {
          await conn.enqueue('send-email', { subscriberId: subscriber._id, step: stepConfig.step });
        }
      }
    });
  }
});

// 3. Queue worker sends the email
app.worker('send-email', async (req, res) => {
  const { subscriberId, step } = req.body.payload;
  const template = await getTemplate(step);
  await sendEmail(subscriber.email, template.subject, generateHTML(template));
  res.end();
});

That's it. Three pieces:

Config file - Define your steps
Cron job - Find subscribers ready for next email
Queue worker - Send it

Why This Actually Works

Streaming Architecture

Instead of loading all subscribers into memory:

// ❌ Memory issues with 50k+ subscribers
const subscribers = await conn.getMany('subscribers').toArray();

// ✅ Constant memory usage
await conn.getMany('subscribers').forEach(async (sub) => {
  await processSubscriber(sub);
});

Scales to 100k+ subscribers without breaking a sweat.

Race Condition Prevention

The atomic update prevents duplicate emails even if cron jobs overlap:

const updated = await conn.updateOne(
  'subscribers',
  { _id: subscriber._id, emailsSent: { $nin: [step] } }, // Only if not already sent
  { $push: { emailsSent: step } }
);

// Only queue if we won the race
if (updated) {
  await conn.enqueue('send-email', { subscriberId, step });
}

Automatic Retry

If sending fails, worker removes from sent list:

catch (error) {
  await conn.updateOne(
    'subscribers',
    { _id: subscriberId },
    { $pull: { emailsSent: step } }
  );
  // Next cron run will retry
}

Deployment

Literally 3 commands:

npm install -g codehooks
coho create my-drip --template drip-email-workflow
coho deploy

Configure your email provider:

coho set-env EMAIL_PROVIDER "sendgrid"
coho set-env SENDGRID_API_KEY "SG.your-key"
coho set-env FROM_EMAIL "hello@yourdomain.com"

Done. Your drip campaign is running.

The Stack

Codehooks gives you everything in one platform:

Serverless functions
NoSQL database (MongoDB-compatible)
Cron scheduler
Queue workers
Environment secrets

No AWS Lambda + SQS + CloudWatch + EventBridge nonsense. Just Node.js and deploy.

Cost Breakdown

For 5,000 subscribers:

Codehooks Pro: $19/month
SendGrid Essentials: $19.95/month
Total: $467/year

vs Mailchimp Standard: $1,020/year

For 50,000 subscribers:

Codehooks Pro: $19/month
SendGrid Pro: $89.95/month
Total: $1,307/year

vs Mailchimp: $3,600-4,800/year

The savings scale with your list size.

What You Get

The open source template includes:

✅ Complete working system

✅ REST API for subscriber management

✅ Responsive HTML email templates

✅ Email audit logging with dry-run mode

✅ SendGrid, Mailgun, Postmark integrations

✅ Example configs (onboarding, courses, nurture)

When NOT to Use This

Don't use this if you need:

Sub-minute delivery SLAs (use transactional email service)
Advanced segmentation UI
No-code workflow builder
Non-technical team members to manage campaigns

This is for developers who want control and ownership.

Try It

coho create my-campaign --template drip-email-workflow
cd my-campaign
coho deploy

Full code: github.com/codehooks-io/codehooks-io-templates

Docs: codehooks.io/docs

Built this for my own SaaS and figured others might find it useful. No affiliation besides being a happy user.

Questions? Drop them below! 👇

You can also read a more comprehensive blogpost here: https://codehooks.io/blog/2026/01/01/webhook-email-automation.

Build a Slack Bot with This Webhook Template

Jbee - codehooks.io — Sun, 14 Dec 2025 09:47:11 +0000

Ever wanted to build a Slack bot but got overwhelmed by the setup complexity? This minimal webhook template gets you a secure, production-ready Slack webhook handler with just a few commands.

The Template

Did you know there's a minimal Slack webhook template for Codehooks.io that makes it ridiculously easy to start building Slack integrations? Here's what makes it great:

~90 lines of code - No bloat, easy to understand
Secure by default - HMAC SHA-256 signature verification built-in
Production-ready - Handles URL verification, signature validation, and timing attacks
Serverless - No servers to manage, auto-scales

Getting Started

coho create myapp --template webhook-slack-minimal
cd myapp
npm install
coho deploy

That's it. Three commands. Your webhook is live.

What You Get Out of the Box

The template handles all the boring security stuff for you:

// Automatic signature verification
function verifySlackSignature(body, signature, timestamp) {
  // Rejects requests older than 5 minutes
  // Uses timing-safe comparison
  // Validates HMAC SHA-256 signature
}

// URL verification for Slack setup
if (body.type === 'url_verification') {
  return res.json({ challenge: body.challenge });
}

// Your bot logic starts here
if (event.type === 'message' && !event.bot_id && event.text) {
  console.log('Message:', event.text);
  // Do something cool
}

Just add your SLACK_SIGNING_SECRET environment variable, point Slack at your webhook URL, and you're receiving events.

Cool Use Cases

Here are some practical ways teams are using Slack bots:

1. Incident Response Bot

Automatically create tickets and notify on-call engineers when someone types @bot incident in your #alerts channel. Parse the message, extract severity levels, and kick off your incident management workflow. Integrate with PagerDuty, Jira, or your internal tools.

if (event.text.includes('incident')) {
  // Parse incident details
  // Create ticket in your system
  // Page on-call engineer
  // Post confirmation back to channel
}

2. Code Review Reminder Bot

Monitor your #engineering channel and remind developers about pending code reviews. When someone mentions a PR link, the bot tracks it and sends daily reminders until it's merged. Integrates with GitHub/GitLab APIs to check PR status.

if (event.text.includes('github.com') && event.text.includes('/pull/')) {
  // Extract PR URL
  // Check PR status via GitHub API
  // Schedule reminders for reviewers
  // Update team when merged
}

3. Knowledge Base Assistant

Create a smart assistant that answers common questions by searching your internal docs. Team members can ask @bot how do I deploy? and get instant answers with links to relevant documentation. Saves your team from answering the same questions repeatedly.

if (event.text.includes('@bot')) {
  const query = extractQuery(event.text);
  // Search your knowledge base
  // Format relevant results
  // Post back with helpful links
}

Why This Matters

Most Slack bot tutorials leave you wading through authentication flows, webhook verification logic, and security best practices. This template gives you that foundation in ~90 lines, so you can focus on building the actual bot logic.

The Codehooks.io platform handles deployment, scaling, environment variables, and logging. You just write JavaScript and deploy.

Next Steps

The template is minimal on purpose - it's designed to be extended. Here's what you might add:

Install @slack/web-api to post messages back to Slack
Add slash commands for interactive workflows
Connect to databases, APIs, or AI services
Handle reactions, mentions, or other event types

Check out the template on GitHub and start building your Slack bot today!

Resources

What would you build with this template? Drop your ideas in the comments!

Building a Production-Ready Webhook Delivery System in 5 Minutes

Jbee - codehooks.io — Sat, 13 Dec 2025 13:08:43 +0000

Building a webhook delivery system from scratch is deceptively complex. You need URL verification, HMAC signatures, retry logic, health monitoring, and scalable architecture to handle thousands of subscribers without blocking your API.

Most teams spend weeks building this infrastructure. But what if you could deploy a production-ready webhook system in minutes?

This post shows you how to build a complete outgoing webhook delivery system with queue-based architecture, automatic retries, security best practices, and enterprise-grade reliability—using just a few hundred lines of code.

How It Works: The Flow

Key Features:

⚡ Instant response (202 Accepted)
🔄 Parallel delivery to all subscribers
🔐 HMAC SHA-256 signatures on every webhook
♻️ Auto-retry with exponential backoff (1s, 2s, 4s)
📊 Health monitoring and auto-disable after 10 failures

What Are Outgoing Webhooks?

Most developers are familiar with receiving webhooks from services like Stripe, GitHub, or Slack. But what about sending them?

Outgoing webhooks (also called "reverse webhooks") let your application notify external services when events occur. When something happens in your system—a user signs up, an order ships, a payment completes—your app sends HTTP POST requests to registered webhook URLs.

This is crucial for building integrations, enabling real-time notifications, and allowing customers to build on top of your platform.

The Challenge: Building It Right Is Hard

Building a robust webhook delivery system from scratch involves solving many complex problems:

URL Verification: How do you validate that webhook URLs are legitimate?
Security: Payloads need HMAC signatures to prevent tampering
Reliability: What happens when a webhook endpoint is down?
Scale: How do you deliver to thousands of subscribers without blocking?
Monitoring: You need delivery stats, failure tracking, and auto-disabling of broken webhooks
Retry Logic: Exponential backoff, maximum attempts, timeout handling

Most teams spend weeks building this infrastructure. But there's a better way.

Queue-Based Architecture: The Secret Sauce

The key to scalable webhook delivery is decoupling event triggering from delivery. Here's how it works:

// 1. Store the event for audit trail
await conn.insertOne('events', eventData);

// 2. Mark all matching webhooks with the event ID
await conn.updateMany('webhooks',
  { status: 'active', $or: [{ events: eventType }, { events: '*' }] },
  { $set: { pendingEventId: eventData.id } }
);

// 3. Queue ALL webhooks in one atomic operation
await conn.enqueueFromQuery('webhooks',
  { status: 'active', pendingEventId: eventData.id },
  'webhook-delivery'
);

The magic is in enqueueFromQuery. Instead of loading webhooks into memory and looping through them, it:

Queues everything in a single database operation
Handles thousands of webhooks without memory overhead
Returns immediately (202 Accepted)
Processes deliveries in parallel via worker functions

This architecture delivers instant response times even with massive subscriber lists.

Security First: HMAC Signing

Every webhook payload includes a cryptographic signature so receivers can verify authenticity:

function generateSignature(payload, secret) {
  const timestamp = Math.floor(Date.now() / 1000);
  const sigBasestring = `${timestamp}.${payload}`;
  const signature = crypto
    .createHmac('sha256', secret)
    .update(sigBasestring, 'utf8')
    .digest('hex');
  return { signature: `v1=${signature}`, timestamp };
}

Headers sent with each webhook:

X-Webhook-Signature: HMAC SHA-256 signature
X-Webhook-Timestamp: Unix timestamp (prevents replay attacks)
X-Webhook-Id: Subscription ID

Receivers validate signatures and reject old timestamps (>5 minutes) to prevent replay attacks.

Automatic URL Verification

Before accepting webhook registrations, the system verifies URLs using industry-standard methods:

Stripe-style verification: Sends a test payload with a verification token and expects HTTP 200.

Slack-style challenge: Sends a random challenge string and expects it echoed back in the response.

Verification happens asynchronously in a worker queue, so registration returns immediately while verification runs in the background.

Smart Retry Logic

Failed deliveries trigger automatic retries with exponential backoff:

// Retry configuration
{
  maxRetries: 3,
  backoffIntervals: [1s, 2s, 4s],
  timeout: 10 seconds,
  autoDisableAfter: 10 consecutive failures
}

A cron job runs every 30 minutes to retry webhooks that have been failing for over an hour, preventing hammering of broken endpoints.

Event Flexibility

Unlike some webhook systems that force you to predefine event types, this system supports any event name:

# E-commerce events
POST /events/trigger/order.placed

# IoT events
POST /events/trigger/sensor.temperature.high

# Custom business events
POST /events/trigger/report.generated

Subscribers can register for specific events or use "*" as a wildcard to receive everything.

Production-Grade Monitoring

The system tracks detailed statistics for each webhook:

{
  "deliveryCount": 1247,
  "consecutiveFailures": 0,
  "lastDeliveryAt": "2025-01-15T10:30:00Z",
  "lastDeliveryStatus": "success",
  "status": "active"
}

After 10 consecutive failures, webhooks are automatically disabled to prevent wasting resources on dead endpoints. Users can manually retry with POST /webhooks/:id/retry.

The Complete API

The system provides a full CRUD API for webhook management:

# Create webhook (with automatic verification)
POST /webhooks
{
  "clientId": "customer-123",
  "url": "https://example.com/webhook",
  "events": ["order.placed", "order.shipped"],
  "verificationType": "stripe"
}

# List webhooks
GET /webhooks?status=active&event=order.placed

# Trigger events (queues delivery to all subscribers)
POST /events/trigger/order.placed
{
  "orderId": "123",
  "total": 99.99,
  "customer": "john@example.com"
}

# Check delivery stats
GET /webhooks/:id/stats

# Manually retry failed webhook
POST /webhooks/:id/retry

Idempotent Registration

The system uses clientId + url as a composite key for upsert logic:

First registration creates the webhook
Subsequent registrations with the same clientId + url update it
Prevents duplicate webhooks
Preserves HMAC secrets across updates
Perfect for multi-tenant SaaS applications

Real-World Integration

The system integrates seamlessly with workflow tools:

n8n: Create a webhook trigger, register the URL, and your workflows activate automatically.

Zapier: Use "Webhooks by Zapier" with Catch Hook, register the URL with verificationType: "stripe", and your Zaps come alive.

Custom apps: Implement signature verification in any language and start receiving events.

See It In Action

Want to try it yourself? The complete implementation is available as a Codehooks.io template:

coho create mywebhooks --template webhook-delivery
cd mywebhooks
npm install
coho deploy

You'll have a production-ready webhook delivery system running in minutes, not weeks.

Key Takeaways

Building webhook delivery infrastructure is complex, but the right architecture makes it manageable:

Queue-based delivery scales to thousands of subscribers
HMAC signatures ensure payload authenticity
Automatic verification validates webhook URLs before accepting them
Smart retries handle transient failures gracefully
Health monitoring auto-disables broken endpoints
Event flexibility supports any event naming scheme

Whether you're building a SaaS platform, IoT system, or integration hub, having solid webhook infrastructure lets your customers build powerful automations on top of your product.

The architecture patterns shown here work with any backend stack—Node.js, Python, Go, or whatever you prefer. The key is separating event triggering from delivery, implementing proper security, and handling failures gracefully.

The complete source code for this webhook delivery system is available at https://github.com/codehooks-io/codehooks-io-templates/tree/main/webhook-delivery

Creating reliable workflows in JavaScript

Jbee - codehooks.io — Tue, 17 Jun 2025 05:58:51 +0000

Using Codehooks.io, creating realiable and durable workflows has never been easier, nothing to learn, just plain JavaScript.

import { app } from 'codehooks-js'
// The workflow definition
const workflow = app.createWorkflow('minimal', 'Minimal workflow example', {
  start: (state, goto) => { goto('end', {...state, message: 'Hello World'}) },
  end: (state, goto) => goto(null, state) // null complete the workflow
})
// A REST API to start a new workflow instance
app.post('/start', async (req, res) => res.json(await workflow.start({prop: 'some value'})))

export default app.init()

Building Reliable Workflows with Serverless JavaScript

Jbee - codehooks.io — Sun, 01 Jun 2025 18:59:52 +0000

Modern web apps often need more than just simple API endpoints. You need logic. Not just any logic, but stateful, resilient, and scalable logic — think user onboarding flows, approval steps, reminders, and retries. Enter: Workflows.

And now, with Codehooks.io, building these workflows is easy, fast, and JavaScript-native. Let's dive in.

🧠 Why Workflows?

Whether you’re working on a side project or building enterprise-grade applications, workflows help you:

Break complex logic into steps
Add retries and error handling
Pause and resume
Scale reliably

🧪 A Simple Example: Odd or Even?

You'll need a codehooks.io account and a project before deploying your workflow code.

In this short tutorial we'll implement a simple workflow for deciding if a number is odd or even.

Let’s define a workflow in index.js:

import { app } from 'codehooks-js'

const workflow = app.createWorkflow('parityCheck', 'Check if a number is even or odd', {
  begin: async (state, goto) => {
    state.number = Math.floor(Math.random() * 100)
    goto('check', state)
  },
  check: async (state, goto) => {
    const step = (state.number % 2 === 0) ? 'even' : 'odd'
    goto(step, state) // branch
  },
  even: async (state, goto) => {
    console.log(`${state.number} is even`)
    goto('end', state)
  },
  odd: async (state, goto) => {
    console.log(`Number ${state.number} is odd`) 
    goto('end', state)
  },
  end: async (state, goto) => {
    console.log('Workflow finished', state)
    goto(null, state) // null complete the workflow
  }
})

// REST API to start a new workflow instance
app.post('/start', async (req, res) => {
  const result = await workflow.start({"Initial": "state"});
  res.json(result);
});

// export app interface to serverless runtime
export default app.init();

Deploy your workflow with the CLI command coho deploy or use the Codehooks Studio to work directly in the browser.

Calling the API endpoint POST https:{PROJECT_URL}/start will print the output from the workflow to the log:

dev 2025-06-15T07:03:05.714Z  Number 29 is odd
dev 2025-06-15T07:03:05.913Z  Workflow finished {
  "Initial": "state",
  "nextStep": "end",
  "createdAt": "2025-06-15T07:02:59.682Z",
  "workflowName": "parityCheck",
  "stepCount": {
    "begin": {
      "visits": 1,
      "startTime": "2025-06-15T07:03:02.738Z",
      "totalTime": 6,
      "finishTime": "2025-06-15T07:03:02.744Z"
    },
    "check": {
      "visits": 1,
      "startTime": "2025-06-15T07:03:05.006Z",
      "totalTime": 3,
      "finishTime": "2025-06-15T07:03:05.009Z"
    },
    "odd": {
      "visits": 1,
      "startTime": "2025-06-15T07:03:05.709Z",
      "totalTime": 3,
      "finishTime": "2025-06-15T07:03:05.712Z"
    },
    "end": {
      "visits": 1,
      "startTime": "2025-06-15T07:03:05.907Z",
      "totalTime": 0
    }
  },
  "_id": "684e7023878a78b8ac8338ab",
  "updatedAt": "2025-06-15T07:03:05.907Z",
  "number": 29,
  "previousStep": "odd",
  "instanceId": "684e7023878a78b8ac8338ab"
}
dev 2025-06-15T07:03:05.917Z  Workflow parityCheck 684e7023878a78b8ac8338ab is completed in time: 6.225s 🎉

🛠 How It Works

Each step is an async function.
goto(step, state) passes updated state and moves to the next step.
State is persisted between steps.
Calling goto(null, state) finish the workflow instance.

🔄 Real-World Use Cases

User onboarding
Approval flows
Reminders & timeouts
Background jobs

🧠 Code-first = AI-ready

One underrated benefit of using a code-first workflow engine like Codehooks? It plays beautifully with AI tools like ChatGPT, Cursor and Copilot.

Because workflows are written in plain, readable JavaScript:

✅ You can ask an LLM to generate your workflows from natural language specs
🐞 You can debug or optimize a step-by-step flow by pasting the code into ChatGPT
🔍 You can analyze edge cases and verify paths programmatically or through simulations

This makes your workflows not just easier to write — but easier to evolve, maintain, and reason about, even with AI assistance.

👉 Try it at codehooks.io

Building SEO-Optimized Directory Services with Codehooks.io: A Developer's Guide

Jbee - codehooks.io — Sun, 27 Apr 2025 08:08:47 +0000

Introduction

In today's digital landscape, creating and maintaining directory services can be a complex task. Whether you're building a product catalog, service directory, or resource hub, you need a solution that's both developer-friendly and SEO-optimized. This is where the directory-template comes in - a powerful open-source solution built on Codehooks.io that makes it easy to create and deploy directory services.

Screenshot of an example directory alltoolz.dev:

Why Directory Services Matter

Directory services are crucial for organizing and presenting information in a structured way. They're used for everything from product catalogs to service listings, and their success often depends on two key factors:

SEO optimization for discoverability
Developer-friendly implementation

The Solution: Directory Template

The directory template provides a complete solution for building directory services with:

Built-in SEO optimization
Modern UI using DaisyUI and Tailwind CSS
Automatic screenshot generation
Sitemap generation
Full text search with lunrjs
Mock data support for rapid development
Easy deployment to Codehooks.io

Key Features for Developers

1. Quick Setup

git clone https://github.com/RestDB/directory-template
cd directory-template
npm install
coho init --empty

2. Modern Tech Stack

Frontend: DaisyUI + Tailwind CSS for beautiful, responsive designs
Backend: Codehooks.io for serverless API endpoints
SEO: Built-in optimization with automatic sitemap generation

3. Developer-Friendly Tools

Mock data generation for testing
Automatic screenshot creation
Built-in search functionality
Easy deployment process

Real-World Example: alltoolz.dev

A great example of this template in action is alltoolz.dev - a directory of developer tools and resources. The site demonstrates how the template can be used to create a professional, SEO-optimized directory service.

Getting Started

Clone the repository and install dependencies
Set up your Codehooks.io account
Run the mock data setup
Deploy to production

The template includes comprehensive documentation and example implementations to help you get started quickly.

Why Codehooks.io?

Codehooks.io provides the perfect backend for directory services because:

Serverless architecture for cost-effective scaling
Built-in database and blob storage
Easy API development
Automatic deployment

Conclusion

Building directory services doesn't have to be complicated. With the directory template and Codehooks.io, you can create professional, SEO-optimized directory services quickly and efficiently. Whether you're building a product catalog, service directory, or resource hub, this solution provides everything you need to get started.

Resources

Introducing JSON Schema for codehooks.io backend collections

Jbee - codehooks.io — Sun, 21 Jul 2024 18:05:57 +0000

In today's fast-paced digital environment, having a reliable backend for applications is crucial. A good datastore ensures data integrity, security, and scalability, which are vital for both business and user experiences. Codehooks.io provides a solid solution with its Datastore, JSON schema support, and a MongoDB-like NoSQL API. This platform helps maintain data consistency and validation and offers a REST API secured with API tokens and JWKS for user authentication.

Why a Solid and Consistent Datastore Backend is Essential

A well-structured NoSQL datastore backend is the backbone of any application. It ensures:

Data Integrity: All data is validated against defined JSON Schemas, reducing the risk of corrupt or malformed data.
Security: Sensitive data is protected through robust authentication and authorization mechanisms.
Scalability: The system can handle increasing loads, ensuring performance remains stable as the application grows.
Flexibility: Ready-made REST APIs allow for seamless integration with various clients and services.

Follow the next 4 simple steps to learn how to build your own Datastore.

Step 1: Setting Up Codehooks.io

First, you'll need to sign up for an account on Codehooks.io if you haven't already. Once signed in, install the Codehooks CLI to manage your projects efficiently.

npm install -g codehooks

Next, log in to your account.

codehooks login

Then create a local directory for your project files.

mkdir myproject
cd myproject
codehooks init

Find the avaliable HTTP endpoint addresses for your project.

codehooks info

In my example this outputs something like this.

Project name: myproject-24ej
Team: codehooks 

API endpoints: 

https://mighty-frog-14a0.codehooks.io
https://myproject-24ej.api.codehooks.io/dev

Step 2: Defining Your JSON Schema

To ensure your data is consistent and secure, you can define a JSON Schema for your collections. This schema will validate the data structure and enforce data types.

Create a schema file (e.g., personSchema.json) defining the structure of your data:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Person",
  "type": "object",
  "properties": {
    "firstName": {
      "type": "string",
      "description": "The person's first name."
    },
    "lastName": {
      "type": "string",
      "description": "The person's last name."
    },
    "age": {
      "type": "integer",
      "description": "The person's age.",
      "minimum": 0
    },
    "email": {
      "type": "string",
      "format": "email",
      "description": "The person's email address."
    },
  },
  "required": [
    "firstName",
    "lastName",
    "email"
  ]
}

Use the CLI to add this JSON Schema to your collection:

codehooks add-schema --collection 'person' --schema './personSchema.json'

This command applies the schema to the specified collection, ensuring all future data adheres to this structure.

Step 3: Importing Your Data

Codehooks.io allows you to import data from various formats such as JSON, Excel, or CSV. For this example, we'll import a JSON file containing sample data for our web application.

Importing JSON Data

Prepare your JSON file (e.g., persondata.json) with the data you want to import. Then use the CLI to import this data into your Codehooks NoSQL Datastore.

codehooks import --filepath './persondata.json' --collection 'person'

This command uploads your JSON data to Codehooks, creating a new collection in the process.

Step 4: Utilizing the Ready-Made REST API

Codehooks.io provides a robust, ready-made REST API to interact with your NoSQL datastore, making it easy to perform CRUD (Create, Read, Update, Delete) operations on your data. This JavaScript database API is secured with API tokens for machine-to-machine integration and supports JWKS for flexible user authentication.

Creating a Record

To add a new record to your collection, use the following REST API call with fetch:

const newRecord = {
  firstName: "John",
  lastName: "Doe",
  email: "john.doe@example.com",
  age: 30
};

fetch('https://mighty-frog-14a0.codehooks.io/person', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer YOUR_JWT_TOKEN'
  },
  body: JSON.stringify(newRecord)
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

JSON-Schema validation

In the event that clients sends data not following the JSON-Schema, a validator error will be returned.
E.g. when a client posts a JSON object missing a required field a validator HTTP status 400 error object will be returned.

{
    "schemaError": [
        {
            "instancePath": "",
            "schemaPath": "#/required",
            "keyword": "required",
            "params": {
                "missingProperty": "firstName"
            },
            "message": "must have required property 'firstName'"
        }
    ]
}

Reading Records

To fetch records from your collection, use a GET request with fetch:

fetch('https://mighty-frog-14a0.codehooks.io/person', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer YOUR_JWT_TOKEN'
  }
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

Updating a Record

To update an existing record, specify the record ID and the fields to update, This example will fail due to the requirements in the JSON-schema:

const updatedRecord = {
  firstName: "Jill",
  lastName: "Doe",
  email: "jill.doe@example.com",
  age: 29
};

fetch('https://mighty-frog-14a0.codehooks.io/person/record-id', {
  method: 'PUT',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer YOUR_JWT_TOKEN'
  },
  body: JSON.stringify(updatedRecord)
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

Deleting a Record

To delete a record, use the record ID in a DELETE request:

fetch('https://mighty-frog-14a0.codehooks.io/person/record-id', {
  method: 'DELETE',
  headers: {
    'Authorization': 'Bearer YOUR_JWT_TOKEN'
  }
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

Codehooks.io Studio

While the Codehooks CLI is designed for automation and efficiency, Codehooks.io also provides a user-friendly interface - Codehooks Studio. This makes it easy to manage your database, import data, and define data schemas. The intuitive dashboard allows you to visualize your data, perform CRUD operations, and configure settings without writing any code. This flexibility ensures that both developers and non-developers can manage the backend seamlessly.

Conclusion

By leveraging the new JSON Schema support in Codehooks.io, you can ensure that your backend data is consistently validated and well-structured. This powerful feature, combined with Codehooks.io's NoSQL Datastore and ready-made REST API, provides a robust and efficient foundation for any modern application. These tools make your data fast, secure, and consistent, allowing you to focus on building great features and enhancing user experience.

Start today and see how Codehooks.io's JSON Schema support can streamline your backend development process 🚀

Links for Further Reading

Introduction to NoSQL Databases

Learn about the different types of NoSQL databases and their use cases.

Understanding JSON Schema

A comprehensive guide to defining and using JSON Schemas for data validation.

RESTful API Design Best Practices

Explore best practices for designing and using RESTful APIs.

JavaScript Fetch API

Official documentation and examples for using the Fetch API in JavaScript to make HTTP requests.

Securing APIs with JWT

Understand how to secure your APIs using JSON Web Tokens (JWT).

Codehooks.io Documentation
- Official documentation for Codehooks.io, covering all features and functionalities.