JWT authentication in Django usually breaks in a very specific way: login succeeds, you copy the access token, and the very next request comes back with 401 Unauthorized. The response body is the whole diagnosis — if you read it before changing code, this is a ten-minute fix instead of an afternoon of guessing.

The short answer is this: a Simple JWT 401 almost always means one of four things. The access token has expired, the wrong token (a refresh token) was sent to an API endpoint, the Authorization header never reached Django, or the token was signed with a different secret than the server now uses. Below is how to tell which one you have, and the correct fix for each.

What the JWT authentication error actually says

Django REST Framework with Simple JWT returns a JSON body, not just a status code. Read the detail, code, and the per-message fields:

{
  "detail": "Given token not valid for any token type",
  "code": "token_not_valid",
  "messages": [
    {
      "token_class": "AccessToken",
      "token_type": "access",
      "message": "Token is invalid or expired"
    }
  ]
}

That one body already narrows the problem down:

• code token_not_valid, message Token is invalid or expired: the token failed validation — it is expired, malformed, blacklisted, or signed with a different key. Check the steps below in order.
• detail Authentication credentials were not provided: this is a different bug. No usable Authorization header reached the view at all, so Django never even saw a token. Skip to the header check below.
• detail Given token not valid for any token type, with a valid-looking token: you very often sent the refresh token where an access token belongs. The two token types are not interchangeable.
• Token is blacklisted: the refresh token was already rotated or logged out. The client must log in again — no server-side setting will resurrect that token.

JWT authentication settings that cause most 401 errors

Most production 401s are configuration, not code. This is a known-good baseline for Simple JWT 5.5.1, the current release on PyPI at the time of writing:

# settings.py
from datetime import timedelta

INSTALLED_APPS = [
    # ...
    "rest_framework",
    "rest_framework_simplejwt.token_blacklist",
]

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

SIMPLE_JWT = {
    "ACCESS_TOKEN_LIFETIME": timedelta(minutes=15),
    "REFRESH_TOKEN_LIFETIME": timedelta(days=7),
    "ROTATE_REFRESH_TOKENS": True,
    "BLACKLIST_AFTER_ROTATION": True,
    "AUTH_HEADER_TYPES": ("Bearer",),
}

Three settings in that block explain most surprises:

• Short default access lifetime: out of the box, Simple JWT access tokens live for five minutes and refresh tokens for one day. If your frontend never calls the refresh endpoint, every user appears to be logged out after five minutes. That is expiry working as designed, not a bug.
• Signing key follows SECRET_KEY: by default tokens are signed with your Django SECRET_KEY. Regenerate or change SECRET_KEY in production and every existing token instantly becomes invalid. Users must log in again, and no code fix changes that.
• The blacklist app must be installed: if you enable blacklist-after-rotation without adding the token_blacklist app and running migrations, rotation breaks. Install the app, migrate, then enable the setting.

Wire the endpoints once, in your root URL configuration:

# urls.py
from django.urls import path
from rest_framework_simplejwt.views import (
    TokenObtainPairView,
    TokenRefreshView,
    TokenVerifyView,
)

urlpatterns = [
    path("api/token/", TokenObtainPairView.as_view(), name="token_obtain_pair"),
    path("api/token/refresh/", TokenRefreshView.as_view(), name="token_refresh"),
    path("api/token/verify/", TokenVerifyView.as_view(), name="token_verify"),
]

Fix JWT token expired errors with a real refresh flow

Expired access tokens are normal. The bug is a client that treats expiry as a logout instead of refreshing once and retrying the original request:

async function apiFetch(url, options = {}) {
  const makeRequest = (access) => fetch(url, {
    ...options,
    headers: {
      ...(options.headers || {}),
      Authorization: `Bearer ${access}`,
    },
  });

  let response = await makeRequest(localStorage.getItem("access"));
  if (response.status !== 401) return response;

  const refreshResponse = await fetch("/api/token/refresh/", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ refresh: localStorage.getItem("refresh") }),
  });
  if (!refreshResponse.ok) return response; // refresh is dead: log the user out

  const data = await refreshResponse.json();
  localStorage.setItem("access", data.access);
  if (data.refresh) localStorage.setItem("refresh", data.refresh);
  return makeRequest(data.access);
}

Note the two details people miss. First, with rotation enabled the refresh response can contain a new refresh token — store it, or the next refresh will present a blacklisted token. Second, only retry on 401, and only once. Retrying in a loop turns a dead session into a request storm.

Still not sure whether the token itself is the problem? Inspect it server-side before blaming the frontend:

from rest_framework_simplejwt.tokens import AccessToken

token = AccessToken("paste-the-access-token-here")
print(token["token_type"])  # must be "access"
print(token["user_id"])
print(token["exp"])         # UTC epoch seconds: compare with your server clock

If constructing the token raises an error, the token is malformed or signed with another key. If it parses but the exp value is in the past, it is simply expired and the refresh flow above is the fix. Also check server time: a container or VM with a skewed clock will reject fresh tokens as not yet valid or already expired.

One related trap: a browser can drop the Authorization header before Django ever sees it. If your API and frontend are on different origins and preflight requests fail, treat it as a CORS problem first — see our guide to being blocked by the CORS policy. And do not confuse this with cookie-session failures: header-based JWT auth does not need a CSRF token, which is a separate mechanism covered in our post on Django CSRF verification failed. Verifying a credential before trusting it is the same discipline we apply to webhooks in our Stripe webhook verification guide.

The wrong fixes for invalid token errors

These appear in almost every forum thread, and each one trades a small bug for a bigger one:

• Stretching the access token lifetime to 30 days: the 401s stop, but a stolen access token now works for a month and cannot be revoked. Keep access tokens short and fix the refresh flow instead.
• Turning off expiry checks or adding a huge leeway: a large LEEWAY setting hides clock problems for a while and quietly accepts tokens that should be dead.
• Commenting out IsAuthenticated to make the error go away: the endpoint now works for everyone, including people with no token at all. You have removed the lock, not fixed the key.
• Regenerating SECRET_KEY every deploy: every deploy logs out every user and invalidates every token, because the signing key changed. Keep SECRET_KEY stable in your environment, and rotate it only as a deliberate, communicated event.
• Sending whichever token is at hand: access and refresh tokens have different token_type claims and different jobs. An endpoint that expects an access token will correctly reject a refresh token every time.

Final checklist for JWT authentication in Django

Work through these in order and the 401 will name itself:

• Read the response body first: token_not_valid, credentials not provided, and blacklisted tokens are three different bugs with three different fixes.
• Confirm the token type: decode the token and check that token_type is access for API calls.
• Check expiry and server time: compare the exp claim with a correct UTC clock on the server.
• Verify the header arrives: confirm the Authorization Bearer header reaches Django, through your proxy and CORS configuration.
• Keep SECRET_KEY stable: if it changed, old tokens are invalid by design and users must log in again.
• Implement refresh properly: refresh once on 401, store any rotated refresh token, retry the original request once, and log out cleanly if the refresh token is rejected.

Do that, and JWT authentication stops being a mystery error and becomes what it should be: a short-lived access token, a working refresh flow, and a 401 you can explain in one sentence.

Building a SaaS product is less a single build than a sequence of decisions. Doing them in the wrong order is what makes projects expensive, according to the original article.

The sequence, summarised

1. Validate the problem first. Talk to the people who would pay, and confirm the pain is frequent and costly enough to justify software.
2. Define the smallest useful version. Separate the core workflow that must work on day one from everything that can wait.
3. Design around the workflow, not features. Map the main user journey end to end before screens multiply.
4. Choose boring, proven foundations. Accounts, payments and data separation are not places to experiment.
5. Build in visible slices. Working software shown regularly beats a long silent build with a big reveal.
6. Prepare for launch as its own step. Billing checks, backups, monitoring and a support path need attention before users arrive.
7. Plan the post-launch loop. Early feedback, fixes and small improvements are part of development, not a separate phase.

Each stage reduces the risk of the next, and skipping early stages simply moves their cost later, with interest.

Read the full article on Djangix: SaaS Product Development: From Idea to Launch, Step by Step — with the complete step-by-step process.

Adding payments to a SaaS product looks simple until the first edge case: a card fails after access was granted, a customer is charged twice, or a cancellation never reaches your database. The original article treats billing as a state problem, not just a checkout form.

The core ideas, summarised

• Model billing in your own data first. Keep customer and subscription identifiers and current status on your side, so your product does not depend on a live call to decide who has access.
• Use a hosted checkout for the first version. It handles card collection and common payment methods far better than a custom form built quickly.
• Let verified server-side events drive access. Payment and subscription changes should update your records from notifications arriving at your server — not from what the browser reports after redirect.
• Handle the awkward lifecycle events. Failed renewals, cancellations, plan changes and refunds each need an explicit response in your access logic.
• Make retries safe. Repeating a create call after a timeout should not create a second charge — use idempotency and test that path.
• Test with simulated events before going live, including failure cases.

Most billing bugs are lifecycle bugs, not checkout bugs.

Read the full article on Djangix: Stripe API Integration for SaaS — with the full architecture, event list and mistakes checklist.

A Django page that feels instant with a handful of rows can crawl once the table grows. Often the cause is not the database itself, but how many separate trips the ORM makes to it.

The N+1 pattern, in plain terms

Fetch a list in one query, then follow a related object for each row — and each follow-up is another query. Ten rows hide the problem; a thousand rows turn it into a thousand extra trips.

Choosing the right tool

• For a single-valued relationship — such as the one author of an article — fetch the related row together with the main row in a joined query. One trip, and later access is free.
• For a collection — such as all the comments belonging to each item — fetch the related rows in a separate batched query and match them in Python. Joining collections into the main query can multiply rows and repeat parent data.

That direction — single-valued versus collection — is the core decision rule in the original article.

Habits that keep you honest

Count queries in tests and development rather than guessing, watch what templates and serializers actually access, and remember the limits: these helpers do not remove queries for later separate querysets.

The short version: measure the query count, match the helper to the shape of the relationship, and re-check after you change it.

Read the full article on Djangix: select_related vs prefetch_related: The Django N+1 Fix — with worked examples and the query count at each step.

You add a Content Security Policy, deploy, and the site looks fine but nothing responds. That is not the policy failing — it is the policy working. Your own inline code simply is not allowed yet.

What the policy is doing

CSP is a browser-enforced allowlist for scripts, styles, images and connections. Its main security value is against injected scripts, and injected code is usually inline — so a strict policy blocks inline code by default, including yours.

Five fixes, in the order to try them

1. Move inline code to external files. A script file served from your own origin is already allowed by a self-only script rule, and it also gains caching and linting.
2. Use a fresh nonce for code that must stay inline. Generate a random value for every response, put the same value in the policy and the tag, and never reuse it.
3. Hash a script that never changes. A fixed snippet can be allowed by its hash — but any edit, even formatting, changes the hash and blocks it again.
4. Replace inline handlers with listeners. Inline click handlers in markup are blocked, which is why pages can load while buttons do nothing. Move the behaviour into JavaScript and attach listeners there.
5. Name third parties explicitly. Analytics, chat and embeds each need their own origins listed in the relevant directives. Do not use a wildcard — that also allows an attacker's origin.

The shortcut to avoid

Allowing inline scripts generally makes the errors disappear by disabling the protection CSP exists to provide. If that is the fix, the policy is mostly decoration.

Safer rollout

Start in report-only mode: the browser enforces nothing but reports violations, so you can find and fix real usage before enforcing the same policy for users.

Read the full article on Djangix: Content Security Policy Blocking Your Scripts? — including the Django nonce middleware example and the full ranked fixes.

A non-streamed chat answer leaves the user staring at a spinner for the whole generation. Streaming changes the feel, not the total time: the first tokens arrive in under a second and the answer appears to type itself.

What is actually sent

The transport is Server-Sent Events — one HTTP response that stays open and delivers small messages. Each message carries a JSON chunk, and the useful text lives in a tiny delta field. Most chunks are fragments, not whole words, so the client simply concatenates them until a final done marker arrives.

Going through your own backend

Browsers should not call the provider directly, because that would expose your API key. So your server receives the chunks and re-emits them — and that middle step is where many implementations break.

• Wrap each token as JSON. Raw token text can contain newlines, which break the event framing. Encoding the token inside a JSON object avoids mangled multi-line answers.
• Read with fetch, not EventSource, for POST chats. The built-in event API cannot send a JSON body or an authorization header, so read the response stream manually and keep a buffer for events split across network chunks.
• Ask for usage explicitly. A stream option is needed if you want a final usage chunk for billing or budgeting.

Production pitfalls worth planning for

• Buffering proxies: Reverse proxies and CDNs may hold the response and deliver it all at once, silently defeating streaming. Disable buffering for that route and test through the real production path.
• Errors after the stream starts: Once the first chunk is sent, you cannot change the status code. Send an error as an event instead and render it in the UI.
• Disconnected users and saving: Stop consuming when the client goes away, and save the assembled answer once at the end rather than writing to the database per token.
• Idle timeouts: Periodic keepalive comments can keep a long generation from being cut off.

When not to stream

Short answers gain little, machine-consumed structured output usually needs to be complete before it can be parsed, and background jobs have no one watching. Streaming is a user-experience feature — use it where a person is waiting.

Read the full article on Djangix: Streaming OpenAI API Responses: How It Works, in Python, Django & FastAPI — with the complete Python, Django and FastAPI code.

US industrial safety data is public, but it has never been convenient: separate agency systems, separate search forms, and records that sit in isolation from each other. SafetyGraph, described in the full article, unifies them into one dataset holding more than half a million incident records.

The hard part is identity

The same employer appears under name variants, punctuation differences, and renames, so the pipeline normalises names and matches conservatively, erring toward separate records when a link is uncertain. Establishments, inspections, violations, and accidents are then related explicitly instead of being left as disconnected rows.

What one queryable dataset enables

With those links, a company's history across sources, or the chain from an inspection to its findings and outcome, becomes a single query rather than hours of manual cross-checking — the form safety teams, researchers, journalists, and data builders actually need.

Read the full article

This was a condensed summary. The complete story — sources, matching, data model, and example questions — is on the Djangix blog: Building SafetyGraph: 546,891 Industrial Incident Records in One Queryable Dataset

There is no single honest number for a SaaS MVP — there is a range, and scope moves it far more than coding speed does. The full guide breaks that range down by product type and by phase.

What you are really estimating

A narrow product with one core job, accounts, and payment can reach real customers in weeks. Add many user roles, layered permissions, several third-party integrations, or regulated data and you are planning in months, for reasons that have little to do with typing.

Where the time actually goes

Validation and definition, a foundation of accounts and core data, the main build, then billing, hardening, and launch. In practice the delays collect between phases — decisions, designs, credentials, content, and feedback — so fast, clear decisions shorten a project as surely as fast development.

Stretchers and shortcuts

Mid-build additions, vague requirements, bespoke design everywhere, and unchecked integration approvals stretch timelines. A single clear outcome, proven services for auth and payments, and cutting scope instead of quality to meet a chosen launch date keep them honest.

Read the full article

This was a condensed summary. The complete timeline, with phase ranges and an estimation checklist, is on the Djangix blog: How Long Does It Take to Build a SaaS MVP? An Honest Timeline

You do not need a cluster to deploy without downtime. The pattern in the full guide runs blue-green on a single EC2 host: two complete copies of the app, one live, one idle, with Nginx switching traffic between them.

Two colours, one server

Each colour gets its own directory, virtualenv, Gunicorn service, and port. The database, media, and environment stay shared, so switching colours changes code — not data.

Deploy to the idle colour

Update the inactive copy, run checks, start it, and probe its health endpoint on its own port. Only when it answers correctly do you update the Nginx upstream and reload, sending users to the new release.

Rollback and the traps

The old colour keeps running, so rollback is another proxy switch, not a rebuild. Guard the details the guide calls out: keep secrets out of the app folders, never let a deploy overwrite static files the live colour is serving, and treat database changes the old code cannot read as a separate, careful step.

Read the full article

This was a condensed summary. The complete walkthrough, with commands and configuration, is on the Djangix blog: Deploying Django on AWS with Zero Downtime

A CORS block is the browser enforcing a server's answer, so the fix almost never lives in the JavaScript that got blocked. The console message is a family of distinct complaints, and the clause after the headline tells you which one you have.

Missing or mismatched origin

If the response carries no matching Access-Control-Allow-Origin value, check the exact origin — scheme, host, and port all count — and remember that wildcard answers stop working once credentials are involved.

Failed preflight

Requests with custom headers or non-simple methods trigger an OPTIONS preflight first. If the server does not allow the method and headers you send, the real request is never made.

Headers, credentials, and look-alikes

Response headers stay hidden from JavaScript unless the server exposes them, credentialed calls need explicit permission, and some apparent CORS failures are really redirects, server errors, or mixed content wearing a CORS costume. In Django, the full guide configures the CORS middleware and its allowlists deliberately so each case is handled on the server side.

Read the full article

This was a condensed summary. The complete guide, message by message, is on the Djangix blog: Blocked by CORS Policy: Every Console Message and Its Real Fix

A 429 tells you a limit was hit, but not whether waiting will help. That depends on which limit it was, so start from the error code and the rate-limit headers rather than the status alone.

Retryable: temporary rate pressure

Short-lived requests-per-minute and tokens-per-minute limits clear on their own. For these, back off and retry — the SDK already retries a small number of times by default, and a custom policy should add exponential delay, random jitter, and an upper bound so retries do not arrive in a synchronised wave.

Not retryable: quota and spend limits

When the error points to exhausted quota, billing, or a project spend cap, retrying changes nothing. Stop calling, tell the user or operator plainly, and fix the underlying account issue first.

Lower your request rate for good

Cache repeated prompts, deduplicate identical calls, batch where the work allows it, cap max_tokens realistically, trim oversized context, and send simple jobs to a smaller model. For bursty background work, a queue that paces requests beats immediate retries from every worker.

Read the full article

This was a condensed summary. The complete guide, with the decision table and retry code, is on the Djangix blog: OpenAI API Rate Limit Errors (429): Which Ones to Retry and Which Ones to Stop

“CSRF verification failed” is Django protecting you — a POST arrived without a valid CSRF token. Work through the causes below in order; one of them is almost always responsible.

1. Missing csrf_token in the form

Every POST form rendered by Django needs the CSRF token tag inside it. Without it, the browser sends no token and the middleware rejects the request with a 403. This is the first thing to check, especially on hand-written templates and forms added by JavaScript.

2. CSRF_TRUSTED_ORIGINS behind proxies

In production behind a proxy or load balancer, Django may see a different scheme or host than the browser used. If the Origin does not match a trusted pattern, the check fails even with a correct token. Add your real production origin — including https:// — to CSRF_TRUSTED_ORIGINS.

3. Cookie settings

If the CSRF cookie never reaches the server, no token can validate. Check cookie domain and secure flags against how the site is actually served, and confirm the cookie is being set in the browser at all before blaming the form.

4. The AJAX header

JavaScript requests do not get the template tag automatically. Read the token from the cookie or the rendered page and send it in the X-CSRFToken header on every POST, PUT, and DELETE request.

Read the full article

This was a condensed summary. The complete troubleshooting guide is on the Djangix blog: Fixing 'CSRF Verification Failed' in Django

What Django's built-in Tasks framework gives you

Django now has a standard way to define and enqueue background tasks inside the project itself — no separate task library required just to get work off the request cycle. You define a task, enqueue it, and a backend runs it. For common jobs like sending email, generating thumbnails, cleaning up old data, or calling a slow third-party API, that simplicity is the point: fewer moving parts, less configuration, and an interface that feels like the rest of Django.

Where Celery still wins

Celery is the mature, battle-tested option, and it shows at scale. If you need advanced routing between queues, complex workflows made of chains and groups, fine-grained rate limiting and retries, periodic scheduling at volume, or a large ecosystem of brokers and monitoring tools, Celery gives you controls the built-in framework was never trying to provide. Teams already running Celery in production lose little by staying.

The decision rule

Start with Django Tasks when your background work is straightforward and moderate in volume, and you value doing more with what Django already ships. Choose Celery when the work itself is complex — multiple queues, chained workflows, heavy scheduling, or throughput that needs serious tuning — or when your team already knows it well.

In short: default to the simpler built-in option, and graduate to Celery when your requirements, not habit, demand it.

Read the full article

This was a condensed summary. The complete comparison is on the Djangix blog: Django Tasks vs Celery: Which Should You Use?

Why webhook signature verification matters

A Stripe webhook endpoint is just a public URL in your Django app. Anyone who finds that URL can POST to it — including someone sending a forged “payment succeeded” event to get an order marked as paid without ever paying. Signature verification is how you prove an event really came from Stripe before you act on it.

The raw-body requirement

Stripe calculates the signature over the exact bytes it sent. If you parse the JSON first and re-serialize it, the bytes change — key ordering and whitespace are not preserved — and verification fails even for genuine events. In Django, read request.body first and pass those raw bytes to Stripe; do not work from json.loads() output or request.POST for this check.

Verifying with the signing secret

Each webhook endpoint has its own signing secret (starting with whsec_). Take three things — the raw request body, the Stripe-Signature header, and that secret — and pass them to Stripe’s event construction/verification helper. If it raises an error, reject the request. Only process the event after verification succeeds.

Three common pitfalls

1. Parsed JSON instead of raw bytes — verifying against a decoded and re-encoded payload instead of request.body.
2. The wrong secret in production — test and live endpoints have different signing secrets, and a stale environment variable will fail every real event.
3. Not returning 200 fast — slow handlers trigger Stripe retries and duplicate deliveries. Verify, acknowledge with a 200 quickly, and move heavy work out of the request path.

Read the full article

This was a condensed summary. The complete walkthrough, with full code, is on the Djangix blog: Verifying Stripe Webhooks in Django, Step by Step