DEV Community: GREVE Malick

How I Handle OAuth2 Token Refresh and Quotas in a Django API Gateway

GREVE Malick — Mon, 24 Aug 2026 22:48:05 +0000

My first post about Asstgr covered the "what" — a self-hosted gateway that lets you register third-party APIs and call them through one unified interface. This time I want to zoom into the "how": specifically, two problems that are deceptively annoying to get right — OAuth2 token lifecycle management and per-user quota enforcement.

If you're building anything that proxies calls to multiple third-party APIs on behalf of your users, you'll hit both of these sooner or later.

Problem 1: OAuth2 tokens expire at the worst possible time

When you integrate a single OAuth2-protected API, refreshing a token by hand is annoying but manageable. When you're proxying an arbitrary number of APIs — each with its own grant type, scopes, and expiry — you need a system, not a snippet.

Asstgr models this with one OAuthConfig per API:

Field Purpose
grant_type client_credentials, authorization_code, or password
token_url Where to fetch/refresh tokens
client_id / client_secret_encrypted Credentials, secret stored encrypted at rest
scope Space-separated scopes
access_token / refresh_token Cached values
token_expires_at Expiry timestamp — null means the token never expires

The actual work happens in a dedicated OAuthService, kept separate from the views. Its job boils down to three responsibilities:

Fetch a token the first time an API is used, based on its grant_type.
Check expiry before every call — if token_expires_at is in the past (or close to it), refresh proactively instead of waiting for a 401 from the upstream API.
Persist the new access_token / refresh_token / token_expires_at back onto the OAuthConfig so the next call reuses it.

The detail that matters most here: refresh happens at the gateway level, once, and every caller benefits from it. Without a shared gateway, every single client integrating that API has to reimplement this same refresh logic — and inevitably some of them get it wrong (usually: reacting to a 401 instead of checking expiry ahead of time, which causes the first request after expiry to fail).

Encrypting client_secret at rest is non-negotiable once you're storing credentials for APIs you don't own. It's a small thing, but it's the difference between "gateway" and "liability."

Problem 2: quotas need to be atomic, not eventually-consistent

The second problem is subtler. A naive quota check looks like this:

python
if quota.call_count + api.quota_cost > quota.monthly_limit:
raise QuotaExceeded()
quota.call_count += api.quota_cost
quota.save()

This works fine until two requests from the same user hit the gateway at nearly the same time — which, with a burst limit of 30 requests/second, is not a rare edge case, it's Tuesday. Both requests read the same call_count, both pass the check, both increment, and you've let the user go over budget.

Asstgr's APICallQuota model tracks call_count, monthly_limit, and the current month/year, and the increment is wrapped so the check-and-increment happens atomically at the database level rather than in Python. Two practical rules came out of building this:

Never trust an in-memory read for a value you're about to write back. Use F() expressions or select_for_update() so the increment happens where the data lives, not in application code that can race.
Reset by period, not by cron job. Rather than a scheduled task that zeroes out counters on the 1st of the month (and inevitably fails silently once), the quota check itself looks up-or-creates the APICallQuota row for the current month/year. If it doesn't exist yet, it's created fresh. No cron, no midnight job that can fail, no stale counter.

HasSufficientQuota is a DRF permission class, checked before execute/ even reaches the view logic — which means a user who's out of credits gets a clean 403 before the gateway wastes a call to the upstream API on their behalf.

Where this leaves the request lifecycle

Putting the two together, a single call to /api/v1/apis/{id}/endpoints/{id}/execute/ goes through:

Authenticate the caller (API key)
Check burst + sustained rate limits (DRF throttling)
Check quota (HasSufficientQuota) — atomic check against APICallQuota
Resolve auth for the target API:
- static API key → attach directly
- OAuth2 → OAuthService checks expiry, refreshes if needed
Build the request from registered Endpoint/Parameter/Header/Method
Call the upstream API
Format the response (JSONCleaner: json/compact/standard/verbose)
Log the call (APILog) + increment quota
Return the formatted response + quota status to the caller

Nothing here is exotic — it's mostly about making sure steps 3 and 4 don't have races, and that a failure in step 6 doesn't leave the quota incremented for a call that never actually succeeded.

Takeaways if you're building something similar
Centralize token refresh. One place that owns "is this token still good" saves every downstream integration from reimplementing (and getting wrong) the same logic.
Treat quota checks as a database problem, not an application problem. Anything read-then-write under concurrency needs to happen atomically where the data lives.
Derive state from time, don't schedule it. A quota keyed by (user, month, year) that's lazily created is more robust than a monthly reset job.
Fail before you spend. Check quota and rate limits before making the upstream call, not after — so a rejected request costs you nothing.

Asstgr is open source (Django + DRF) if you want to see the full implementation: github.com/asstgr/asstgropensource. Happy to dig into any of these pieces further in the comments.

How to Handle OAuth 2.0 Authentication to Third-Party APIs with Asstgr (self-hosted)

GREVE Malick — Thu, 13 Aug 2026 13:53:32 +0000

If you've ever had to integrate an OAuth 2.0-protected third-party API into multiple projects, you know the drill: handle the authorization flow, store the tokens, track their expiration, build automatic refresh logic... and start over on every new project.

Asstgr is a self-hosted API gateway (Django + DRF) that centralizes all of this. The idea: you register a third-party API once in Asstgr, describe its endpoints, and then call it through a unified REST interface — Asstgr takes care of authentication, quota, and logging on your behalf.

In this article, we'll focus on one specific use case: how to connect an OAuth 2.0-protected API to Asstgr, and call it without ever handling a token by hand.

The concept
Your app ──► Asstgr (/api/v1/...execute/) ──► OAuth2-protected third-party API
│
├─ Auth (API Key or OAuth2)
├─ Quota
├─ Logs
└─ Response formatting

Your application only needs to know one thing: your Asstgr API key (sk-...). Asstgr internally handles all exchanges with the third-party API's OAuth server (fetching, caching, and refreshing tokens).

Supported flows

Asstgr supports the three most common OAuth 2.0 grants, with automatic token refresh:

client_credentials — for server-to-server integrations (the most common case)
authorization_code — for APIs requiring explicit user authorization
password — for legacy ROPC-based APIs

Step 1 — Register the API

We start like with any other API in Asstgr:

http
POST /api/v1/apis/
{
  "name": "My Protected API",
  "url": "https://api.example.com/v1",
  "auth_required": true,
  "quota_cost": 2
}

Step 2 — Configure OAuth 2.0

This is where it gets interesting. We attach an OAuth configuration to the API through the dedicated endpoint:

http
POST /api/v1/apis/{api_id}/oauth/
{
  "grant_type": "client_credentials",
  "token_url": "https://api.example.com/oauth/token",
  "client_id": "your_client_id",
  "client_secret": "your_client_secret",
  "scope": "read write"
}

The client_secret is stored encrypted server-side (client_secret_encrypted in the database). Once this configuration is saved, Asstgr knows how to obtain a token for this API.

Checking token status

You can check at any time whether a valid token is currently cached:

http
GET /api/v1/apis/{api_id}/oauth/token/

Forcing a refresh

If needed (debugging, secret rotation on the provider's side, etc.), you can manually force a token refresh:

http
POST /api/v1/apis/{api_id}/oauth/token/

Under normal circumstances this isn't necessary: Asstgr's internal service (OAuthService) checks token expiration (token_expires_at) before every call and refreshes it automatically if needed, completely transparently.

Step 3 — Describe the endpoint and its parameters

Just like with a regular API, we add the endpoint and its parameters:

http
POST /api/v1/apis/{api_id}/endpoints/
{
  "path": "/protected-resource",
  "description": "OAuth2-protected resource"
}
http
POST /api/v1/apis/{api_id}/endpoints/{endpoint_id}/parameters/
{
  "name": "resource_id",
  "param_type": "query",
  "data_type": "STRING",
  "required": true
}
http
POST /api/v1/apis/{api_id}/endpoints/{endpoint_id}/methods/
{ "method": "GET" }

Step 4 — Execute the call

And here's the main payoff: from your application, a single call, using your Asstgr key — no OAuth token to manage:

http
POST /api/v1/apis/{api_id}/endpoints/{endpoint_id}/execute/
Authorization: Api-Key sk-xxxxxxxxxxxxxxxxxxxxxxxx

{
  "method": "GET",
  "params": { "resource_id": "42" },
  "display_format": "standard"
}

Asstgr will, in order:

Verify your API key and remaining quota
Fetch (or refresh) the OAuth2 token associated with that third-party API
Build the actual HTTP request with that token in the Authorization header
Call the third-party API
Log the call (APILog: user, endpoint, method, status, response size)
Format and return the response

json
{
  "status_code": 200,
  "result": "...",
  "quota": {
    "used": 4,
    "remaining": 96,
    "limit": 100,
    "usage_pct": 4.0
  }
}

Why centralize this instead of handling OAuth in every service?
A single place to store secrets — your client_id / client_secret don't end up scattered across ten different microservices' codebases
Automatic, shared refresh — the token is cached and refreshed once, even if multiple services call the same API
Unified quota and logging — you know exactly who's calling what, and how much it costs in credits
Transparent provider changes — if the third-party API changes its token URL or scopes, there's only one place to update
Going further

Everything else (API keys, quotas, rate limiting, response formats) follows the same simple pattern: register declaratively once, then call it through /execute/.

The project is open source (Django 5.x + DRF, PostgreSQL):

👉 github.com/asstgr/asstgropensource

If you find the project useful, a ⭐ goes a long way, and you can follow updates on @asstgrio.

Building a Light API Integration Proxy in Django (Why & How)

GREVE Malick — Thu, 06 Aug 2026 13:06:55 +0000

Why another API tool?

As I built more complex applications, I noticed a pattern: every API has its own auth, rules, and formats. Setting up a full API Gateway like Kong felt like overkill for my needs.

I wanted a single tool to handle execution, authentication, and logging so my app only deals with business logic.

The Architecture (PoC Stage)

To validate the concept quickly, I built a synchronous MVP using:

Django & PostgreSQL: To easily model endpoints, params, and keys.
Requests / Urllib: To dynamic construct downstream calls.

⚠️ Note: I chose Django for rapid prototyping. I plan to migrate to Async (HTTPX / FastAPI or Go) once the execution logic is stable.

How it Works

Register the API: Define endpoints, base URLs, and OAuth/API Keys in the DB.
Execute via a single endpoint:

python

# Instead of handling OAuth + custom headers manually in your app:

import os
import requests
import json
from dotenv import load_dotenv

# Load variables from the .env file
load_dotenv()


# ==========================================
# CONFIGURATION
# ==========================================
# 1. Your Asstgr API Key (generated from your admin panel or the API)
API_KEY = os.getenv("ASSTGR_API_KEY")

# 2. The endpoint ID of '/user' linked to the GitHub API (ID: 36)
# (If you don't know it, run a GET request to http://localhost:8000/api/v1/apis/36/ to find it)
ENDPOINT_ID = "10"

# 3. The base URL of your local Asstgr instance
BASE_URL = "http://localhost:8000/api/v1"

# ==========================================
# REQUEST SETUP
# ==========================================
# Target URL for Asstgr's unified execution route
url = f"{BASE_URL}/apis/36/endpoints/{ENDPOINT_ID}/execute/"

# Required HTTP headers (Asstgr API Key Authentication)
headers = {
    "Authorization": f"Api-Key {API_KEY}",
    "Content-Type": "application/json"
}

# Request body payload
# Requesting 'json' format to retrieve the full raw GitHub user profile
payload = {
    "method": "GET",
    "params": {},
    "display_format": "standard"
}

# ==========================================
# EXECUTION
# ==========================================
try:
    print(f"Connecting to Asstgr: {url}...")
    response = requests.post(url, headers=headers, json=payload)

    # Check if the HTTP request to Asstgr was successful (status code 2xx)
    response.raise_for_status()

    data = response.json()

    print("\n--- Response Received Successfully ---")
    print(json.dumps(data, indent=2, ensure_ascii=False))

except requests.exceptions.HTTPError as http_err:
    print(f"\n[HTTP Error] Server returned status code: {response.status_code}")
    try:
        # Try to print the detailed error JSON payload from Django REST Framework
        print(json.dumps(response.json(), indent=2))
    except ValueError:
        print(response.text)
except Exception as err:
    print(f"\n[Error] An unexpected error occurred: {err}")

This project is in its early stages. Here is what I'm working on next:

[ ] Payload Encryption

[ ] Async Execution (HTTPX)

[ ] Caching with Redis

If you've built similar integration layers or have feedback on the approach, I'd love to hear your thoughts in the comments!

Check out the code on GitHub

Under the Hood: How My API Abstraction Layer Executes Requests (Django + DRF)

GREVE Malick — Mon, 03 Aug 2026 19:10:52 +0000

Before diving into the code, here is a quick overview of how the system works:

In my abstraction layer, API specifications are registered in the database. At runtime, the core logic queries these details while python services (powered by requests) handle the actual call construction and execution.

To keep things digestible, this post will focus strictly on two core components:

API Registration logic

Dynamic URL construction

(Note: I'll cover methods, endpoint parameters, headers, and authentication like OAuth 2.0 / API Keys in Part 2!)

The Core Data Model (API) To store the configuration for each registered API, I built a dedicated Django model. It acts as the single source of truth for base URLs, authentication requirements, access rights, and quota management.

Here is what it looks like:
`class API(models.Model):
name = models.CharField(max_length=255)
description = models.TextField(blank=True, null=True)
url = models.URLField(validators=[URLValidator()])
auth_required = models.BooleanField(default=True)
created_by = models.ForeignKey(User, on_delete=models.CASCADE, related_name='user_apis', null=True, blank=True)
api_key_encrypted = models.CharField(blank=True, null=True)
is_blocked = models.BooleanField(default=False)
is_active = models.BooleanField(default=True)

# 🆕 NEW FIELD: Quota cost per call
quota_cost = models.PositiveIntegerField(
    default=1,
    help_text="Number of credits consumed per call to this API"
)

def can_be_accessed_by(self, user):
    """Only creator or admin can access an API."""
    if not user or not user.is_authenticated:
        return False
    if user.is_superuser:
        return True
    return self.created_by == user

def __str__(self):
    return f"{self.name} (Coût: {self.quota_cost} crédit{'s' if self.quota_cost > 1 else ''})"`

URL Construction & Parameter Injection (build_url) The heart of the execution logic relies on a dynamic URL builder. It takes the base API URL, injects dynamic path parameters (e.g., /users/{user_id}), and encodes query string parameters cleanly using Python's urllib.parse.

`from urllib.parse import quote_plus, urlencode

def build_url(api_url: str, endpoint_path: str, parameters: list, user_params: dict) -> str:
# Clean up trailing/leading slashes to avoid double-slash issues (e.g., api.com//v1)
url = api_url.rstrip("/") + "/" + endpoint_path.lstrip("/")

# 1. Replace path parameters (e.g., {user_id} -> 42)
for param in parameters:
    if param.param_type == 'path':
        if param.name not in user_params:
            raise ValueError(f"Missing required path parameter: '{param.name}'")
        value = quote_plus(str(user_params[param.name]))
        url = url.replace(f"{{{param.name}}}", value)

# 2. Build and append query parameters
query_params = {
    param.name: user_params.get(param.name, param.default_value)
    for param in parameters
    if param.param_type == 'query' and user_params.get(param.name) is not None
}

if query_params:
    connector = '&' if '?' in url else '?'
    url += connector + urlencode(query_params)

return url`

The Execution Entry Point (ExecuteEndpointView) Once the URL logic is ready, the execution flow is triggered through a dedicated Django REST Framework view. Notice how access control and quota checks are enforced at the permission layer before any execution prep happens:

`from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status
from django.shortcuts import get_object_or_404

class ExecuteEndpointView(APIView):
"""
POST /api/v1/apis//endpoints//execute/
"""
authentication_classes = [APIKeyAuthentication]
permission_classes = [IsAPIKeyAuthenticated, HasSufficientQuota]

def post(self, request, api_id, endpoint_id):
    # 1. Fetch and validate access to the target API
    api = get_object_or_404(API, pk=api_id, is_active=True, is_blocked=False)
    if not api.can_be_accessed_by(request.user):
        return Response({"detail": "Forbidden."}, status=status.HTTP_403_FORBIDDEN)

    # 2. Build URL & execute request
    # (URL construction -> Headers injection -> HTTP Call via requests)`

Well, I think I've covered enough for today—I don't want to make this article too long!

Want to check out the full code? The open-source repository link is in my bio.

Want to follow the rest of the series? Feel free to hit the follow button so you don't miss Part 2!

Thanks to everyone for reading, and happy coding!