Skip to content

Home

Jump to bottom
Kyvex edited this page Aug 30, 2026 · 2 revisions

django-tenant-apikeys wiki

django-tenant-apikeys is a small, framework-agnostic package for issuing API keys to the tenants/organizations in a multi-tenant Django app — prefix + hashed secret, per-key scopes, expiration, and throttled last-used tracking, with first-class Django REST Framework support and a documented Django Ninja recipe. For install instructions and the full API reference, start with the README.

This wiki goes deeper on specific topics than the README does. Suggested reading order below; jump straight to whichever one you need otherwise.

Start here

  1. Django multi-tenant API key authentication — the core model: why multi-tenant API keys need more than TokenAuthentication, and how the prefix+hash, scopes, expiry, and last_used_at fields work together.
  2. django-tenant-apikeys vs djangorestframework-api-key: which one do you need — a factual comparison if you're deciding between the two.

Using it with Django REST Framework

  1. Scoping API keys per tenant in Django REST Framework — has_scope(), HasAPIKeyScope, and designing a scope taxonomy that ages well.
  2. Testing a custom DRF authentication backend with pytest-django — how the package's own test suite proves every rejection path, as a template for testing your own auth backend.

Using it without DRF

  1. Django Ninja API key auth without DRF — the framework-agnostic core wired into a Ninja APIKeyHeader, line by line.

Operating keys in production

  1. Rotating and expiring API keys in Django without breaking existing clients — the overlap pattern: issue new, grace-period the old one, verify the cutover with last_used_at.
  2. Throttled last_used_at tracking: avoiding a DB write on every authenticated request — how record_usage() avoids turning a hot endpoint into a write on every request.
  3. One-time secret reveal in Django admin: the pattern behind save_model — how the admin shows a new secret exactly once, and how to extend it safely for your own concrete model.

Architecture and security

  1. Multi-tenant Django patterns: shared-schema vs schema-per-tenant, and where API keys fit — where this package's shared-schema design fits, and what changes in a schema-per-tenant setup.
  2. A security checklist for storing API keys in Django — every security decision the package made, as a general checklist for storing API keys in Django whether you use this package or not.

Elsewhere

Clone this wiki locally