`inngest.json|cue`

All Inngest functions are defined as inngest.json or inngest.cue files. The file is generated by the inngest init command, but you can create a file manually or edit it as needed. You can use Cue, which is a superset of JSON for additional language features.

Configuration docs

Here's an example inngest.json file with annotations for what each component is:

json
{
The name of your function or step function. This will be visible in the UI.
  "name": "Send SMS Dispatch",
The uniquely generated ID for the function. This is used by the CLI for CRUD operations.
  "id": "prompt-deer-ede40d",
Triggers is an array of event or scheduled triggers for the function (see below)
  "triggers": [
    {
      "event": "worker.dispatched",
      "definition": {
        "format": "cue",
        "synced": false,
        "def": "file://./events/worker-dispatched.cue"
      }
    }
  ],
 
These are the steps of the function. A function can have 1 to n steps, in parallel or sequenced.
  "steps": {
    "step-1": {
      "id": "step-1",
      "path": "file://./steps/send-sms-dispatch",
      "name": "Send SMS Dispatch",
      "runtime": {
        "type": "docker"
      }
    },
    "step-2": {
      "id": "step-2",
      "path": "file://./steps/my-second-step",
      "name": "Send followup SMS",
      "runtime": {
        "type": "docker"
      },
You can specify the order of each step with an "after" field.  Here, this second step will run after the first step completes.  This step will also be able to examine the output of the first step.
      "after": [
        {
	  "step": "step-1"
	}
      ]
    }
  }
}

Function triggers

A function can have 1 or more triggers which are defined in the following format. As a given event is received or schedule is executed, the function is executed starting with the first step. There are two types of triggers: Events and Schedules.

Event triggers

json
{
The event name or pattern for which to match, you can use a wildcard as well like "worker.*" if you'd like to match against multiple events.
  "event": "worker.dispatched",
The event definition can reference a local Cue file which declares the schema of the event itself. This is used with the `inngest run` command to generate test event data
  "definition": {
    "format": "cue",
    "synced": false,
    "def": "file://./events/worker-dispatched.cue"
  }
}

Scheduled triggers

Scheduled triggers are configured as cron expressions, eg:

json
{
  "name": "Send summary",
  "id": "prompt-deer-ede40d",
  "triggers": [
    { "cron": "0 12 * * *" } // The function automatically runs on this schedule.
  ],
}

Steps

The list of steps is an object, with each step using a unique key id and it's own step configuration. A function can have 1 to n steps. For more information about steps, check out the Step Functions documentation.

json
"steps": {
The step id - this must be unique
  "step-1": {
    "id": "step-1",
The path to the step's code including a Dockerfile for Docker runtime functions.
    "path": "file://./steps/send-sms-dispatch",
A nicely formatted name for the step for logging and UI purposes
    "name": "Send SMS Dispatch",
A runtime declaration instructing Inngest how to execute your function
    "runtime": {
      "type": "docker"
    }
  },
  "step-2": {
    "id": "step-2",
    "path": "file://./steps/log-confirmation-for-admin",
    "name": "Log confirmation for admin",
The "after" parameter is used to specify which step to execute this step after. This allows you to chain steps together to create complex DAGs
    "after": {
      "step": "step-1", // The ID of a previous step.
Wait is an optional field that specifies a delay between executing steps, e.g. "24h" or "1h30m"
      "wait": "24h", // This will wait 24h before running, after step 1 completes.
    },
    "runtime": {
      "type": "docker"
    }
  }

Waits

You can specify that steps should run after a wait, eg. to schedule a step to execute 10 minutes after the trigger you can specify "wait": "10m" within the after JSON block.

Event coordination

You can also pause functions in between steps by specifing an async block. The async block halts a function, sets up a temporary trigger which listens for the specified event, and automatically resumes the function when a matching event is received.

Using this functionality it's possible to easily build flows that model complex user journeys, such as retention flows, drip campaigns, etc.

Runtimes

Runtimes are defined within each step's configuration. A runtime specifies how the function runs. There are multiple runtimes available:

docker: indicates that the step should run code within a container
http: indicates that the step should execute an HTTP fetch (instead of running code).

Previous`login`

Next`serve()`