Forem: Dibyajyoti

Clerk Webhooks and Inngest: A Complete Integration Guide

Dibyajyoti — Mon, 04 May 2026 05:32:21 +0000

Modern apps need to react instantly to user activity. When someone signs up, updates their profile, or deletes their account, your backend should respond immediately without constantly checking for changes.

That’s exactly what happens when you combine Clerk webhooks with Inngest.

This guide walks you through the concept + setup + real implementation in a clean, practical way.

1. Understanding Webhooks (Quick Clarity)

A webhook is simply:

An automatic HTTP POST request sent when an event happens

Instead of asking:

“Did a user sign up yet?”

Your app gets notified instantly:

“A user just signed up. Here’s the data.”

This removes unnecessary API polling and keeps your system real-time.

2. What Clerk Brings to the Table

Clerk handles authentication and emits events whenever something changes.

Core Events You’ll Use

user.created
user.updated
user.deleted

Why These Events Matter

They allow you to:

Store user data in your own database
Keep data synced automatically
Trigger workflows (emails, onboarding, analytics)
Clean up data when users are deleted

Without webhooks, your database and Clerk would drift out of sync.

3. The Real Problem (Why You Need Inngest)

Webhooks alone are not enough.

If you directly handle everything inside the webhook:

Requests become slow
Failures can break the flow
No retry mechanism
Poor scalability

You need a system that can:

Queue events
Retry failures
Run background jobs safely

That’s where Inngest comes in.

4. What Inngest Actually Does

Think of Inngest as:

A reliable event processor for your backend

Key Capabilities

Background job execution
Automatic retries
Event queueing
Batch processing
Cron jobs and scheduling

So instead of doing heavy work inside the webhook, you delegate it to Inngest.

5. How Everything Connects (Big Picture)

Here’s the full flow:

Clerk detects an event (user signup)
Clerk sends webhook → your backend
Your backend forwards event → Inngest
Inngest runs a function
Function updates your database

Simple, clean, scalable.

6. Project Setup (Based on Your Implementation)

Install Inngest

npm install inngest

Create Inngest Client

`inngest/index.js`

import { Inngest } from "inngest";

// Initialize client
export const inngest = new Inngest({ id: "glowup-app" });

// Store all functions here
export const functions = [];

Connect Inngest to Your Server

`server.js`

import { serve } from "inngest/express";
import { inngest, functions } from "./inngest/index.js";

app.get("/", (req, res) => res.send("server is running"));

// Inngest endpoint
app.use("/api/inngest", serve({ client: inngest, functions }));

At this point, your app is ready to receive and process events.

7. Creating Inngest Functions (Core Logic)

Now comes the important part: handling user data.

1. User Creation Sync

const syncUserCreation = inngest.createFunction(
  { id: "sync-user-from-clerk" },
  { event: "clerk/user.created" },
  async ({ event }) => {
    const { id, first_name, last_name, email_addresses, image_url } =
      event.data;

    let username = email_addresses[0].email_address.split("@")[0];

    const existingUser = await User.findOne({ username });

    if (existingUser) {
      username = username + Math.floor(Math.random() * 10000);
    }

    const userData = {
      _id: id,
      email: email_addresses[0].email_address,
      full_name: [first_name, last_name].filter(Boolean).join(" "),
      profile_picture: image_url,
      username,
    };

    await User.create(userData);
  }
);

2. User Update Sync

const syncUserUpdation = inngest.createFunction(
  { id: "update-user-from-clerk" },
  { event: "clerk/user.updated" },
  async ({ event }) => {
    const { id, first_name, last_name, email_addresses, image_url } =
      event.data;

    const updateUserData = {
      email: email_addresses[0].email_address,
      full_name: first_name + " " + last_name,
      profile_picture: image_url,
    };

    await User.findByIdAndUpdate(id, updateUserData);
  }
);

3. User Deletion Sync

const syncUserDeletion = inngest.createFunction(
  { id: "delete-user-with-clerk" },
  { event: "clerk/user.deleted" },
  async ({ event }) => {
    const { id } = event.data;
    await User.findByIdAndDelete(id);
  }
);

Export All Functions

export const functions = [
  syncUserCreation,
  syncUserUpdation,
  syncUserDeletion,
];

8. Important Missing Piece (Webhook → Inngest Bridge)

Your webhook should NOT contain heavy logic.

It should only:

Receive event
Verify it
Forward to Inngest

Example flow:

await inngest.send({
  name: "clerk/user.created",
  data: evt.data,
});

9. Real-World Flow (Step-by-Step)

User signs up → Clerk triggers user.created
Webhook receives event
Event sent to Inngest
Inngest runs syncUserCreation
User saved in database

Everything happens asynchronously and reliably.

10. Why This Architecture Works So Well

Clean Separation

Clerk → Auth
Your backend → Routing
Inngest → Logic

Reliability

Failed jobs retry automatically

Scalability

Handles high traffic without blocking requests

Maintainability

Logic is modular and easy to extend

11. Common Mistakes to Avoid

Doing DB Work Inside Webhook

This will slow down your API and break under load.

Skipping Event Naming Consistency

Use structured names like:

clerk/user.created
clerk/user.updated

Not Handling Edge Cases

Missing email
Duplicate usernames
Partial updates

12. Final Thoughts

This setup is not just about syncing users.

It’s about shifting your backend to an event-driven architecture.

Instead of tightly coupling everything:

You react to events
Process them asynchronously
Keep systems loosely connected

That’s how modern scalable apps are built.

State Management in React with Redux Toolkit (Beginner-Friendly Guide)

Dibyajyoti — Mon, 04 May 2026 05:21:21 +0000

When you start building React apps, managing state feels simple. A few useState hooks here and there, maybe some props passed down. But as your app grows, things get messy fast. Data starts flowing in too many directions, components become tightly coupled, and debugging turns into a headache.

That’s where state management tools like Redux Toolkit come in.

What is State Management?

State refers to the data your app needs to function. For example:

User login status
Form inputs
API data
UI states (like modals, loaders)

Managing this state means deciding:

Where it lives
Who can access it
How it gets updated

Why Not Just Use React State?

React already gives you:

useState
useContext

These are great for small apps. But in larger apps:

Props drilling becomes annoying
State gets duplicated
Logic becomes scattered

You need a central place to manage everything cleanly.

What is Redux Toolkit?

Redux Toolkit (RTK) is the modern, simplified way to use Redux.

Old Redux had issues:

Too much boilerplate
Complex setup
Confusing patterns

Redux Toolkit fixes that by:

Reducing code
Providing built-in best practices
Making state logic easier to write and maintain

Core Concepts (Simple Breakdown)

1. Store

The store is the global state container.

Think of it like:

A single object that holds all your app’s data

2. Slice

A slice represents a piece of state + its logic.

Example:

userSlice
cartSlice
themeSlice

Each slice includes:

Initial state
Reducers (functions that update state)

3. Reducers

Reducers define how state changes.

They are just functions:

(state, action) => newState

With Redux Toolkit, you can write simpler code:

state.value += 1

(No need to manually return new objects)

4. Actions

Actions are events that trigger state updates.

Example:

dispatch(increment())

5. Dispatch

Dispatch is how you send actions to the store.

Setting Up Redux Toolkit (Step-by-Step)

1. Install

npm install @reduxjs/toolkit react-redux

2. Create a Slice

// features/counterSlice.js
import { createSlice } from "@reduxjs/toolkit";

const initialState = {
  value: 0,
};

const counterSlice = createSlice({
  name: "counter",
  initialState,
  reducers: {
    increment: (state) => {
      state.value += 1;
    },
    decrement: (state) => {
      state.value -= 1;
    },
  },
});

export const { increment, decrement } = counterSlice.actions;
export default counterSlice.reducer;

3. Create Store

// app/store.js
import { configureStore } from "@reduxjs/toolkit";
import counterReducer from "../features/counterSlice";

export const store = configureStore({
  reducer: {
    counter: counterReducer,
  },
});

4. Connect to React App

// main.jsx or index.js
import { Provider } from "react-redux";
import { store } from "./app/store";

<Provider store={store}>
  <App />
</Provider>;

5. Use State in Components

import { useSelector, useDispatch } from "react-redux";
import { increment, decrement } from "./features/counterSlice";

function Counter() {
  const count = useSelector((state) => state.counter.value);
  const dispatch = useDispatch();

  return (
    <div>
      <h1>{count}</h1>
      <button onClick={() => dispatch(increment())}>+</button>
      <button onClick={() => dispatch(decrement())}>-</button>
    </div>
  );
}

Why Redux Toolkit is Worth Learning

1. Centralized State

Everything lives in one place, easier to debug.

2. Predictable Updates

State only changes through reducers.

3. Scalable Architecture

Perfect for large apps.

4. Cleaner Code

Less boilerplate than classic Redux.

When Should You Use Redux Toolkit?

Use it when:

Your app has complex state
Multiple components need the same data
You’re working on medium to large projects

Avoid it if:

Your app is very small
Simple useState works fine

Common Beginner Mistakes

Overusing Redux for small apps
Putting everything in one slice
Not structuring folders properly
Forgetting to normalize large datasets

Pro Tip

Don’t rush into Redux just because it's popular. Learn:

useState
useContext
Then move to Redux Toolkit when needed

Final Thoughts

Redux Toolkit isn’t just a library, it’s a pattern for thinking about state.

Once it clicks, your apps become:

Easier to scale
Easier to debug
Easier to maintain

If you're aiming to build real-world React apps or preparing for jobs, this is a skill that will pay off heavily.

How to Integrate Razorpay in a MERN App with Backend Verification

Dibyajyoti — Fri, 13 Feb 2026 11:32:42 +0000

Building a Learning Management System (LMS) like Ascend requires more than just displaying videos; it requires a seamless, secure way for users to purchase content.

In this article, I’ll walk you through how I integrated Razorpay into my MERN stack project, ensuring that every transaction is verified on the backend before granting course access.

The Workflow

Before diving into code, it’s important to understand the handshake between your app and Razorpay. We don't just trust the frontend; we verify every payment signature on our server to prevent fraud.

1. Frontend Setup: Preparing the UI

First, we need the Razorpay checkout script in our index.html. This injects the global Razorpay object into our window.

<script src="https://checkout.razorpay.com/v1/checkout.js"></script>

TypeScript Definitions

Since I built Ascend with TypeScript, I needed to define the Razorpay types to avoid the dreaded "property does not exist on window" error. I created a src/types/razorpay.d.ts file:

export {};

declare global {
  interface Window {
    Razorpay: new (options: RazorpayOptions) => RazorpayInstance;
  }

  interface RazorpayOptions {
    key: string;
    amount: number;
    currency: string;
    name?: string;
    description?: string;
    order_id?: string;
    handler?: (response: RazorpayResponse) => void;
    prefill?: {
      name?: string;
      email?: string;
      contact?: string;
    };
    theme?: {
      color?: string;
    };
  }

  interface RazorpayInstance {
    open(): void;
    on(event: string, callback: () => void): void;
  }

  interface RazorpayResponse {
    razorpay_payment_id: string;
    razorpay_order_id: string;
    razorpay_signature: string;
  }
}

2. Backend Phase 1: Creating the Order

When a student clicks "Enroll," we don't just open the modal. We first ask our server to create a Razorpay Order. This ensures the price is fetched from our database, not sent from the client (where it could be tampered with).

The Route:

userRouter.post("/purchase-rzp", protect, wrapAsync(purchaseCourseRZP));

The Controller:
In purchaseCourseRZP, we calculate the final price, create a "pending" purchase record in our DB, and then initialize the Razorpay order.

export const purchaseCourseRZP = async (req, res) => {
  const { courseId } = req.body;
  const { userId } = await req.auth();

  const userData = await User.findById(userId);
  const courseData = await Course.findById(courseId);

  if (!userData || !courseData) {
    throw new ExpressError(404, "Data not found");
  }

  const finalAmount =
    courseData.coursePrice -
    (courseData.discount * courseData.coursePrice) / 100;

  // Create a record in our database first
  const newPurchase = new Purchase({
    courseId: courseData._id,
    userId,
    amount: finalAmount,
    status: "pending",
  });

  await newPurchase.save();

  // initialize razorpay
  const razorpayInstance = new Razorpay({
    key_id: process.env.RZP_KEY_ID,
    key_secret: process.env.RZP_KEY_SECRET,
  });

  const options = {
    amount: Math.round(finalAmount * 100), // paisa
    currency: "INR",
    receipt: `receipt_${newPurchase._id}`,
    notes: {
      purchaseId: newPurchase._id.toString(),
    },
  };

  const order = await razorpayInstance.orders.create(options);

  res.json({
    success: true,
    orderId: order.id,
    amount: order.amount,
    key: process.env.RZP_KEY_ID,
    purchaseId: newPurchase._id,
  });
};

3. Frontend Phase 2: Opening the Modal

Once the backend returns the orderId, we trigger the Razorpay popup in CourseDetails.tsx.

  const enrollCourse = async () => {
    try {
      if (!userData) return toast.error("Login to enroll");
      if (isAlreadyEnrolled) return toast.error("Already enrolled");

      const token = await getToken();
      if (!token) return toast.error("Unauthorized");

      const { data } = await axios.post(
        backendUrl + "/api/user/purchase-rzp",
        { courseId: courseData?._id },
        { headers: { Authorization: `Bearer ${token}` } },
      );

      if (!data.success) return toast.error("Something went wrong");

      const options = {
        key: data.key,
        amount: data.amount,
        currency: "INR",
        order_id: data.orderId,

        // This runs after a successful payment
        handler: async (response: RazorpayResponse) => {
          await axios.post(
            backendUrl + "/api/user/verify-rzp",
            {
              ...response,
              purchaseId: data.purchaseId,
            },
            { headers: { Authorization: `Bearer ${token}` } },
          );

          window.location.replace("/loading/my-enrollments");
        },
      };

      const rzp = new window.Razorpay(options);
      rzp.open();
    } catch (error) {
      const msg =
        error instanceof Error ? error.message : "Something went wrong";
      toast.error(msg);
    }
  };

4. Backend Phase 3: The Critical Security Check

This is where the magic happens. When the user pays, Razorpay gives them a razorpay_signature. We must verify this signature on our server using our RZP_KEY_SECRET to confirm the payment is legitimate.

The Verification Logic:
We use HMAC SHA256 to create a signature on our end and compare it with the one provided by the frontend.

export const verifyRazorpayPayment = async (req, res) => {
  const {
    razorpay_order_id,
    razorpay_payment_id,
    razorpay_signature,
    purchaseId,
  } = req.body;

  const body = razorpay_order_id + "|" + razorpay_payment_id;

  const expectedSignature = crypto
    .createHmac("sha256", process.env.RZP_KEY_SECRET)
    .update(body)
    .digest("hex");

  if (expectedSignature !== razorpay_signature) {
    await Purchase.findByIdAndUpdate(purchaseId, {
      status: "failed",
    });
    throw new ExpressError(400, "Invalid signature");
  }

  const purchaseData = await Purchase.findById(purchaseId);
  const userData = await User.findById(purchaseData.userId);
  const courseData = await Course.findById(purchaseData.courseId);

  // enroll student
  courseData.enrolledStudents.push(userData._id);
  await courseData.save();

  userData.enrolledCourses.push(courseData._id);
  await userData.save();

  purchaseData.status = "completed";
  purchaseData.paymentId = razorpay_payment_id;
  await purchaseData.save();

  res.json({ success: true });
};

Summary

By following this flow, Ascend ensures that:

Price Integrity: Prices are calculated server-side.
Atomicity: A purchase record is created before the payment starts.
Security: No student is enrolled unless the cryptographic signature from Razorpay is verified.