DEV Community: Moin Ul Haq

Which link actually brought the sale?

Moin Ul Haq — Thu, 05 Nov 2026 04:32:20 +0000

Most of us share links everywhere. Instagram bio. WhatsApp groups. Email. Ads. A poster with a QR code. Then a sale happens, and someone asks a simple question. Which link did it?

If you cannot answer that, you are guessing. And guessing is expensive.

I learned this the hard way while building Fewly. I am Moinul Haq, the founder, and I built it because I was tired of short links that only told me a click happened. A click is not a sale. A click is not even a sign that someone liked your product. It just means someone tapped.

Caption: The Fewly homepage, showing a clean starting point for creating short links.

Start with one question

Before you shorten anything, decide what you want to learn. Do you want to know which platform works best? Which ad creative works best? Which email subject line gets people to actually buy?

One link per answer. That is the whole trick.

If you use the same link on Instagram, WhatsApp, and email, your numbers will blend together. You will see 500 clicks and feel good. You will have no idea where those 500 people came from. Use a separate link for each place, even if they all go to the same page. It takes a few extra seconds, and it saves you weeks of guessing later.

Give every link a clear name

A back-half is the part after the slash. Use it well.

A link called /sale is fine. A link called /sale-instagram is better. A link called /sale-instagram-reel-nov is best, because six months later you will still know what it was.

Keep names short, readable, and honest. Do not use random letters if you can avoid it. Future you will thank present you.

Add UTM tags, but keep them simple

UTM tags are small labels you add to a link. They tell your analytics where a visit came from. Source, medium, and campaign are enough for most people.

For example, source can be instagram, medium can be bio, and campaign can be winter-sale. That is it. You do not need ten tags. You need three tags you will actually use the same way every time.

The common mistake is spelling the same thing five different ways. Instagram, insta, IG, and instagram-bio are four different campaigns in your reports, even though they are the same place. Pick one spelling and stick to it.

Clicks are only step one

Here is where most link tools stop, and where most confusion starts. You see clicks go up, but sales stay flat. What happened?

Maybe people clicked, but the page was slow. Maybe they clicked from the wrong country for your shipping. Maybe they clicked at midnight, when your shop was closed for live support. Clicks alone cannot tell you that.

You need to connect the click to what happened next. Did the person sign up? Did they add something to the cart? Did they pay? That is conversion tracking. In plain terms, it means your link tool and your checkout both agree on one thing: this sale came from this link.

When you have that, your decisions get easy. You stop spending on the link that gets clicks but no sales. You put more effort into the link that gets fewer clicks but more buyers. That is a very different list, and it is usually a surprise.

Caption: A blurred view of the Fewly analytics dashboard, showing clicks and sales without sharing private details.

Watch device, country, and time

Three details change everything, and they are easy to miss.

First, device. iPhone users and Android users do not always behave the same way. If you sell an app, sending both groups to the same web page is a waste. Send iPhone users to the App Store and Android users to Google Play. It is a small change, and it removes a whole step for the buyer.

Second, country. If you only ship to one country, clicks from other countries are not bad, they are just not buyers. Knowing that stops you from thinking a campaign failed when it was actually shown to the wrong audience.

Third, time of day. Some links work best in the morning, some at night. If you post at the wrong hour, you are not testing the link, you are testing the clock. A busy-hour view helps here, because it shows when people actually tap, not when you think they will.

QR codes count too

A QR code on a menu, a package, or a poster is also a link. Treat it the same way.

Use a dynamic QR code, which points at a short link, if you want to change the destination later or count scans. A static QR code is fine for something simple like a WiFi password, because the data is inside the code itself and it never expires. For marketing, dynamic is better, because you can fix a mistake without reprinting everything.

And please test the print size. A tiny QR code on a busy package is not a link, it is a decoration. People need to scan it from a normal distance, with normal light, on a normal phone.

Caption: The Fewly free tools page, with simple tools that support QR codes and short links.

A simple weekly check

You do not need a daily dashboard ritual. Once a week, answer these five questions.

Which link got the most clicks? Which link got the most sales? Which link got clicks but no sales? Which platform sent the best buyers, not just the most visitors? What will you stop doing next week?

That last question matters most. Most of us only add new links. We rarely stop the ones that do not work. Stopping is free, and it frees up time for the links that actually bring money.

Keep it honest

One more thing. Do not chase a big click number for its own sake. A link with 10,000 clicks and zero sales is not a win. A link with 100 clicks and 10 sales is a business.

Short links are not magic. They are just a way to see clearly. When you can see which link brought the sale, you can make a better next move. That is the whole point.

Caption: The Fewly API docs, showing how conversion tracking and routing work in plain steps.

I built Fewly to make that view simple, with real-time analytics, branded links, QR codes, and conversion tracking, starting free at fewly.tech. You can also read the docs at fewly.tech/docs to see how conversion tracking and routing work in plain steps. No matter which tool you use, though, the habit is the same: one link per place, clear names, simple tags, and sales, not just clicks, as the final score.

10 Browser-Based Tools That Replaced My Local Dev Utilities

Moin Ul Haq — Sun, 19 Jul 2026 18:17:58 +0000

I replaced my laptop in March and did the thing everyone threatens to do: no backup restore, fresh install, add software only when I genuinely miss it.

Four months later, an entire category never came back. The one-job utilities — JSON prettifier, diff GUI, hash tool, the little menu-bar timestamp thing — are browser tabs now. Not web apps that ship my data to a server. Client-side pages: they load once, run entirely in the tab, and keep working when the Wi-Fi drops.

That distinction is the whole point. Half of what I paste into these tools is production-adjacent — webhook payloads with customer emails, staging configs, API responses. So my filter is blunt: open DevTools, watch the Network tab while I paste, and close the tab forever if anything leaves. Everything below passes. Fair warning: the tool links here point at fewly, which is my own project. Every tool on this list has alternatives elsewhere; the client-side pattern is what I'm actually recommending.

1. JSON Formatter

Webhook debugging is where this earns its keep. Stripe hands you something like:

{"id":"evt_3PZk","type":"invoice.paid","data":{"object":{"amount_paid":4900,"customer":"cus_QRt8"}}}

Readable? Barely, and that's the short version. I paste it into fewly's JSON formatter, get proper indentation, and — the underrated part — validation for free, since the tool has to parse before it can pretty-print. Trailing comma in a hand-edited fixture file? It points at the line instead of letting me squint.

2. Text Diff

A feature worked on staging and 500'd in production. The entire diagnosis was two .env files pasted side by side: prod was missing REDIS_TLS=true and carried a stale API_BASE. Ninety seconds. No git, no vimdiff over SSH. Real code diffs still happen in the PR, obviously — this is for config-shaped text that never reaches version control: env files, nginx blocks, two versions of an email template. It also settles "did anything change on your side?" disputes with vendors, gently.

3. Hash Generator

Two habits. Checksums first: when a vendor publishes a SHA-256 next to their SDK download, I actually verify it now, because verifying costs ten seconds. Second, quick digests while sketching — hashing a canonical string to design a cache key or a dedupe ID. Yes, shasum -a 256 exists and I still use it in scripts. But when the string is already on my clipboard and a browser is already open, the tab wins on pure motion economics.

4. Timestamp Converter

1752868800 means nothing to me and never will. Logs speak epoch; incident reports speak "Friday around 9 p.m." A converter translates both directions and — the part I actually get wrong — handles timezones. When a user in Karachi reports something broke "last night," turning that into a UTC range I can grep is the real task, and doing offset math in my head at 1 a.m. has burned me more than once. The ISO 8601 output drops straight into API query params too, which ends the format guessing.

5. Cron Generator

I've written cron expressions for a decade and still don't fully trust myself with field order under pressure.

0 3 * * 1

Three a.m. every Monday. Or every March? Or the 1st of the month? (It's Monday. But you double-checked, didn't you.) A generator that renders the schedule back into plain English before it lands in a crontab has prevented at least two "why did this run 31 times" incidents that I know of.

6. Encoder / Decoder

OAuth debugging is nesting-doll decoding: a redirect_uri URL-encoded inside a query string, a base64 blob inside an Authorization header, occasionally both at once. Decode, read, fix, re-encode. If base64 still feels slightly mystical, MDN's glossary entry is the best ten-minute explanation I've found. After that, a paste box beats typing atob() into a console you don't have open.

7. YAML to JSON (and back)

GitHub Actions taught me that I cannot see YAML indentation errors after 6 p.m. A matrix build kept skipping one OS; the file looked fine. Converted to JSON, the bug was instant — my entry sat one level too high, a sibling of matrix instead of a child. YAML-to-JSON gives you the parser's-eye view, which is the view that matters. The reverse direction earns its spot whenever a machine-generated JSON config needs to become something humans can review without wincing. (The workflow syntax reference and I remain on speaking terms regardless.)

8. CSV Viewer

The 18 MB export problem: a spreadsheet app will open it, then immediately start improving it — dates reinterpreted for your locale, encodings guessed, columns reformatted. A read-only viewer does none of that. I skim, confirm the column names, spot-check that row 40,000 looks like row 4, close. Most of the time I never needed to edit the file. I needed to see it, and seeing shouldn't mutate.

9. Markdown and HTML, both directions

Release notes get written once, in Markdown. Then the email tool wants HTML, a CMS field wants Markdown back, and someone in marketing wants the announcement "as a web page." Round-tripping through a converter beats hand-repairing <li> soup in either direction. A recent favorite: a client sent brand copy as raw HTML scraped from their old site, and one paste turned it into Markdown I could commit to the project wiki. Small tool, weekly use, zero drama.

10. File Converter

The surprise entry. Product managers send specs as .docx; our docs live in the repo as Markdown. The file converter on the same hub does DOCX-to-Markdown in the tab — a 14-page spec becomes a reviewable pull request in about a minute, headings and lists intact. It goes the other way too, Markdown to PDF, for the people who want "a document" back.

Where the terminal still wins

None of this retires jq. Anything repeated, scheduled, or larger than ~50 MB belongs in a script, and jq's filter language is untouchable for surgical extraction mid-pipeline. The browser tools won a different niche: interactive, one-off, paste-shaped problems where startup cost dominates the actual work. Knowing which niche you're standing in is the skill.

The actual takeaway

My Homebrew list is a third of its former size and I haven't missed the utility folder once. The full set of tabs I use lives at fewly.tech/tools — 50-odd tools, free, client-side, no signup, and they work offline once loaded. But steal the pattern even if you skip the site: before trusting any "free online tool," open the Network tab and watch what leaves. If your data ships out for a task your laptop could do locally, find a better tab. My running total after four months: zero dollars, zero licenses, zero update prompts.

Suggested author bio: Moin is the founder of fewly, a free URL shortener with 50+ free browser-based tools. He builds the kind of small utilities he wishes came pre-installed.

How to Fix “Authentication Credentials Were Not Provided” Error in Django REST Framework JWT

Moin Ul Haq — Sun, 08 Mar 2026 20:02:56 +0000

Introduction

You’ve set up JWT authentication in your Django REST Framework API. Your token generation works perfectly. You’re sending the Authorization header with every request. But somehow, you keep getting this frustrating error:

{
  "detail": "Authentication credentials were not provided."
}

If you’ve been pulling your hair out over this issue, you’re not alone. This is one of the most common authentication problems Django backend developers face, and I’ve encountered it countless times while building production APIs at Elevabel and in my personal projects.

The good news? This error usually has straightforward solutions once you understand what’s actually happening behind the scenes.

Understanding the Problem

The “Authentication credentials were not provided” error occurs when Django REST Framework’s authentication system cannot find or validate the JWT token in your request. Despite what the error message suggests, this doesn’t always mean you forgot to send credentials—it often means the credentials aren’t being recognized properly.

Here are the most common causes:

- Incorrect Authorization header format
- Missing authentication classes in settings or views
- CORS issues blocking headers
- Middleware interference
- Token prefix mismatch

Let’s walk through each solution systematically.

Solution 1: Verify Your Authorization Header Format

The most common culprit is an incorrectly formatted Authorization header. Django REST Framework’s SimpleJWT expects a specific format.

Correct Format:

Authorization: Bearer

Common Mistakes:

Wrong: Authorization: JWT <token>
Wrong: Authorization: Token <token>
Wrong: Authorization: <token> (missing prefix)
Wrong: Authorization: Bearer<token> (missing space)

Testing with cURL:

curl -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc..." \ http://localhost:8000/api/protected-endpoint/

Testing with JavaScript (fetch):

fetch('http://localhost:8000/api/protected-endpoint/', {
  method: 'GET',
  headers: {
    'Authorization': `Bearer ${accessToken}`,
    'Content-Type': 'application/json',
  },
})

Testing with Python requests:

import requests

headers = {
    'Authorization': f'Bearer {access_token}',
}

response = requests.get(
    'http://localhost:8000/api/protected-endpoint/',
    headers=headers
)

Solution 2: Configure Authentication Classes Properly

Django REST Framework needs to know which authentication backend to use. You can configure this globally or per-view.

Global Configuration (settings.py):

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ),
    'DEFAULT_PERMISSION_CLASSES': (
        'rest_framework.permissions.IsAuthenticated',
    ),
}

Per-View Configuration:


from rest_framework import generics
from rest_framework.permissions import IsAuthenticated
from rest_framework_simplejwt.authentication import JWTAuthentication

class ProtectedView(generics.ListAPIView):
    authentication_classes = [JWTAuthentication]
    permission_classes = [IsAuthenticated]
    queryset = MyModel.objects.all()
    serializer_class = MySerializer

Important: If you set authentication_classes on a view, it overrides the global setting. Make sure JWT authentication is included.

Solution 3: Handle CORS Properly

When building a separate frontend (React, Vue, etc.), CORS can block your Authorization header from reaching Django.

Install django-cors-headers:

pip install django-cors-headers


Configure CORS (settings.py):

INSTALLED_APPS = [
    # ...
    'corsheaders',
    # ...
]

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',  # Must be at the top
    'django.middleware.common.CommonMiddleware',
    # ... other middleware
]

# Development settings
CORS_ALLOWED_ORIGINS = [
    "http://localhost:3000",
    "http://127.0.0.1:3000",
]

# Allow credentials (important for JWT)
CORS_ALLOW_CREDENTIALS = True

# Explicitly allow Authorization header
CORS_ALLOW_HEADERS = [
    'accept',
    'accept-encoding',
    'authorization',
    'content-type',
    'dnt',
    'origin',
    'user-agent',
    'x-csrftoken',
    'x-requested-with',
]

Production Note: Never use CORS_ALLOW_ALL_ORIGINS = True in production. Always specify exact origins.

Solution 4: Check for Middleware Conflicts

Custom middleware can sometimes interfere with authentication. If you have custom authentication middleware, ensure it’s not conflicting with DRF’s authentication.

Example of problematic middleware:

# DON'T DO THIS
class CustomAuthMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # This might strip the Authorization header
        if 'Authorization' in request.headers:
            # Custom processing that breaks JWT
            pass
        return self.get_response(request)

Solution:

Either remove conflicting middleware or exclude API endpoints:

class CustomAuthMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # Skip middleware for API endpoints
        if request.path.startswith('/api/'):
            return self.get_response(request)

        # Your custom logic for other endpoints
        return self.get_response(request)

Solution 5: Verify Token Prefix Settings

SimpleJWT uses “Bearer” as the default prefix, but this can be customized. Make sure your frontend and backend agree on the prefix.

Check your JWT settings (settings.py):

from datetime import timedelta

SIMPLE_JWT = {
    'ACCESS_TOKEN_LIFETIME': timedelta(minutes=60),
    'REFRESH_TOKEN_LIFETIME': timedelta(days=1),
    'AUTH_HEADER_TYPES': ('Bearer',),  # This must match your frontend
    'AUTH_HEADER_NAME': 'HTTP_AUTHORIZATION',
}

If you changed AUTH_HEADER_TYPES to something like ('JWT',), your Authorization header must use that prefix:

Authorization: JWT <token>

Best Practices for Production JWT Authentication

Based on my experience building scalable backend systems, here are some best practices:

1. Use Short-Lived Access Tokens

SIMPLE_JWT = {
    'ACCESS_TOKEN_LIFETIME': timedelta(minutes=15),  # Short-lived
    'REFRESH_TOKEN_LIFETIME': timedelta(days=7),     # Longer-lived
    'ROTATE_REFRESH_TOKENS': True,
    'BLACKLIST_AFTER_ROTATION': True,
}

2. Implement Token Blacklisting

INSTALLED_APPS = [
    # ...
    'rest_framework_simplejwt.token_blacklist',
]

Run migrations:

python manage.py migrate token_blacklist

3. Add Proper Error Handling

from rest_framework.views import exception_handler
from rest_framework.response import Response

def custom_exception_handler(exc, context):
    response = exception_handler(exc, context)

    if response is not None and response.status_code == 401:
        response.data = {
            'error': 'Authentication failed',
            'detail': 'Please provide valid credentials',
            'code': 'authentication_failed'
        }

    return response

# In settings.py
REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'myapp.utils.custom_exception_handler',
}


4. Log Authentication Failures

import logging

logger = logging.getLogger(__name__)

class ProtectedView(generics.ListAPIView):
    authentication_classes = [JWTAuthentication]
    permission_classes = [IsAuthenticated]

    def handle_exception(self, exc):
        if isinstance(exc, AuthenticationFailed):
            logger.warning(
                f"Authentication failed for {self.request.path} "
                f"from IP {self.request.META.get('REMOTE_ADDR')}"
            )
        return super().handle_exception(exc)

Real-World Insight

In my work at Elevabel, I’ve debugged this exact error dozens of times across different client projects. The most common issue? Frontend developers using Authorization: Token because they’re used to Django’s built-in token authentication.

One project had a particularly tricky case: the Authorization header was being stripped by an AWS Application Load Balancer security rule. Always test your authentication in the actual deployment environment, not just locally.

Another lesson learned: when building APIs consumed by mobile apps, implement detailed error responses. A generic “credentials not provided” message doesn’t help mobile developers debug whether the token is malformed, expired, or missing entirely.

Debugging Checklist

When you encounter this error, work through this checklist:

Verify Authorization header format: Bearer
Check that rest_framework_simplejwt is installed
Confirm JWTAuthentication is in DEFAULT_AUTHENTICATION_CLASSES
Test the token is valid (not expired)
Verify CORS is configured correctly
Check for middleware conflicts
Test with a simple cURL request to isolate frontend issues
Review Django logs for authentication errors
Confirm the endpoint requires authentication (has IsAuthenticated permission)

Conclusion

The “Authentication credentials were not provided” error in Django REST Framework JWT authentication is frustrating but solvable. In most cases, it comes down to header formatting, configuration issues, or CORS problems.

Start with the basics: verify your Authorization header format and ensure JWT authentication is properly configured. If those don’t work, systematically check CORS settings and middleware conflicts.

Remember, authentication is the foundation of API security. Taking time to implement it correctly—with proper error handling, logging, and token management—will save you countless debugging hours down the road.

About the Author

Moin Ul Haq is a backend web developer from Pakistan specializing in Django, REST APIs, and scalable backend architecture. As the Founder of Elevabel, a software and web development company, he builds production-ready web platforms and backend systems for clients globally. Moin shares his development insights and projects on GitHub at github.com/moin-ul-haq.

LinkedIn OAuth in Django Using Allauth and OpenID Connect: A Practical Guide

Moin Ul Haq — Thu, 05 Mar 2026 22:34:34 +0000

By Moin ul Haq – Software Engineer | Web Developer | Django Enthusiast

Integrating LinkedIn OAuth in Django can be tricky, especially when you want smooth authentication and proper user data handling. In this guide, I’ll walk you through using Django Allauth with OpenID Connect for LinkedIn login, tackling real-world issues I faced while building client-facing web apps.

Why LinkedIn OAuth?
LinkedIn login is perfect when you want:

Users to sign up quickly using their LinkedIn profiles.
Secure authentication without managing passwords.
Access to professional user data like email, name, and profile URL.

Most tutorials cover Google or Facebook, but LinkedIn’s OpenID Connect implementation often confuses developers. Let’s solve it step by step.

Step 1: Install Dependencies

Start with Django and Allauth:

pip install django
pip install django-allauth[openidconnect]

Make sure your Django project is set up with INSTALLED_APPS updated:

INSTALLED_APPS = [
    ...
    'django.contrib.sites',
    'allauth',
    'allauth.account',
    'allauth.socialaccount',
    'allauth.socialaccount.providers.openid_connect',
]
SITE_ID = 1

Step 2: Configure LinkedIn as OpenID Connect Provider

Go to LinkedIn Developer Portaland create a new app.
Add OAuth 2.0 redirect URLs, e.g., http://localhost:8000/accounts/openid/login/callback/
Note your Client ID and Client Secret.

Step 3: Add Provider in Django Admin

Django Allauth allows dynamic configuration:

Login to Django Admin → Social Applications → Add LinkedIn.
Select Site → example.com (or localhost for testing).
Enter Client ID and Secret Key.
Use OpenID Connect as Provider type.

Step 4: Update URLs

Add Allauth URLs to your urls.py:

from django.urls import path, include

urlpatterns = [
    path('accounts/', include('allauth.urls')),
    ...
]

Step 5: Frontend Integration

Add a simple login button in your template:

<a href="{% provider_login_url 'openid_connect' %}?process=login">
    Login with LinkedIn
</a>

⚠️ Tip: Always use {% provider_login_url %} instead of hardcoding URLs to avoid callback issues.

Step 6: Handling Common Problems

1. “Invalid redirect_uri”

Make sure the redirect URI in LinkedIn app matches exactly with the one Django Allauth uses.

2. User Email Not Returned

LinkedIn requires r_emailaddress permission. Ensure your Allauth provider scope includes:

SOCIALACCOUNT_PROVIDERS = {
    'openid_connect': {
        'SCOPE': ['openid', 'email', 'profile']
    }
}

3. Tokens Not Saved

Allauth stores tokens in SocialToken. Always check the SocialApp and SocialAccount entries in Django Admin.

Step 7: Verify Everything Works

Run server:
python manage.py runserver
Click Login with LinkedIn → authorize → redirected to dashboard.
Check request.user → should have LinkedIn email, name, and token.

Personal Branding Angle

While implementing this, I realized professional networking login flows not only save development time but also improve user trust. As a developer, mastering OAuth integrations with Django is a strong portfolio highlight, showing clients that you can handle enterprise-grade authentication.

💡 Pro Tip: Post your projects integrating OAuth on GitHub with proper README and a live demo. Recruiters and clients love this.

Conclusion

Using Django Allauth + OpenID Connect makes LinkedIn OAuth integration straightforward if you handle:

Provider scopes correctly.
Redirect URIs precisely.
Tokens and user data securely.

This setup not only improves user experience but also demonstrates your capability to solve complex authentication challenges professionally.

🔗 About Me

I’m Moin ul Haq, a software engineer building scalable Django applications. I write about real-world solutions, web development challenges, and software best practices. Check out my projects on GitHub.

Fixing “Got AttributeError: 'NoneType' object has no attribute …” in Django REST Framework

Moin Ul Haq — Wed, 04 Mar 2026 10:43:43 +0000

Hi! I’m Moin Ul Haq, a Software Engineer from Bahawalpur specializing in Django backend development.

If you’ve ever worked with Django REST Framework (DRF), you may have seen this frustrating error:
AttributeError: 'NoneType' object has no attribute 'id'

This usually happens when Serializer.save() or a nested serializer tries to access a field that doesn’t exist or is not properly passed.

In this tutorial, I’ll show you:

Why this error occurs
How to reproduce it
How to fix it cleanly in DRF

By the end, your serializers will handle missing data safely, and this error will become a thing of the past.

Step 1: Understanding the Error

This error typically occurs in DRF when:

A nested serializer expects a related object but receives None
A required field is missing in validated_data
You call .id or access attributes on a NoneType object

Example scenario:

from rest_framework import serializers
from .models import Task, Project

class TaskSerializer(serializers.ModelSerializer):
    class Meta:
        model = Task
        fields = ['id', 'title', 'project']

    def create(self, validated_data):
        project = validated_data.get('project')
        print(project.id)  # ❌ Error occurs here if project is None
        return Task.objects.create(**validated_data)

If a client POSTs without project, DRF will raise:
AttributeError: 'NoneType' object has no attribute 'id'

Step 2: Proper Validation in Serializer

The clean way to fix this is to validate the field before using it:

class TaskSerializer(serializers.ModelSerializer):
    class Meta:
        model = Task
        fields = ['id', 'title', 'project']

    def create(self, validated_data):
        project = validated_data.get('project')
        if project is None:
            raise serializers.ValidationError({
                'project': 'Project must be provided.'
            })
        return Task.objects.create(**validated_data)

✅ Now, if the client forgets project, they get a clear DRF validation error instead of AttributeError.

Step 3: Optional Nested Objects

Sometimes, the field may be optional. In that case, handle it like this:

class TaskSerializer(serializers.ModelSerializer):
    class Meta:
        model = Task
        fields = ['id', 'title', 'project']

    def create(self, validated_data):
        project = validated_data.get('project')
        task = Task.objects.create(
            title=validated_data.get('title'),
            project=project if project else None
        )
        return task

If project is missing, the serializer still works
No more “NoneType object has no attribute …” error

Step 4: Always Test Your API

Example POST request:
{ "title": "Finish DRF Tutorial" }

With validation: returns 400 Bad Request with message: "Project must be provided."
Without validation: crashes with AttributeError

✅ This ensures clean error handling and a better developer experience.

Conclusion

The “Got AttributeError: 'NoneType' object has no attribute …” error is one of the most common issues in Django REST Framework, especially for beginners dealing with nested serializers or required fields.

Key takeaways:

Always validate required fields before accessing attributes
Use serializers.ValidationError for meaningful messages
Optional fields should be handled with None checks

About the Author

I’m Moin Ul Haq, a Software Engineer from Bahawalpur specializing in Django & Python backend development. I share tutorials, tips, and real-world solutions to help developers build scalable web applications.

Follow me on Dev.to or check my GitHub: moin-ul-haq
for more backend projects.