$npx -y skills add inngest/inngest-skills --skill inngest-middlewareUse when adding cross-cutting concerns to durable functions — structured logging or tracing across all functions, error tracking with Sentry, payload encryption for sensitive data, dependency injection of clients (DB, Stripe, etc.) into function handlers, custom telemetry, or beh
| 1 | # Inngest Middleware |
| 2 | |
| 3 | Master Inngest middleware to handle cross-cutting concerns like logging, error tracking, dependency injection, and data transformation. Middleware runs at key points in the function lifecycle, enabling powerful patterns for observability and shared functionality. |
| 4 | |
| 5 | > **These skills are focused on TypeScript.** For Python or Go, refer to the [Inngest documentation](https://www.inngest.com/llms.txt) for language-specific guidance. Core concepts apply across all languages. |
| 6 | |
| 7 | > **Note:** The middleware system was significantly rewritten in v4. The lifecycle hooks documented here reflect the v4 API. If migrating from v3, consult the [migration guide](https://www.inngest.com/docs-markdown/reference/typescript/v4/migrations/v3-to-v4) for details on breaking changes. |
| 8 | |
| 9 | > **⚠ For Realtime use the `inngest-realtime` skill, NOT this one.** Inngest v3 used `realtimeMiddleware()` from `@inngest/realtime` to inject a `publish` arg into function handlers. **v4 ships realtime natively** — `step.realtime.publish` is built-in, no middleware required. Do NOT install `@inngest/realtime` on a v4 project (it's a v3-era package and produces `TypeError: Cls is not a constructor` at runtime). See the `inngest-realtime` skill for the v4 pattern. |
| 10 | |
| 11 | ## What is Middleware? |
| 12 | |
| 13 | Middleware allows code to run at various points in an Inngest client's lifecycle - during function execution, event sending, and more. Think of middleware as hooks into the Inngest execution pipeline. |
| 14 | |
| 15 | **When to use middleware:** |
| 16 | |
| 17 | - **Observability:** Add logging, tracing, or metrics |
| 18 | - **Dependency injection:** Share client instances across functions |
| 19 | - **Data transformation:** Encrypt/decrypt, validate, or enrich data |
| 20 | - **Error handling:** Custom error tracking and alerting |
| 21 | - **Authentication:** Validate user context or permissions |
| 22 | |
| 23 | ## Middleware Lifecycle |
| 24 | |
| 25 | Middleware can be registered at **client-level** (affects all functions) or **function-level** (affects specific functions). |
| 26 | |
| 27 | ### Execution Order |
| 28 | |
| 29 | ```typescript |
| 30 | const inngest = new Inngest({ |
| 31 | id: "my-app", |
| 32 | middleware: [ |
| 33 | loggingMiddleware, // Runs 1st |
| 34 | errorMiddleware // Runs 2nd |
| 35 | ] |
| 36 | }); |
| 37 | |
| 38 | inngest.createFunction( |
| 39 | { |
| 40 | id: "example", |
| 41 | middleware: [ |
| 42 | authMiddleware, // Runs 3rd |
| 43 | metricsMiddleware // Runs 4th |
| 44 | ], |
| 45 | triggers: [{ event: "test" }] |
| 46 | }, |
| 47 | async () => { |
| 48 | /* function code */ |
| 49 | } |
| 50 | ); |
| 51 | ``` |
| 52 | |
| 53 | **Order matters:** Client middleware runs first, then function middleware, in the order specified. |
| 54 | |
| 55 | ## Creating Custom Middleware |
| 56 | |
| 57 | ### Basic Middleware Structure |
| 58 | |
| 59 | ```typescript |
| 60 | import { InngestMiddleware } from "inngest"; |
| 61 | |
| 62 | const loggingMiddleware = new InngestMiddleware({ |
| 63 | name: "Logging Middleware", |
| 64 | init() { |
| 65 | // Setup phase - runs when client initializes |
| 66 | const logger = setupLogger(); |
| 67 | |
| 68 | return { |
| 69 | // Function execution lifecycle |
| 70 | // Note: `fn` is loosely typed in middleware generics; fn.id works at runtime |
| 71 | onFunctionRun({ ctx, fn }) { |
| 72 | return { |
| 73 | beforeExecution() { |
| 74 | logger.info("Function starting", { |
| 75 | functionId: fn.id, |
| 76 | eventName: ctx.event.name, |
| 77 | runId: ctx.runId |
| 78 | }); |
| 79 | }, |
| 80 | |
| 81 | afterExecution() { |
| 82 | logger.info("Function completed", { |
| 83 | functionId: fn.id, |
| 84 | runId: ctx.runId |
| 85 | }); |
| 86 | }, |
| 87 | |
| 88 | transformOutput({ result }) { |
| 89 | // Log function output |
| 90 | logger.debug("Function output", { |
| 91 | functionId: fn.id, |
| 92 | output: result.data |
| 93 | }); |
| 94 | |
| 95 | // Return unmodified result |
| 96 | return { result }; |
| 97 | } |
| 98 | }; |
| 99 | }, |
| 100 | |
| 101 | // Event sending lifecycle |
| 102 | onSendEvent() { |
| 103 | return { |
| 104 | transformInput({ payloads }) { |
| 105 | logger.info("Sending events", { |
| 106 | count: payloads.length, |
| 107 | events: payloads.map((p) => p.name) |
| 108 | }); |
| 109 | |
| 110 | // Spread to convert readonly array to mutable array |
| 111 | return { payloads: [...payloads] }; |
| 112 | } |
| 113 | }; |
| 114 | } |
| 115 | }; |
| 116 | } |
| 117 | }); |
| 118 | ``` |
| 119 | |
| 120 | ### Python Implementation |
| 121 | |
| 122 | Python middleware follows a similar pattern. See [Dependency Injection Reference](./references/dependency-injection.md) for complete Python examples. |
| 123 | |
| 124 | ```` |
| 125 | |
| 126 | ## Dependency Injection |
| 127 | |
| 128 | Share expensive or stateful clients across all functions. **See [Dependency Injection Reference](./references/dependency-injection.md) |