DEV Community: Sospeter Mong'are

Testing M-PESA STK Push Callbacks Locally Without Exposing Your Server

Sospeter Mong'are — Wed, 18 Mar 2026 13:02:35 +0000

If you've ever built an M-PESA STK Push integration, you've probably hit this wall: M-PESA needs a publicly accessible callback URL to send payment confirmations, but your app is running on localhost. How do you test this without deploying every single time?

In this guide I'll show you a simple approach using webhook.site and a small Node.js poller script that automatically forwards M-PESA callbacks to your local machine.

What We're Building

When a user completes an STK Push payment, M-PESA sends a POST request to your callback URL with the payment result. Normally that URL has to be publicly accessible. Since localhost isn't public, we'll use webhook.site as a middleman - it catches the callback from M-PESA, and our poller script picks it up and forwards it to our local app automatically.

The flow looks like this:

M-PESA → webhook.site → our poller script → localhost

Prerequisites

Node.js installed on your machine
Your Laravel app running locally
An M-PESA Daraja API account (sandbox or production)
Basic understanding of how STK Push works

Step 1 - Get a webhook.site URL

Go to webhook.site and you'll immediately get a unique URL that looks like this:

https://webhook.site/f5d500b7-1196-42ef-8ecd-c906e49f7df36

The part after the last slash is your token. Copy it - you'll need it shortly. Keep this tab open so you can see incoming requests.

Step 2 - Store the Callback URL in Your .env

Instead of hardcoding the webhook.site URL in your code, store it in your .env file so you can swap it out easily without touching any code:

MPESA_CALLBACK_URL=https://webhook.site/f5d500b7-1196-42ef-8ecd-c906e49f7df36

On production you simply leave this variable out and it falls back to your real callback URL automatically.

Step 3 - Update Your ProcessController

In your M-PESA ProcessController where you build the STK Push request, find the CallBackURL line and update it like this:

"CallBackURL" => env('MPESA_CALLBACK_URL') ?: route('ipn.MPesa'),

What this does is simple. If MPESA_CALLBACK_URL is set in your .env it uses that. If it's not set, it falls back to your real route. This means locally it points to webhook.site, and on production it uses your actual callback route - no code changes needed when you deploy.

Step 4 - Create the Poller Script

This is the magic piece. Create a file called forwarder.js anywhere on your machine - I put mine in the project root. Paste this in:

const WEBHOOK_TOKEN = 'f5d500b7-1196-42ef-8ecd-c906e49f7df36'; // your token here
const LOCAL_URL = 'http://localhost:8000/ipn/mpesa';
const POLL_INTERVAL = 5000; // check every 5 seconds

let lastSeenId = null;

async function poll() {
    try {
        const res = await fetch(`https://webhook.site/token/${WEBHOOK_TOKEN}/requests?sorting=newest&per_page=1`);
        const data = await res.json();

        if (!data.data || data.data.length === 0) return;

        const latest = data.data[0];

        if (latest.uuid === lastSeenId) return; // already processed this one

        lastSeenId = latest.uuid;

        const body = latest.content;
        console.log('New callback received! Forwarding to local app...');
        console.log(body);

        const forward = await fetch(LOCAL_URL, {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: body
        });

        console.log('Done. Local app responded with status:', forward.status);

    } catch (err) {
        console.error('Error:', err.message);
    }
}

setInterval(poll, POLL_INTERVAL);
console.log('Watching webhook.site for incoming callbacks...');

Replace the WEBHOOK_TOKEN value with your own token from Step 1. The LOCAL_URL should match whatever route your app uses for the M-PESA IPN.

Step 5 - Run Everything

You'll need two terminals open.

Terminal 1 - start your Laravel app:

php artisan serve

Terminal 2 - start the poller:

node forwarder.js

You should see this message in Terminal 2:

Watching webhook.site for incoming callbacks...

Step 6 - Trigger a Test Payment

Go through your app's deposit flow and trigger an STK Push. Enter your phone number and hit pay. You'll get the prompt on your phone.

Once you complete the payment, here's what happens automatically:

M-PESA sends the callback to webhook.site
Your poller picks it up within 5 seconds
It forwards the full payload to your local app
Your local app processes it and updates the database

You'll see something like this in Terminal 2:

New callback received! Forwarding to local app...
{"Body":{"stkCallback":{"ResultCode":0,"CheckoutRequestID":"ws_CO_xxxxx",...}}}
Done. Local app responded with status: 200

And your database gets updated just like it would in production.

Why Not Just Use ngrok?

Ngrok is the most common answer to this problem and it works well. However if you're running a licensed script, adding a new public URL can trigger a second domain detection and invalidate your license. The webhook.site approach avoids this completely since your app never gets a new public URL - only the callback endpoint changes temporarily, and only in your local .env.

Cleaning Up After Testing

When you're done testing, remove MPESA_CALLBACK_URL from your .env or comment it out:

# MPESA_CALLBACK_URL=https://webhook.site/f5d500b7-1196-42ef-8ecd-c906e49f7df36

Your app will fall back to the real route automatically. Stop the forwarder.js script and you're done. Nothing was changed in your codebase, nothing gets pushed to production.

Summary

The whole setup takes about 5 minutes and gives you a proper local testing loop for M-PESA callbacks without ngrok, without deploying, and without touching your production environment. The poller script is lightweight, requires no dependencies beyond Node.js, and you can reuse the same approach for any other payment gateway callback - just change the LOCAL_URL to point to the right IPN route.

How to Run Multiple PHP Versions on Windows and Switch Easily

Sospeter Mong'are — Sun, 15 Mar 2026 12:45:08 +0000

When working on modern PHP projects like those built with Laravel, you will eventually run into version conflicts.

One project may require PHP 8.3, while another older project may still run on PHP 8.1 or 8.2. If your system only has one PHP version installed, you will constantly run into errors like:

Composer detected issues in your platform:
Your Composer dependencies require a PHP version ">= 8.3.0".
You are running 8.2.12.

Instead of reinstalling PHP every time you switch projects, the better solution is to install multiple PHP versions and switch between them instantly.

One of the easiest ways to achieve this on Windows is by using Scoop, a lightweight package manager designed for developers.

Below is a simple and clean setup.

1. Install Scoop

Open PowerShell and run:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
irm get.scoop.sh | iex

Confirm installation:

scoop --version

Scoop installs tools into your user directory and avoids the common permission problems that occur with traditional installers.

2. Add the Versions Bucket

Scoop organizes packages using "buckets". To install multiple PHP versions, you need the versions bucket.

scoop bucket add versions

This bucket contains packages like:

php81
php82
php83

3. Install Multiple PHP Versions

You can now install any PHP version you need.

Example:

scoop install php82
scoop install php83

Check installed packages:

scoop list

At this point both PHP versions exist on your system, but only one will be active at a time.

4. Switch Between PHP Versions

To switch to PHP 8.3:

scoop reset php83

To switch to PHP 8.2:

scoop reset php82

Verify the active version:

php -v

This instantly updates your terminal environment.

5. Running Your Laravel Project

Once the correct version is active, you can start your project normally:

php artisan serve

If the project requires PHP 8.3, switching to php83 will resolve the platform check error.

Why This Approach Is Powerful

Modern development environments rarely use a single runtime version.

You may have projects such as:

Legacy project running PHP 8.1
Production system using PHP 8.2
New Laravel 11 applications requiring PHP 8.3

Using Scoop allows you to move between these environments instantly without reinstalling anything.

Bonus: Install Other Developer Tools

Scoop can also install common development tools:

scoop install composer
scoop install nodejs
scoop install git

This creates a clean development environment that is easy to maintain and update.

Final Thoughts

Managing multiple PHP versions used to be complicated on Windows. With Scoop, the process becomes simple and developer friendly.

Instead of fighting your environment, you can focus on building applications and switching versions only when necessary.

For backend developers working with frameworks like Laravel, this setup saves time and prevents version related errors during development.

M-PESA DARAJA API - C2B Integration Guide

Sospeter Mong'are — Fri, 13 Mar 2026 09:42:47 +0000

Introduction

If you are building a web or mobile app that needs to receive payments from M-PESA customers in Kenya, the Safaricom Daraja API is the tool you need. This guide will walk you through everything from scratch no prior API experience required.

By the end of this guide, you will understand:

What the C2B API is and how it works
How to set up and test it in the sandbox using Postman
What ValidationURL and ConfirmationURL do
How to take your integration live

What is C2B?

C2B stands for Customer to Business. It refers to the flow of money from an individual customer to your business. When a customer pays your Paybill or Till number via M-PESA, that is a C2B transaction.

The C2B API allows your application to receive real-time notifications every time a payment comes in, so you can automate things like:

Marking an order as paid
Sending a payment receipt to the customer
Updating your accounting system automatically

What is Daraja?

Daraja (which means "bridge" in Swahili) is Safaricom's developer portal that gives you access to the M-PESA API. It provides a sandbox (testing) environment where you can simulate payments without using real money, and a production environment for real transactions.

Portal URL: https://developer.safaricom.co.ke

PART ONE: SANDBOX TESTING

Before using real money, Daraja gives you a sandbox environment to safely test your integration. This is where you should always start.

STEP 1 - Create a Daraja Account & App

Set up your developer profile

Go to https://developer.safaricom.co.ke and click Sign Up
Fill in your details and verify your email address
Once logged in, click "My Apps" in the top navigation menu
Click "Create Sandbox App" - give it any name (e.g. "MyShopC2B")
Under the products section, check "M-Pesa Sandbox" to enable sandbox APIs
Click "Create App"

Your app will now appear in the "My Apps" section. Click on it and you will see two important values:

Key	Description
Consumer Key	Acts like your app's username for the API
Consumer Secret	Acts like your app's password for the API

💾 Save These! Copy your Consumer Key and Consumer Secret somewhere safe. You will need them for every API call.

STEP 2 - Get an Access Token

Authenticate before making any API call

Every single API request to Daraja requires an access token. Think of it like a temporary password that proves your identity. It expires after 1 hour and you need to generate a new one.

In Postman:

Method: GET
URL: https://sandbox.safaricom.co.ke/oauth/v1/generate?grant_type=client_credentials

Go to the Authorization tab in Postman:

Auth Type: Basic Auth
Username: paste your Consumer Key
Password: paste your Consumer Secret

Click Send. You should get a response like this:

{
  "access_token": "SGWcJPtNtYNPGm1DqBNqZZZZZZ",
  "expires_in": "3599"
}

📋 Copy It! Copy the access_token value. You will paste it in the Authorization header of every request below.

STEP 3 - Understanding Your Callback URLs

The heart of how C2B notifications work

Before registering your URLs, it is important to understand what each one does. When a customer makes a payment, Safaricom contacts your server at two different points in the payment flow:

📱 Customer Pays  →  🔍 ValidationURL  →  ✅ ConfirmationURL
  (Sends money)      ("Should I allow    ("Payment done,
                          this?")          record it!")

ValidationURL - "Should I allow this payment?"

This is called before the payment is processed. Safaricom sends you the payment details and waits for your response. You can accept or reject the payment based on your own business logic - for example, checking if the account number the customer entered actually exists in your system.

You respond with one of the following:

// Accept the payment
{ "ResultCode": "0", "ResultDesc": "Accepted" }

// Reject the payment
{ "ResultCode": "C2B00012", "ResultDesc": "Rejected" }

⚠️ Note: ValidationURL is optional. If you set ResponseType to "Completed" when registering, Safaricom skips validation and auto-accepts all payments. This is recommended for beginners.
Validation URL is the URL that receives the validation request from API upon payment submission. The validation URL is only called if external validation on the registered short code is enabled.
(By default, External Validation is disabled)

ConfirmationURL - "Payment went through, save the details"

This is called after the payment has been successfully processed. At this point, you cannot reject the payment - it has already gone through. This is where your app should record the transaction, update a database, send a receipt, or trigger any other business logic.

Feature	ValidationURL	ConfirmationURL
When called	BEFORE payment is processed	AFTER payment is processed
Purpose	Accept or reject the payment	Record and act on the payment
Your response matters?	YES - can block the payment	NO - informational only
Required?	Optional	Yes, always required

🏪 Real-world analogy: Think of it like a supermarket checkout. The ValidationURL is the cashier checking if your loyalty card is valid before ringing up. The ConfirmationURL is the receipt printer - it just records that the sale happened.

STEP 4 - Get a Free Callback URL for Testing

Use webhook.site to capture callbacks

Your ValidationURL and ConfirmationURL must be publicly accessible HTTPS endpoints. For sandbox testing, you do not need a real server - you can use a free tool called webhook.site.

Go to https://webhook.site in your browser
You will instantly get a unique URL like: https://webhook.site/abc-123-xyz
Copy that URL - you will use it as both your ValidationURL and ConfirmationURL for testing
Leave the webhook.site tab open. Callbacks from Safaricom will appear here in real time

🚫 URL Rules: Never use words like "MPesa", "M-Pesa", or "Safaricom" in your URLs - the system will block them. Also, localhost URLs will not work. Always use a proper HTTPS URL.

STEP 5 - Register Your Callback URLs

Tell Safaricom where to send payment notifications

Now you will call the Register URL API to link your callback URLs to your Paybill shortcode.

In Postman:

Method: POST
URL: https://sandbox.safaricom.co.ke/mpesa/c2b/v1/registerurl

Headers tab - add these two headers:

Header Key	Header Value
Authorization	`Bearer YOUR_ACCESS_TOKEN` (paste the token from Step 2)
Content-Type	`application/json`

Body tab - select "raw" and "JSON", then paste:

{
  "ShortCode": "600584",
  "ResponseType": "Completed", // Either Cancelled or Completed
  "ConfirmationURL": "https://webhook.site/your-unique-url",
  "ValidationURL": "https://webhook.site/your-unique-url"
}

Field	Explanation
ShortCode	The sandbox test Paybill number (600584 is the default sandbox shortcode)
ResponseType	"Completed" means skip validation and auto-accept all payments
ConfirmationURL	Your webhook.site URL - where Safaricom sends payment confirmations
ValidationURL	Your webhook.site URL - where Safaricom asks for approval (optional here)

A successful response looks like:

{
  "OriginatorCoversationID": "...",
  "ResponseCode": "0",
  "ResponseDescription": "success"
}

STEP 6 - Simulate a C2B Payment

Pretend a customer is paying you

Now for the fun part - you will simulate a customer sending money to your Paybill. Safaricom provides a test phone number you can use.

In Postman:

Method: POST
URL: https://sandbox.safaricom.co.ke/mpesa/c2b/v1/simulate

Use the same Authorization header as before, then paste this JSON body:

{
  "ShortCode": "600584",
  "CommandID": "CustomerPayBillOnline",
  "Amount": "100",
  "Msisdn": "254708374149",
  "BillRefNumber": "INV001"
}

Field	Explanation
ShortCode	Your sandbox Paybill number
CommandID	Use `"CustomerPayBillOnline"` for Paybill, or `"CustomerBuyGoodsOnline"` for Till
Amount	The amount the simulated customer is paying (in KES)
Msisdn	The test customer phone number - always use `254708374149` in sandbox
BillRefNumber	The account reference - e.g. an invoice number or order ID

STEP 7 - Check Your Callback

See what your app would receive

After sending the simulation request, go to your webhook.site tab. Within a few seconds, you should see a POST request arrive. This is exactly the payload your real server would receive when a customer pays.

It will look something like this:

{
            "TransactionType": "Pay Bill",
            "TransID": "UCB030CBG1",
            "TransTime": "20260311161727",
            "TransAmount": "1.00",
            "BusinessShortCode": "600991",
            "BillRefNumber": "account001",
            "InvoiceNumber": "",
            "OrgAccountBalance": "4635316.60",
            "ThirdPartyTransID": "",
            "MSISDN": "bbff37cea44ac0b2d964ee0dfb8d2df8513dc7ba1b36129a929fc3fbd6dd4af4",
            "FirstName": "John"
}

Field	Value	Explanation
`TransactionType`	`Pay Bill`	The type of transaction. Will be "Pay Bill" for Paybill or "Buy Goods" for Till numbers
`TransID`	`UCB030CBG1`	Unique M-PESA transaction ID. Use this as your reference to avoid processing the same payment twice
`TransTime`	`20260311161727`	Timestamp of the transaction in `YYYYMMDDHHmmss` format. This one means 11 March 2026 at 16:17:27
`TransAmount`	`1.00`	The amount the customer paid in KES
`BusinessShortCode`	`600991`	Your Paybill or Till number that received the payment
`BillRefNumber`	`account001`	The account number the customer entered when paying. Use this to identify which customer or order the payment belongs to
`InvoiceNumber`	(empty)	Optional invoice number. Usually empty for most C2B transactions
`OrgAccountBalance`	`4635316.60`	Your Paybill account balance after this transaction was processed
`ThirdPartyTransID`	(empty)	Used in some integrations for a third-party reference. Usually empty
`MSISDN`	`bbff37c...`	The customer's phone number. In sandbox it is returned as a hashed/masked value for privacy.
`FirstName`	`John`	The first name of the customer as registered on M-PESA

💡 Tip: The three most important fields to save in your database are TransID (to prevent duplicate processing), BillRefNumber (to identify the customer/order), and TransAmount (to confirm the correct amount was paid).

In a real application, you would read this JSON payload and use the TransAmount, BillRefNumber, and MSISDN fields to update your database and send a receipt to the customer.

⚠️ Sandbox Note: Sandbox callbacks can sometimes be unreliable. If your webhook.site does not receive anything after 30 seconds, try the simulation again. This is a known sandbox issue.

Full C2B Flow Recap

Step	Action	What Happens
1	Get Token	You authenticate with your Consumer Key & Secret and receive a temporary access token
2	Register URLs	You tell Safaricom where to send payment notifications
3	Customer Pays	A real or simulated customer sends money to your Paybill or Till number
4	Validation	Safaricom hits your ValidationURL asking "should I accept this?" (optional)
5	Confirmation	Safaricom hits your ConfirmationURL with the full payment details
6	Your App Acts	Your server reads the payload and updates the database, sends a receipt, etc.

PART TWO: GOING LIVE

Once your sandbox integration is working correctly, you are ready to go live and process real M-PESA transactions.

Prerequisites Before Going Live

Make sure you have all of the following before applying for live credentials:

A working sandbox integration - all steps above tested and confirmed working
A registered and verified Paybill or Till Number from Safaricom
An active Safaricom G2 Business Admin account (used to verify your shortcode)
A real publicly accessible HTTPS server URL (not localhost, not webhook.site) for your callback URLs
Company documentation: Certificate of incorporation, KRA PIN, and directors' IDs (for businesses)

🏢 Get a Paybill First: To get a Paybill number, visit a Safaricom shop with your company registration documents. For a Till number, you can apply via the Safaricom self-onboarding portal. Processing takes 24–72 hours.

Step 1 - Register on the Safaricom G2 Portal

The G2 portal (https://org.ke.mpesa.com) is Safaricom's business management platform. You need an account here so Daraja can verify you own the Paybill or Till number you want to use.

Send an email to M-PESABusiness@safaricom.co.ke requesting a Business Admin account
Attach required documents: company registration certificate, KRA PIN, directors' IDs, and a signed board resolution
Safaricom will create your G2 account and send login credentials
Log in, change your password, and create an "assistant role" user - these credentials will be used in the next step

Step 2 - Confirm Your Sandbox Integration is Solid

Before applying to go live, make sure all of the following are working in sandbox:

Access token generation is working
URL registration returns a success response
Simulated payments are triggering callbacks to your server
Your server is responding with the correct 200 OK responses
Your database or backend is correctly parsing and saving the callback payload

Step 3 - Click "Go Live" on the Daraja Portal

Log into https://developer.safaricom.co.ke
Go to "My Apps" and open your app
Click the "Go Live" button
Select "Verification by Shortcode" as the method
Enter your Paybill/Till shortcode and your G2 assistant user credentials
Select the API products you need (e.g. C2B)
Upload your test cases - a document showing what you tested and the results
Submit your request

⏱️ Approval Time: Safaricom typically takes 24–72 hours to review and approve your live request. You will receive your production credentials by email once approved.

Step 4 - Replace Sandbox Credentials with Live Ones

Once approved, update your application to use production values:

What to Change	Sandbox → Production
API Base URL	`sandbox.safaricom.co.ke` → `api.safaricom.co.ke`
Consumer Key	Sandbox key → New live Consumer Key
Consumer Secret	Sandbox secret → New live Consumer Secret
ShortCode	`600584` (test) → Your actual Paybill/Till number
Callback URLs	webhook.site URLs → Your real HTTPS server URLs

Step 5 - Test a Small Live Transaction

After switching to production credentials, do a small test with real money (e.g. KES 1) to confirm everything works end to end:

Pay your Paybill from a real M-PESA number
Confirm your ConfirmationURL receives the callback
Verify your database is updated correctly
Check that the customer receives the expected response or receipt

📝 Keep Logs: Always log every transaction in the early stages of going live. Implement retry logic in case of failed callbacks - Safaricom may occasionally retry if your server is slow to respond.

Common Mistakes to Avoid

#	❌ Do NOT do this	✅ Do this instead
1	Include "MPesa" or "Safaricom" in your callback URLs	Use neutral words in your URLs e.g. `/payment/confirm`
2	Use localhost or 127.0.0.1 as your callback URL	Host your app or use a tunneling tool like Ngrok (sandbox only)
3	Use webhook.site/ngrok URLs in production	Use a real, stable HTTPS server in production
4	Apply for all products without knowing what you need	Plan ahead - decide which APIs you need before going live
5	Forget to renew your access token every hour	Generate a fresh token on each session or add auto-renewal logic
6	Ignore the callback response format	Always respond with `200 OK` and valid `ResultCode`/`ResultDesc`

Useful Resources

Resource	URL
Daraja Developer Portal	https://developer.safaricom.co.ke
Daraja API Documentation	https://developer.safaricom.co.ke/APIs
Safaricom G2 Business Portal	https://org.ke.mpesa.com
Test Callback Tool	https://webhook.site
M-PESA Business Email	M-PESABusiness@safaricom.co.ke

If you need payment integrations, You can reach out to me on email.

Happy building!

Understanding APIs: Core Knowledge Every Developer Should Have

Sospeter Mong'are — Mon, 09 Mar 2026 20:10:20 +0000

Application Programming Interfaces (APIs) are the backbone of modern software. They enable different applications and services to communicate with each other, exchange data, and perform actions across systems. Whether you are working in frontend, backend, or product development, understanding how APIs work is essential.

Below are the key concepts every developer should understand when learning APIs.

1. REST

Most modern APIs follow the REST (Representational State Transfer) architecture. REST defines how resources are structured and accessed over the web. In a REST API, resources such as users, payments, or products are accessed through endpoints.

Example:

GET /users
GET /orders/123

REST helps maintain consistency and makes APIs easier to understand and use.

2. HTTP Methods

HTTP methods define the type of action you want to perform on a resource. The most common methods include:

GET - Retrieve data from the server
POST - Create a new resource
PUT or PATCH - Update an existing resource
DELETE - Remove a resource

Understanding when to use each method is fundamental when building or consuming APIs.

3. Status Codes

Status codes tell you the outcome of an API request. They help developers quickly determine whether a request succeeded or failed.

Common examples include:

200 - Request successful
201 - Resource created successfully
400 - Bad request
401 - Unauthorized
404 - Resource not found
500 - Server error

Learning how to interpret these codes is crucial for debugging integrations.

4. JSON

Most APIs use JSON (JavaScript Object Notation) as the format for exchanging data. JSON is lightweight and easy for both humans and machines to read.

Example response:

{
  "id": 101,
  "name": "John Doe",
  "email": "john@example.com"
}

Developers should be comfortable reading, writing, and validating JSON structures.

5. Authentication and Authorization

APIs must ensure that only authorized users or systems can access them. Authentication verifies identity, while authorization determines what actions are allowed.

Common methods include:

API Keys
OAuth 2.0
JWT (JSON Web Tokens)
Basic Authentication

Many business APIs rely heavily on authentication mechanisms, such as the Stripe API, Twilio API, and M-Pesa Daraja API.

6. Headers

HTTP headers provide additional information about the request or response.

Common headers include:

Authorization - used to pass authentication tokens
Content-Type - defines the format of the request body
Accept - indicates the expected response format

Understanding headers helps you control how APIs process requests.

7. Request and Response Structure

An API request can contain several components:

Path parameters
Query parameters
Request body
Headers

Example request:

GET /transactions?limit=10

The response typically returns structured data along with a status code.

8. Error Handling

Well-designed APIs return clear error messages when something goes wrong.

Example:

{
  "error": "invalid_request",
  "message": "Missing required field"
}

Understanding error responses helps developers quickly diagnose and fix issues during integration.

9. Pagination

When APIs return large datasets, they often split results into smaller pages.

Common parameters include:

limit
offset
cursor

Example:

GET /transactions?limit=20&offset=40

Pagination ensures efficient data retrieval without overloading the system.

10. Rate Limiting

To protect infrastructure, many APIs limit how many requests a client can make within a given time period.

If the limit is exceeded, the server may return:

429 Too Many Requests

Developers must design their systems to handle rate limits gracefully.

11. Webhooks

Webhooks allow systems to receive real-time notifications when an event occurs, instead of constantly polling an API.

For example, a payment service may send a webhook when a payment is completed. This pattern is widely used in platforms like the Stripe API.

12. API Documentation

Good documentation is essential when working with APIs. Many APIs use tools like Swagger, Postman, or the OpenAPI Specification to clearly describe endpoints, parameters, and responses.

Being able to read and interpret API documentation is a critical developer skill.

Conclusion

APIs power the digital world. From payment processing to messaging services and cloud platforms, they enable systems to interact seamlessly.

For anyone building modern applications, understanding REST, HTTP methods, status codes, JSON, authentication, headers, pagination, rate limits, and webhooks is not optional. It is foundational knowledge that every developer should master.

What is Vite

Sospeter Mong'are — Wed, 18 Feb 2026 09:47:07 +0000

If you just downloaded a React project and saw something like:

npm run dev

And then an error mentioning vite, you might be wondering:

What exactly is Vite?

Let us break it down in simple terms.

What Is Vite?

Vite is a tool that helps you run and build modern frontend applications like React, Vue, or plain JavaScript apps.

You can think of it as:

A development server
A build tool
A translator for modern JavaScript

All combined into one.

Why Do We Need Vite?

Modern frontend code includes things like:

JSX (used in React)
TypeScript
ES Modules
CSS imports inside JavaScript
Modern JavaScript features

Browsers do not fully understand all of this directly.

Vite takes your modern code and converts it into something the browser can understand.

Without a tool like Vite, your React app would not run properly in the browser.

What Does Vite Actually Do?

When you run:

npm run dev

Vite:

Starts a local development server
Usually something like:
http://localhost:5173
Loads your app into the browser
Watches your files for changes
Automatically refreshes the browser when you save changes

This makes development fast and smooth.

Simple Analogy

Imagine building a car:

React is the engine components
Your code is the raw material
The browser is the driver
Vite is the factory that assembles everything so the car can run

Without the factory, the parts do not become a working car.

Is Vite Part of React?

No.

React is just a JavaScript library for building user interfaces.

It does not:

Start a server
Compile files
Bundle your code
Optimize your app for production

Vite is what makes your React project actually run during development and prepares it for deployment.

Why Is Vite Popular?

Vite is popular because it is:

Very fast
Simple to configure
Lightweight
Easy to set up

Compared to older tools like Webpack, Vite starts almost instantly and reloads changes much faster.

What Happens If Vite Is Missing?

If you see an error like:

'vite' is not recognized as an internal or external command

It usually means:

You have not installed project dependencies yet.

The fix is usually:

npm install
npm run dev

Final Thoughts

If you are building modern frontend apps, Vite is the tool that:

Runs your app locally
Converts modern code to browser ready code
Makes development faster
Prepares your app for production

In short:

Vite is the engine that makes your frontend project come alive.

The Engineer as a Decision Maker, Not a Developer

Sospeter Mong'are — Wed, 11 Feb 2026 08:43:49 +0000

For years, the software industry has romanticized the image of the engineer as someone who writes elegant code, masters frameworks, and ships features at lightning speed. But the most valuable engineers today are not defined by how fast they type or how many languages they know.

They are defined by the quality of their decisions.

The shift from developer to decision maker is what separates average engineers from high impact engineers. And in a world where AI can generate code in seconds, this shift is no longer optional. It is essential.

Code Is a Tool. Decisions Create Value.

A junior developer focuses on implementation:

How do I build this?
Which syntax should I use?
How do I fix this error?

A decision making engineer asks different questions:

Should we build this at all?
What problem are we actually solving?
Is this the simplest solution?
What are the long term consequences?

The difference is subtle but powerful.

Code is the output. Decisions determine whether that output is useful, scalable, secure, and aligned with business goals.

An engineer who understands tradeoffs between performance and cost, speed and maintainability, abstraction and simplicity becomes far more valuable than someone who only knows how to implement tickets.

Every Line of Code Is a Liability

Writing code feels productive. But every line added is something that must be maintained, tested, debugged, documented, and eventually refactored.

A decision driven engineer understands that sometimes the best decision is:

Reuse instead of rebuild.
Integrate instead of invent.
Simplify instead of scale prematurely.
Delete instead of add.

Strong engineers reduce complexity. They do not increase it just to prove skill.

They think in systems, not just scripts.

Technical Choices Are Business Decisions

Choosing a database is not just a technical act. It affects:

Hosting costs
Scaling strategy
Hiring requirements
Vendor lock in
Performance under growth

Choosing to microservice too early can slow a startup. Choosing to ignore observability can cost days in downtime. Choosing the wrong payment flow can affect revenue.

Engineers who understand that architecture impacts money, users, and growth move from being implementers to strategic contributors.

They stop waiting for instructions. They start shaping direction.

Decision Making Requires Context

You cannot make strong engineering decisions without understanding:

The product vision
The customer pain points
The revenue model
The team capacity
The timeline constraints

This is why the best engineers attend product meetings, ask business questions, and care about metrics.

They do not hide behind code.

They know that a technically perfect solution that misses market timing is a failure.

AI Is Raising the Bar

With AI tools generating boilerplate, scaffolding APIs, and even debugging, the value of raw coding skill is decreasing.

The competitive advantage is now:

Problem framing
Tradeoff analysis
Risk evaluation
Architectural thinking
Clear communication

Anyone can generate code.

Not everyone can decide what should be generated.

From Task Taker to Owner

A developer waits for a ticket.

A decision making engineer asks:

What outcome are we targeting?
Is this the highest priority problem?
Is there a faster way to deliver impact?
What will break in six months if we do this?

Ownership changes everything.

Instead of “I implemented what I was told,” the mindset becomes, “I am responsible for the result.”

That shift transforms careers.

How to Become a Decision Driven Engineer

Study tradeoffs, not just syntax.
Learn why systems fail. Learn scaling patterns. Learn architectural mistakes.
Understand the business model.
If the product makes money from transactions, uptime and performance matter differently than if it makes money from subscriptions.
Simplify aggressively.
Complexity compounds. Simplicity scales.
Communicate clearly.
The best decisions are useless if you cannot explain them.
Think long term.
Ask what this decision looks like at 10x growth.

The Future Engineer

The future engineer is not the person who knows the most frameworks.

It is the person who:

Knows when not to use one.
Understands impact beyond code.
Aligns technology with strategy.
Chooses clarity over cleverness.
Optimizes for outcomes, not ego.

Code is still important. But code is no longer the differentiator.

Judgment is.

And the engineers who master decision making will shape products, teams, and industries long after the syntax they once memorized becomes obsolete.

React Hooks Explained (Beginner-Friendly)

Sospeter Mong'are — Mon, 09 Feb 2026 05:08:00 +0000

First: What is a Hook?

A Hook is just a special function React gives you to “plug into” React features like:

State
Lifecycle
Context
Performance optimization

Hooks always:

Start with use
Are called inside components only
Follow predictable rules

The Core Hooks (You should learn these)

These are the hooks you’ll use in almost every React app.

1️⃣ `useState` — Store changing data

You already know this one 👍

const [count, setCount] = useState(0);

Use it for:

Form inputs
Toggles
Counters
Loading states

Mental model:

“Component-level variables that cause re-render when changed.”

2️⃣ `useEffect` — Run side effects

Also familiar now.

useEffect(() => {
  fetchData();
}, []);

Use it for:

API calls
Subscriptions
Timers
Logging

Mental model:

“Run this after rendering or when something changes.”

3️⃣ `useContext` — Read global data

Used with React Context.

const user = useContext(UserContext);

Use it for:

Logged-in user
Theme
Language

Mental model:

“Read shared data without passing props.”

Secondary Hooks (Learn after basics)

These make apps cleaner and faster.

4️⃣ `useRef` — Store values without re-rendering

const inputRef = useRef(null);

Use it for:

Accessing DOM elements
Storing values that shouldn’t trigger UI updates
Timers, counters, previous values

Example:

inputRef.current.focus();

Mental model:

“A box that holds data across renders without re-rendering.”

5️⃣ `useReducer` — Advanced state logic

Alternative to useState.

const [state, dispatch] = useReducer(reducer, initialState);

Use it when:

State logic is complex
Many related state updates exist

Backend analogy:

Reducer = controller logic

6️⃣ `useMemo` — Cache expensive calculations

const result = useMemo(() => heavyCalculation(data), [data]);

Use it to:

Prevent unnecessary recalculations
Improve performance

Mental model:

“Only recalculate if inputs change.”

7️⃣ `useCallback` — Cache functions

const handleClick = useCallback(() => {
  doSomething();
}, []);

Use it when:

Passing functions to child components
Preventing unnecessary re-renders

Mental model:

“Same function instance unless dependencies change.”

Advanced / Rare Hooks (Know they exist)

You don’t need these early on, but it’s good to know them.

8️⃣ `useLayoutEffect`

Like useEffect, but runs before browser paint.

Use only when:

You need to measure layout sizes
You see flickering UI issues

⚠️ Rarely needed.

9️⃣ `useImperativeHandle`

Controls what a parent can access from a child component.

Used with forwardRef.

Advanced use cases only.

10️⃣ `useId`

Generates unique IDs.

const id = useId();

Useful for:

Form inputs
Accessibility (labels)

Custom Hooks (VERY IMPORTANT)

You can create your own hooks.

function useGroups() {
  const [groups, setGroups] = useState([]);

  useEffect(() => {
    fetchGroups().then(setGroups);
  }, []);

  return groups;
}

Use them to:

Reuse logic
Keep components clean

Mental model:

“Extract reusable logic into a function.”

Beginner Learning Order (Recommended)

Here’s the safe learning path:

useState
useEffect
useContext
useRef
useReducer
useMemo & useCallback
Custom Hooks

What You Should NOT Do as a Beginner 🚫

Don’t memorize all hooks
Don’t use useMemo everywhere
Don’t optimize too early
Don’t jump to advanced hooks before basics

Quick Summary Table

Hook	Purpose	Learn When
useState	Local state	Day 1
useEffect	Side effects	Day 1
useContext	Global state	Early
useRef	DOM & mutable values	Early
useReducer	Complex logic	Intermediate
useMemo	Performance	Later
useCallback	Stable functions	Later

Final Takeaway

You don’t need all hooks to build real apps.
You need to understand a few deeply.

If you master:

useState
useEffect
useContext

You can build most production apps comfortably.

The First Big Mistake: Thinking Software Engineering Is Just Coding

Sospeter Mong'are — Wed, 04 Feb 2026 10:42:02 +0000

One of the biggest misconceptions shaping today’s AI panic is the belief that software engineering equals writing code. From that flawed assumption comes an even bigger conclusion: “If AI can write code, then AI will replace software engineers.”

This logic sounds convincing-until you understand what software engineering actually is.

Coding Is the Output, Not the Job

Writing code is only the visible output of software engineering, not the work itself.

Software engineering is about:

Understanding ambiguous problems
Translating human needs into technical systems
Designing architectures that scale
Making trade-offs between performance, cost, security, and time
Anticipating failure, misuse, and edge cases
Maintaining systems long after they are written

Code is simply the medium through which these decisions are expressed.

If you remove the thinking, the code becomes meaningless.

Software Engineering Is Decision-Making Under Constraints

Real-world systems don’t fail because someone didn’t know syntax.
They fail because:

Requirements were misunderstood
Assumptions were wrong
Systems didn’t scale as expected
Trade-offs weren’t thought through
Human behavior wasn’t considered

These are engineering problems, not typing problems.

AI can generate code, but it does not own responsibility. It doesn’t sit in meetings to clarify vague requirements. It doesn’t get paged at 2 a.m. when production is down. It doesn’t weigh business risk against technical purity.

Engineers do.

AI Is Powerful at Code - Weak at Context

AI excels at:

Pattern matching
Rewriting existing logic
Generating boilerplate
Speeding up repetitive tasks

But software lives in context:

Business goals change
Users behave unpredictably
Legal and compliance rules evolve
Systems interact with messy, legacy infrastructure

Context is not static. It’s political, social, economic, and human. That’s where engineering judgment lives-and where AI struggles the most.

The Real Role of a Software Engineer

A software engineer is closer to a systems thinker than a typist.

They:

Ask why before how
Challenge requirements that don’t make sense
Design for failure, not perfection
Communicate trade-offs to non-technical stakeholders
Take responsibility for outcomes, not just outputs

This is why senior engineers write less code than juniors-but create far more value.

What AI Actually Changes

AI doesn’t eliminate software engineers. It raises the bar.

Just like:

Compilers didn’t eliminate programmers
Frameworks didn’t eliminate engineers
Cloud computing didn’t eliminate infrastructure thinking

AI removes low-level friction and exposes who actually understands systems.

The future belongs to engineers who can:

Think clearly
Reason about systems
Make sound decisions
Use AI as a tool, not fear it as a replacement

Conclusion

The first mistake was reducing software engineering to coding.
The second mistake is assuming automation replaces thinking.

AI will write more code.
Humans will still decide what should exist, why it should exist, and whether it should exist at all.

That’s not going away anytime soon.

Passing Props in React (How Components Talk to Each Other)

Sospeter Mong'are — Wed, 04 Feb 2026 06:50:00 +0000

Why Passing Props Exists

In React:

Components are isolated
One component cannot access another’s data directly

So how do they communicate?

👉 Props

What Are Props?

Props are inputs to a component.

Think of them like:

Function parameters
API request data

Simple Example

function Greeting({ name }) {
  return <h1>Hello {name}</h1>;
}

function App() {
  return <Greeting name="John" />;
}

What’s Happening?

App sends data → name="John"
Greeting receives it → { name }
UI updates based on props

Backend analogy:

function greeting(name) {
  return `Hello ${name}`;
}

greeting("John");

Props Are Read-Only

❌ This is NOT allowed:

props.name = "Mike";

Props are:

Immutable
Owned by the parent

If data must change → it belongs in state, not props.

Common Beginner Mistake

Trying to store everything in one component.

Correct mindset:

Components should receive data, not own everything.

Key Takeaway

Props are how data flows downward in React.

No props → no real app.

Lifting State Up in React (Sharing State the Right Way)

Sospeter Mong'are — Wed, 04 Feb 2026 06:50:00 +0000

The Problem

Two components need the same data.

Example:

Login component logs in a user
Dashboard component needs that user info

If both manage their own state → chaos.

The Solution: Lift State Up

Move the state to the closest common parent.

Example

function App() {
  const [user, setUser] = useState(null);

  return (
    <>
      <Login setUser={setUser} />
      <Dashboard user={user} />
    </>
  );
}

How This Works

App owns the state
Login updates it
Dashboard consumes it

One source of truth.

Backend Analogy

Think of:

Parent → service layer
Children → controllers

Controllers don’t own data — services do.

When to Lift State

Lift state when:

Multiple components need the same data
Data must stay in sync

Warning Sign

If you’re passing props through many layers, stop.

You’re about to need global state.

Key Takeaway

Shared data should live above the components that use it

Understanding `useContext` in React (A Beginner-Friendly Guide)

Sospeter Mong'are — Tue, 03 Feb 2026 13:33:16 +0000

If you’re learning React, you’ll quickly run into this question:

“How do I share data between many components without passing props everywhere?”

That problem is exactly why useContext exists.

1. The Problem `useContext` Solves

Let’s start with the pain.

Imagine this component tree:

App
 └── Layout
     └── Sidebar
         └── Profile
             └── Avatar

Now imagine:

The logged-in user lives in App
Only Avatar needs the user’s name

Without context, you must pass props like this:

<App user={user}>
  <Layout user={user}>
    <Sidebar user={user}>
      <Profile user={user}>
        <Avatar user={user} />
      </Profile>
    </Sidebar>
  </Layout>
</App>

This is called prop drilling.

Why prop drilling is bad

Components receive data they don’t need
Code becomes noisy
Refactoring is painful
Bugs creep in easily

2. What Is Context (Plain English)

Context is a way to store data once and read it anywhere below.

In human terms:

“Make this data global for part of the app.”

Context does not replace state.
It just changes how state is shared.

3. What Is `useContext`?

useContext is the hook that lets a component read data from a Context.

Think of it as:

“Give me the shared data without passing props.”

4. A Very Simple Example (No Complexity)

Step 1: Create a Context

import { createContext } from "react";

const UserContext = createContext(null);

export default UserContext;

This creates a container for shared data.

Step 2: Provide the Context (at the top)

import { useState } from "react";
import UserContext from "./UserContext";

function App() {
  const [user, setUser] = useState({ name: "John" });

  return (
    <UserContext.Provider value={user}>
      <Dashboard />
    </UserContext.Provider>
  );
}

What’s happening:

UserContext.Provider wraps your app
value={user} is the shared data
Every component inside can access it

Step 3: Consume the Context

import { useContext } from "react";
import UserContext from "./UserContext";

function Dashboard() {
  const user = useContext(UserContext);

  return <h1>Hello {user.name}</h1>;
}

No props.
No drilling.
Just access.

5. Backend Mental Model (Very Important)

Think of Context like:

Backend Concept	React Context
Config file	Context
Auth middleware	Provider
Request access	useContext

Once data is in Context:

You don’t pass it manually
You just read it when needed

6. When Should You Use `useContext`?

Good use cases

Logged-in user
Theme (dark/light)
Language
App-wide settings

Bad use cases

Highly dynamic data (typing, counters)
Large, frequently changing lists
Complex business logic

7. Sharing State AND Actions (Common Pattern)

Usually, you’ll share both:

Data
Functions to update the data

<UserContext.Provider value={{ user, setUser }}>
  <App />
</UserContext.Provider>

Then consume:

const { user, setUser } = useContext(UserContext);

This is how login/logout works.

8. Why Context Is NOT a State Manager

Important beginner truth:

Context does not manage state.
It only distributes state.

You still need:

useState
useReducer
or another store

Context is the delivery system, not the engine.

9. Common Beginner Mistakes

❌ Using Context for everything

This leads to:

Performance issues
Hard-to-track updates

❌ Putting too much logic in Context

Keep it simple:

Data
Small helpers

❌ Forgetting Provider

If there’s no Provider, useContext returns undefined.

10. `useContext` vs Props (Quick Comparison)

Props	useContext
Explicit	Implicit
Best for local data	Best for shared data
Easy to trace	Can be hidden
No setup	Needs Provider

11. A Simple Rule to Remember

If many components need the same data, and passing props feels annoying — use Context.

12. Where `useContext` Fits in Your Learning Path

You should learn useContext after:

useState
Passing props
Lifting state up

And before:

Redux
Zustand

Final Summary

useContext solves prop drilling
It lets components read shared data
It works best for global, stable data
It does not replace state management libraries

Once this clicks, React starts feeling clean and intentional, not messy.

Understanding `useEffect` in React: A Beginner-Friendly Guide

Sospeter Mong'are — Tue, 03 Feb 2026 11:46:25 +0000

If you’re new to React, one thing that often confuses beginners is when and why to use useEffect. Let’s break it down slowly, so it makes perfect sense even if you’ve never done frontend before.

1. What is `useEffect`?

useEffect is a React Hook that lets you perform side effects in a component.

Side effects are things your component does that are outside rendering the UI:

Fetching data from an API
Logging to the console
Setting timers (setTimeout)
Interacting with browser APIs (like localStorage)

In plain terms:

“useEffect is a way to tell React: do this action after the component appears on the page or when something changes.”

2. When do you actually need it?

Think of useEffect as React’s way of replacing old lifecycle methods from class components:

Old React class method	`useEffect` equivalent	Typical use
`componentDidMount`	`useEffect(() => { ... }, [])`	Run once on page load
`componentDidUpdate`	`useEffect(() => { ... }, [dependency])`	Run when a value changes
`componentWillUnmount`	`useEffect(() => { return () => {...} }, [])`	Clean up before component disappears

2.1 Backend Analogy

If React were a backend server:

useEffect(() => fetchData(), []) → “Call the database once when the request starts”
useEffect(() => fetchData(), [userId]) → “Call the database every time the userId changes”

This makes it very intuitive if you already understand API calls and triggers.

3. The Basic Syntax

useEffect(() => {
  // code you want to run
}, [dependencies]);

Breaking it down:

First argument: A function containing the code you want to run (your “effect”)
Second argument: An array of dependencies that tells React when to run the effect

3.1 Dependency Array `[]`

Empty array [] → Run once, after the component loads
Example:

useEffect(() => {
  console.log("Component loaded!");
}, []);

Think of it like onPageLoad.

3.2 Dependencies `[value]`

Add values inside the array → Run every time one of these values changes

const [count, setCount] = useState(0);

useEffect(() => {
  console.log(`Count changed to: ${count}`);
}, [count]);

Here, the effect only runs when count changes.
Backend analogy: “Re-fetch or re-run a query when this parameter changes.”

3.3 No Dependency Array

If you don’t provide a dependency array, the effect runs after every render:

useEffect(() => {
  console.log("Runs on every render!");
});

⚠️ Be careful — this can cause infinite loops if you update state inside the effect.

4. A Real Example: Fetching Groups on Page Load

This is exactly like your GroupList component:

useEffect(() => {
  fetch("http://localhost:3000/groups", {
    headers: {
      Authorization: "Bearer TOKEN"
    }
  })
    .then((res) => res.json())
    .then((data) => setGroups(data.groups));
}, []); // empty array → run only once

API is called once when component appears
groups state updates → React re-renders the UI automatically

5. Cleanup Function (Optional but Important)

Sometimes effects need cleanup, like:

Removing event listeners
Clearing timers
Canceling subscriptions

useEffect(() => {
  const timer = setInterval(() => console.log("Tick"), 1000);

  // cleanup function
  return () => clearInterval(timer);
}, []);

Think of it as undoing something before the component disappears, similar to closing a DB connection.

6. Common Beginner Mistakes

Mistake	Why It Happens	How to Fix
Forgetting `[]` when effect should run once	Effect runs on every render → infinite API calls	Add empty dependency array `[]`
Updating state without dependency	Infinite loop: state changes → render → effect → state	Include correct dependencies `[state]` or move code to a button click
Using `useEffect` for user actions	e.g., clicking a button should not run automatically	Keep `useEffect` for side effects, not triggers

7. Golden Rules

useEffect = side effects, not user actions
Empty array [] = run once
Dependencies [value] = run when value changes
Return a cleanup function if needed
Don’t use useEffect to replace normal function calls triggered by buttons

8. Quick Mental Model (Backend-Friendly)

Backend Concept	React `useEffect` Equivalent
API request on page load	`useEffect(() => fetchData(), [])`
API request on parameter change	`useEffect(() => fetchData(), [param])`
Closing DB connection	`return () => cleanup()`

9. Summary

useEffect is React’s way of doing things after rendering
Use it for:
- Fetching data
- Logging
- Timers or subscriptions
Don’t use it for:
- Button clicks
- User input triggers (use event handlers instead)

✅ Once you understand useEffect, React stops feeling magical — it becomes predictable, just like backend logic:

Load component → run effect
Dependencies change → re-run effect
Cleanup when leaving → prevent leaks