Skip to main content
Nelkap doesn’t run your code on its own servers. Your workflows stay in your app, next to your database and your other code. Each time a run has work to do, Nelkap sends a POST request to your app, and the SDK runs the workflow right there. That request arrives at your project’s endpoint: one route that you add to your app and that passes each request to nelkap.handle. This section shows how to add that route in your framework, from the keys to your first run.

​
Choose your framework

Next.js

A route handler in the App Router.

React Router

A resource route, in framework mode.

SvelteKit

A +server.ts endpoint.

Nuxt

A server route in the server folder.

Astro

An endpoint rendered on demand.

Hono

A route on a Hono app running on Node.js.

Express

A route that turns Express’s request into a standard one.

​
Any other framework

nelkap.handle takes a standard web Request and returns a standard Response. Any framework that gives you the incoming request in that form works the same way: add a POST route, and return what handle returns.
The SDK needs Node.js 22 or later.

​
What happens when Nelkap calls your route

Each call carries the workflow to run, the run’s payload, and the steps already saved. handle then does three things:
  1. It checks that the call carries your project’s secret. If it doesn’t, it answers 401, and nothing runs.
  2. It looks for the workflow among the ones you registered. If your app doesn’t have it, it answers 404.
  3. It answers 202 right away, then runs the workflow in the background, saving each step as it finishes.
Answering first means Nelkap never waits for your workflow, however long it takes. The run itself goes on until it completes, fails, or pauses on a sleep or a wait.

​
What your endpoint needs

  • A public HTTPS URL on a domain name. Nelkap calls it over the internet, so a local address won’t work.
  • An answer within 30 seconds, without a redirect. handle answers at once, so this only matters if something runs before it.
  • No sign-in. If your app checks sign-in on every route, leave this one out: handle checks Nelkap’s secret instead.
If Nelkap can’t reach your endpoint, it tries again, up to three attempts in all. After that, the run fails with deliveryFailed, and you can replay it once your endpoint is back.

​
Serverless hosts

Hosts like Vercel can stop your code as soon as the response is sent. Since handle answers before the workflow runs, the run would stop with it. To keep it going, pass your host’s waitUntil to handle:
Each framework page shows the right waitUntil for its hosts. These hosts also limit how long a function can run. A call runs as many steps as it can within that limit. If the host stops it first, every step already saved is kept, and Nelkap calls your app again five minutes later to go on from there. Only a single step longer than the limit can’t finish, so keep each step shorter than your host allows.

​
Your project’s secret

Nelkap sends your project’s secret with every call, and handle compares it with NELKAP_SECRET. You can rotate the secret from your projects, for example if it leaked. Your endpoint then turns calls away until it has the new one, so update NELKAP_SECRET right after.