
Inngest Events
Design Inngest event names, payloads, dedupe IDs, and fan-out patterns so background jobs stay idempotent under at-least-once delivery—including Stripe-style webhooks.
Overview
Inngest Events is an agent skill most often used in Build (also Ship, Operate) that teaches robust Inngest event schemas, idempotency IDs, fan-out triggers, and system event handling for durable workflows.
Install
npx skills add https://github.com/inngest/inngest-skills --skill inngest-eventsWhat is this skill?
- Full event payload schema: name, data, optional id, ts, and version field v
- Idempotent handling with event id and 24-hour deduplication window
- Fan-out: one trigger event invoking many downstream Inngest functions
- System events such as inngest/function.failed for failure-oriented workflows
- TypeScript-focused guidance with pointers to Inngest docs for Python and Go
- 24-hour deduplication window for optional event id
- Required event fields: name and data object
Adoption & trust: 2.7k installs on skills.sh; 23 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need event-driven Inngest functions but duplicate webhook deliveries and vague event names will cause double side effects and unclear fan-out.
Who is it for?
Solo builders implementing Inngest-backed SaaS workflows with webhooks, multi-handler fan-out, and explicit idempotency boundaries.
Skip if: Teams only needing generic message-queue theory without Inngest, or cron-only jobs with no event producers.
When should I use this skill?
When designing event-driven workflows, fan-out patterns, idempotent event IDs, or handling at-least-once delivery from sources like Stripe webhooks on Inngest.
What do I get? / Deliverables
You ship named, versioned events with dedupe IDs and fan-out patterns that survive at-least-once delivery and external sources like Stripe.
- Event type definitions with name, data, optional id/ts/v
- Fan-out mapping from trigger events to functions
- Idempotency strategy for external webhooks
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Primary shelf is Build integrations where event contracts and handlers are authored alongside backend code. Integrations subphase captures webhook ingress, cross-service fan-out, and schema versioning for Inngest-triggered functions.
Where it fits
Model Stripe webhook payloads as Inngest events with stable names and dedupe ids before registering functions.
Fan out user.signup to onboarding email, CRM sync, and analytics handlers from one emitted event.
Simulate duplicate event delivery to confirm 24-hour id window prevents double billing side effects.
Subscribe to inngest/function.failed to alert and replay compensating workflows after handler crashes.
How it compares
Event-design playbook for Inngest’s JSON event model—not a generic Zapier recipe or raw SQS tutorial.
Common Questions / FAQ
Who is inngest-events for?
Developers shipping TypeScript-first (or polyglot) apps on Inngest who want agents to follow official event payload, naming, and idempotency conventions.
When should I use inngest-events?
Use in Build integrations when defining producers and schemas, in Ship testing when validating dedupe and fan-out under retries, and in Operate monitoring when handling inngest/function.failed and webhook replay scenarios.
Is inngest-events safe to install?
It is documentation-style workflow guidance; review the Security Audits panel on this Prism page and your own secret handling for webhook verification in production.
SKILL.md
READMESKILL.md - Inngest Events
# Inngest Events Master Inngest event design and delivery patterns. Events are the foundation of Inngest - learn to design robust event schemas, implement idempotency, leverage fan-out patterns, and handle system events effectively. > **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. ## Event Payload Format Every Inngest event is a JSON object with required and optional properties: ### Required Properties ```typescript type Event = { name: string; // Event type (triggers functions) data: object; // Payload data (any nested JSON) }; ``` ### Complete Schema ```typescript type EventPayload = { name: string; // Required: event type data: Record<string, any>; // Required: event data id?: string; // Optional: deduplication ID ts?: number; // Optional: timestamp (Unix ms) v?: string; // Optional: schema version }; ``` ### Basic Event Example ```typescript await inngest.send({ name: "billing/invoice.paid", data: { customerId: "cus_NffrFeUfNV2Hib", invoiceId: "in_1J5g2n2eZvKYlo2C0Z1Z2Z3Z", userId: "user_03028hf09j2d02", amount: 1000, metadata: { accountId: "acct_1J5g2n2eZvKYlo2C0Z1Z2Z3Z", accountName: "Acme.ai" } } }); ``` ## Event Naming Conventions **Use the Object-Action pattern:** `domain/noun.verb` ### Recommended Patterns ```typescript // ✅ Good: Clear object-action pattern "billing/invoice.paid"; "user/profile.updated"; "order/item.shipped"; "ai/summary.completed"; // ✅ Good: Domain prefixes for organization "stripe/customer.created"; "intercom/conversation.assigned"; "slack/message.posted"; // ❌ Avoid: Unclear or inconsistent "payment"; // What happened? "user_update"; // Use dots, not underscores "invoiceWasPaid"; // Too verbose ``` ### Naming Guidelines - **Past tense:** Events describe what happened (`created`, `updated`, `failed`) - **Dot notation:** Use dots for hierarchy (`billing/invoice.paid`) - **Prefixes:** Group related events (`api/user.created`, `webhook/stripe.received`) - **Consistency:** Establish patterns and stick to them ## Event IDs and Idempotency **When to use IDs:** Prevent duplicate processing when events might be sent multiple times. ### Basic Deduplication ```typescript await inngest.send({ id: "cart-checkout-completed-ed12c8bde", // Unique per event type name: "storefront/cart.checkout.completed", data: { cartId: "ed12c8bde", items: ["item1", "item2"] } }); ``` ### ID Best Practices ```typescript // ✅ Good: Specific to event type and instance id: `invoice-paid-${invoiceId}`; id: `user-signup-${userId}-${timestamp}`; id: `order-shipped-${orderId}-${trackingNumber}`; // ❌ Bad: Generic IDs shared across event types id: invoiceId; // Could conflict with other events id: "user-action"; // Too generic id: customerId; // Same customer, different events ``` **Deduplication window:** 24 hours from first event reception See **inngest-durable-functions** for idempotency configuration. ## The `ts` Parameter for Delayed Delivery **When to use:** Schedule events for future processing or maintain event ordering. ### Future Scheduling ```typescript const oneHourFromNow = Date.now() + 60 * 60 * 1000; await inngest.send({ name: "trial/reminder.send", ts: oneHourFromNow, // Deliver in 1 hour data: { userId: "user_123", trialExpiresAt: "2024-02-15T12:00:00Z" } })