How I Safely Added New Fields to My Django API Without Breaking Existing Users (Inboxit Case Study)

Popoola Temilorun — Sun, 05 Apr 2026 17:36:25 +0000

While building Inboxit a plug-and-play tool that forwards website form submissions to email, Slack, or WhatsApp, I needed to add new fields and change serializers to support more features.

The API was already live in production with real users. Changing models and serializers risked breaking existing integrations.

Here’s exactly how I handled it using the Expand-Contract pattern and API versioning.

The Situation

I had to add new fields to the main model. At the same time, I wanted to improve the response structure.

If I just updated the existing serializer, all current integrations would break.

My Approach: API Versioning + Expand-Contract

I decided to introduce v2 while keeping v1 fully functional.

Step 1: Expand

Added the new fields to the Django model (kept the old fields intact).

Here’s what the model looked like after adding the new fields:

Step 2: Versioning in URLs

I set up URL versioning so both versions could coexist:

# urls.py
urlpatterns = [
    path('api/v1/', include('inboxit.api.v1.urls')),   # Old version (still active)
    path('api/v2/', include('inboxit.api.v2.urls')),   # New version
]

Old clients continue using /api/v1/ without any change.

Step 3: Migration & Contract Phase

Updated code to support both versions where needed.
Added logging to track which version clients were using.
Once most traffic moved to v2, I’ll fully deprecate v1 with proper notice.

Key Lessons

Never modify a live API in place if users depend on it.
Use versioning early (/api/v1/, /api/v2/) to give yourself room to evolve without affecting integrations.
The Expand-Contract pattern (add new → migrate → remove old) prevents painful rollbacks.
Always communicate deprecation timelines to users.

This approach let me add new features to Inboxit without disrupting existing integrations.

Have you had to version an API in production?

What strategy worked best for you — URL versioning, header-based, or something else?

I’d love to hear your experiences in the comments 😎😎.

🔐 Managing Multiple GitHub Accounts with SSH: Personal & Work Setup Guide

Popoola Temilorun — Fri, 06 Jun 2025 20:16:27 +0000

If you've ever struggled to juggle your personal and work GitHub accounts on the same machine, this guide is for you.

In this step-by-step tutorial, you'll learn how to:

✅ Generate SSH keys for different GitHub accounts
✅ Configure SSH with aliases for each identity
✅ Clone repositories using SSH without constant authentication issues

Let’s dive in 👇

1. Generate SSH Keys for Personal and Work GitHub Accounts

Start by creating two separate SSH keys—one for each GitHub account.

# Personal GitHub account
ssh-keygen -t ed25519 -C "your_personal_email@example.com" -f ~/.ssh/id_ed25519 

# Work GitHub account
ssh-keygen -t rsa -b 4096 -C "your_work_email@example.com" -f ~/.ssh/id_rsa_work

📝 Notes:

The -f flag specifies the filename.
Use meaningful filenames like id_ed25519 and id_rsa_work for clarity.

2. Add Your Public Keys to GitHub

Copy the contents of each public key and add them to their respective GitHub accounts:

# Display the public key
cat ~/.ssh/id_ed25519.pub      # Personal
cat ~/.ssh/id_rsa_work.pub     # Work

Then:

Go to your GitHub Settings > SSH and GPG keys
Click "New SSH Key"
Paste the key content and save

Repeat this process for both personal and work accounts.

3. Configure the SSH Config File for Multiple Identities

Create or update your ~/.ssh/config file to define aliases for each account:

# Personal GitHub
Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519

# Work GitHub
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_work

🛠️ You can edit this file using your favorite text editor:

code ~/.ssh/config    # VS Code
nano ~/.ssh/config    # Terminal editor

4. Test Your SSH Connections

Verify your setup with:

ssh -T git@github-personal
ssh -T git@github-work

✅ You should see:

Hi your-username! You've successfully authenticated, but GitHub does not provide shell access.

5. Clone Repositories Using SSH Aliases

Now you can clone repos with the correct identity by using the aliases:

# Personal repo
git clone git@github-personal:your_personal_username/repo.git

# Work repo
git clone git@github-work:your_work_org/repo.git

No more switching keys or editing global settings!

6. Set Local Git User Info for Work Repositories

To ensure your work commits use the correct email and name:

cd path/to/work-repo

git config user.name "Your Work Name"
git config user.email "your_work_email@example.com"

This updates the local .git/config file and overrides the global config.

🔍 Check your Git identity:

git config user.name
git config user.email

🎉 You're All Set!

With this setup, you can seamlessly manage multiple GitHub accounts on one machine using SSH. It's a clean and secure way to avoid authentication conflicts and commit with the correct identity every time.

📌 TL;DR

Use different SSH keys for personal and work accounts
Define aliases in ~/.ssh/config
Clone repos using the correct alias
Set local Git user info per project

💬 Got questions or a better SSH setup? Connect on LinkedIn

DEV Community: Popoola Temilorun