Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit

## Summary
<!-- Succinctly describe your change, providing context, what you've
changed, and why. -->

Makes sure we attempt to parse errors from the Inngest API when sending
events. Partial of #256.

## Checklist
<!-- Tick these items off as you progress. -->
<!-- If an item isn't applicable, ideally please strikeout the item by
wrapping it in "~~"" and suffix it with "N/A My reason for skipping
this." -->
<!-- e.g. "- [ ] ~~Added tests~~ N/A Only touches docs" -->

- [ ] ~~Added a [docs PR]( that
references this PR~~ N/A Bug fix
- [x] Added unit/integration tests
- [x] Added changesets if applicable

## Related
<!-- A space for any related links, issues, or PRs. -->
<!-- Linear issues are autolinked. -->
<!-- e.g. - INN-123 -->
<!-- GitHub issues/PRs can be linked using shorthand. -->
<!-- e.g. "- inngest/inngest#123" -->
<!-- Feel free to remove this section if there are no applicable related
- #256

Git stats


Failed to load latest commit information.

Serverless event-driven queues, background jobs, and scheduled jobs for Typescript.
Works with any framework and platform.

Read the documentation and get started in minutes.

On any serverless platform (Next.js, Deno Deploy, RedwoodJS, AWS Lambda, and anything else) and with no extra infrastructure:

  • ⚑ Write background jobs
  • πŸ• Create scheduled & cron jobs
  • ♻️ Build serverless queues
  • πŸͺœ Write complex step functions
  • 🚘 Build serverless event-driven systems
  • πŸͺ Reliably respond to webhooks, with retries & payloads stored for history

πŸ‘‹ Have a question or feature request? Join our Discord!

Getting started Β· Features Β· Contributing Β· Documentation

Getting started

Install Inngest:

npm install inngest  # or yarn add inngest

Writing functions

Write serverless functions and background jobs right in your own code:

import { Inngest } from "inngest";

const inngest = new Inngest({ name: "My App" });

// This function will be invoked by Inngest via HTTP any time
// the "app/user.signup" event is sent to to Inngest
export default inngest.createFunction(
  { name: "User onboarding communication" },
  { event: "app/user.signup" },
  async ({ event, step }) => {
    await"Send welcome email", async () => {
      await sendEmail({
        template: "welcome",
  • Functions are triggered by events which can be sent via this SDK, webhooks, integrations, or with a simple HTTP request.
  • When a matching event is received, Inngest invokes the function automatically, with built-in retries.

Serving your functions

Inngest invokes functions via HTTP, so you need to serve them using an adapter for the framework of your choice. See all frameworks here in our docs. Here is an example using the Next.js serve handler:

// /pages/api/inngest.ts
import { Inngest } from "inngest";
// See the "inngest/next" adapter imported here:
import { serve } from "inngest/next";
import myFunction from "../userOnboardingCOmmunication"; // see above function

// You can create this in a single file and import where it's needed
const inngest = new Inngest({ name: "My App" });

// Securely serve your Inngest functions for remote invocation:
export default serve(inngest, [myFunction]);

Sending events to trigger functions

// Send events
import { Inngest } from "inngest";
const inngest = new Inngest({ name: "My App" });

// This will run the function above automatically, in the background
inngest.send("app/user.signup", {
  data: { email: "", user_id: "12345" },
  • Events can trigger one or more functions automatically, enabling you to fan-out work.
  • Inngest stores a history of all events for observability, testing, and replay.


  • Fully serverless: Run background jobs, scheduled functions, and build event-driven systems without any servers, state, or setup
  • Works with your framework: Works with Next.js, Redwood, Express, Cloudflare Pages, Nuxt, Fresh (Deno), and Remix
  • Deploy anywhere: Keep deploying to your existing platform: Vercel, Netlify, Cloudflare, Deno, Digital Ocean, etc.
  • Use your existing code: Write functions within your current project and repo
  • Fully typed: Event schemas, versioning, and governance out of the box
  • Observable: A full UI for managing and inspecting your functions



  1. Clone this repository
  2. Intall pnpm
  3. Install Volta to manage consistent Node versions (optional)


Run the following command in the packages/inngest/ directory:

pnpm dev

This will install dependencies, build, and lint the package. It will watch for changes and re-run appropriate commands.

Testing the package

To test changes with other local repositories, we recommend packaging the library entirely and directly installing the resulting .tgz file. This is often more reliable than linking, which can cause issues when using multiple package managers.

# in packages/inngest/
pnpm local:pack # creates inngest.tgz

# in another repo
yarn add ~/path/to/packages/inngest/inngest.tgz

You can also use this method to ship a snapshot of the library with an application. This is a nice way to generate and ship snapshot versions without requiring a release to npm.


To release to production, we use Changesets. This means that releasing and changelog generation is all managed through PRs, where a bot will guide you through the process of adding release notes to PRs.

As PRs are merged into main, a new PR (usually called Release @latest) is created that rolls up all release notes since the last release, allowing you bundle changes together. Once you're happy with the release, merge this new PR and the bot will release the package to npm for you.

Merging PRs to main (therefore both introducing a potential change and releasing to npm) requires that tests pass and a contributor has approved the PR.

Legacy versions

Merging and releasing to previous major versions of the SDK is also supported.

  • Add a backport v*.x label (e.g. backport v1.x) to a PR to have a backport PR generated when the initial PR is merged.
  • Merging into a v*.x branch creates a release PR (named Release v1.x, for example) the same as the main branch. Simply merge to release.

Snapshot versions

If a local inngest.tgz isn't ideal, we can release a tagged version to npm. For now, this is relatively manual. For this, please ensure you are in an open PR branch for observability.

Decide on the "tag" you will be publishing to, which will dictate how the user installs the snapshot, e.g. if your tag is beta, the user will install using inngest@beta.

You can see the currently available tags on the inngest npm page.

NEVER use the latest tag, and NEVER run npm publish without specifying --tag.

If the current active version is v1.1.1, this is a minor release, and our tag is foo, we'd do:

yarn version 1.2.0-foo.1
yarn build
npm publish --access public --tag foo

You can iterate the final number for each extra snapshot you need to do on a branch.