# django-rest-registration hands a Django project a sign-up, sign-in and password reset API

> django-rest-registration is a Django REST Framework package that supplies registration with email verification, session or token login, profile retrieval and update, password reset and change, and email change, without a model of its own. It suits teams that want a conventional account system on a JSON API, and it deliberately hands the verification front end back to the caller, which is both its strength and its work.

**apragacz/django-rest-registration** — User-related REST API based on the awesome Django REST Framework

- Repository: https://github.com/apragacz/django-rest-registration
- Website: https://django-rest-registration.readthedocs.io/
- Stars: 548 · Forks: 87
- Language: Python
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/apragacz-django-rest-registration

## The library is modeless, and that is its main design decision

The package calls itself modeless, and the mechanism behind that word is worth understanding before anything else. It uses the user defined by settings.AUTH_USER_MODEL, and it uses cryptographic signing instead of profile models, so it adds no tables of its own and no migrations to run. That is a genuine advantage over packages that ship their own registration model, because your project keeps one source of truth for users and swapping the user model later does not mean fighting a third party schema. The other consequence is that the library cannot keep state that has no home in your user model, and the e-mail change flow is the clearest example. The scope of the supported views is registration with verification, login and logout with session or token based authentication, user profile retrieval and update, reset password, change password, and register or change e-mail.

## The supported views, one by one

The feature list is short enough to read as a specification. Registration, described as sign-up, comes with verification. Login and logout, described as sign-in, work either session based or token based. The user profile view covers retrieving and updating. Then there is reset password, change password, and register e-mail, which the topic list renders as change email. The distinction between reset and change password is the usual one, reset being the forgot password flow that sends a link, change being the authenticated flow for a user who knows their current password. The views are also compatible with django-rest-swagger, which matters if you intend to publish an OpenAPI description of your API, and the project reports coverage above 98 percent, so the behaviour is pinned down by tests rather than by prose.

## Installing is one pip command and two settings blocks

The install path is a pip install of the package by name.

```bash
pip install django-rest-registration
```

Then you add the app to INSTALLED_APPS so that the templates for notification emails can be reached.

```python
INSTALLED_APPS=(
    ...

    'rest_registration',
)
```

After that the URLs are wired into your urlconf, with the library's own urls included under a prefix you choose.

```python
api_urlpatterns = [
    ...

    path('accounts/', include('rest_registration.api.urls')),
]


urlpatterns = [
    ...

    path('api/v1/', include(api_urlpatterns)),
]
```

The configuration itself lives in a single setting named REST_REGISTRATION, structured in the same way as Django REST Framework's own settings. The minimal version that satisfies the system checks turns the three verification switches off.

```python
REST_REGISTRATION = {
    'REGISTER_VERIFICATION_ENABLED': False,
    'RESET_PASSWORD_VERIFICATION_ENABLED': False,
    'REGISTER_EMAIL_VERIFICATION_ENABLED': False,
}
```

The preferred configuration instead names the frontend URLs that receive the verification links, and sets the address the mail comes from.

```python
REST_REGISTRATION = {
    'REGISTER_VERIFICATION_URL': 'https://frontend-host/verify-user/',
    'RESET_PASSWORD_VERIFICATION_URL': 'https://frontend-host/reset-password/',
    'REGISTER_EMAIL_VERIFICATION_URL': 'https://frontend-host/verify-email/',

    'VERIFICATION_FROM_EMAIL': 'no-reply@example.com',
}
```

## The frontend URLs are your job, and that is the main integration cost

The library hands back the part that sounds small and is not. The frontend urls are not provided by the library but should be provided by the user of the library, because Django REST Registration is frontend-agnostic. Those urls receive parameters as GET query values and should pass them to the corresponding REST API views via an HTTP POST request. So the flow is a two step dance across two systems. The API sends an email containing a link to your frontend, your frontend reads the token out of the query string, and your frontend posts that token back to the API to complete the verification. The library does not render a page, and it does not decide what the user sees next. For a project with a single page frontend in JavaScript that is an afternoon of work, and for a project with several client applications it is a contract you have to keep, since the three URLs are configuration and every one of them has to exist and behave.

## Verification is on by default, so email has to work before you ship

There is a detail in the documentation that changes the order of your work. In case when any verification is enabled, which the documentation notes is the default, your Django application needs to be properly configured so it can send e-mails. That is the difference between the minimal settings block and the preferred one, and the minimal block is described as the sample that satisfies the system checks, which is a low bar rather than a recommendation for production. Django's own email documentation is the reference the project points at, and the practical consequence is that a deployment with an unconfigured or deliberately suppressed email backend will accept registrations and then silently fail to verify them, with the user waiting for a message that never arrives. If your project is in a staging environment with email disabled, turn the switches off deliberately rather than assuming the defaults are safe.

## One email per user and no JWT, and the project says so

The limitations section is short and specific, and both items are the kind of thing that determines whether you can use the package at all. It supports only one email per user, as a model field, so a project with multiple addresses per account, or a separate email table, is out of scope. And there is no JWT support, but the documentation points at two ways to get it, a cookbook entry in the documentation and the option of using Django REST Registration alongside a library such as django-rest-framework-simplejwt. That second suggestion is the honest description of how JWT users should work, since the library's own auth story is session based or token based in the Django REST Framework sense, and the session based path is what the package does best. A team that has standardised on JWT everywhere is looking at a two package setup rather than one.

## The repository is a conventional Python project with locked dependencies

The packaging tells you the support posture. The project requires Python 3.9 or higher with no Python 2 support, and the package metadata marks the development status as 4 - Beta, with Django 2.0, 3.0 and 4.0 classifiers. The runtime dependencies are minimal, Django 3.0 or newer and djangorestframework 3.3 or newer, and the version is read out of the package at build time from rest_registration._version. The Makefile in the repository shows a development workflow built around lock files, with separate install-dev, install-ci and install-test targets that each install a pinned requirements lock file and the package itself in editable mode, and the all target runs check, test, build and check-package in sequence. The tooling is flake8, mypy, pylint, pytest, pip-compile and sphinx-build, and there is a separate requirements directory holding the lock files, which is a sign of a project that takes dependency reproducibility seriously. The docs directory and a readthedocs configuration publish the full documentation, and an examples directory holds a sharedlinks example.

## Where django-rest-registration is the wrong choice

The first wrong case is a project that needs more than one email address per user, since the library models exactly one, and adding a second address means writing your own model and your own view rather than configuring this one. The second is a project that has standardised on JWT across its whole API, where the library offers no token format of its own and the documentation's answer is to bolt on a second package. The third is a team that wants the library to own the verification user interface, because it deliberately does not, and the work of building three frontend endpoints, keeping them in step with the API contract and testing them, is a real cost that the readme does not hide. The fourth is a project that already has an account system, since the value here is in the views rather than the model, and a service with a working token flow gets little from a second parallel flow. The fifth is a team that needs to know the library is maintained against current Django, because the newest tagged release is v0.9.0 from 2024-08-31 while the last push was on 2026-07-15, so the gap between a release and the working tree is where the compatibility risk sits.

## Conclusion

Django teams exposing a JSON API that need sign-up, sign-in, password reset and email change without writing those views themselves, and who are comfortable owning a frontend for the verification step, are the people this package is for. It is the wrong choice for a project that already has its own user model with multiple emails or needs JWT, since the package supports only one email per user and states plainly that there is no JWT support, pointing instead to a cookbook entry and to django-rest-framework-simplejwt. Check three things before you adopt it: that the Django and Django REST Framework versions in your project fall inside the supported range, since the requirements ask for Django 3.0, 4.0 or 5.0 and DRF 3.3 or newer on Python 3.9 or higher, that your email backend is configured, because verification is on by default and the application must be able to send mail, and that you are prepared to build the three frontend URLs the library expects. The licence is MIT, the last push was on 2026-07-15, and the newest tagged release is v0.9.0 from 2024-08-31.

## FAQ

### How do I install django-rest-registration?

Run pip install django-rest-registration, add rest_registration to INSTALLED_APPS so the notification email templates can be found, then include rest_registration.api.urls in your urlconf under a prefix of your choosing. The package requires Django 3.0, 4.0 or 5.0 with Django REST Framework 3.3 or newer, on Python 3.9 or higher.

### Does django-rest-registration ship its own user model?

No. It is modeless, using the user defined by settings.AUTH_USER_MODEL and cryptographic signing instead of profile models, so it adds no tables and no migrations of its own.

### How does verification work in django-rest-registration?

The frontend urls are not provided by the library and should be provided by the user of the library, because the library is frontend-agnostic. Those urls receive parameters as GET query values and should pass them to the corresponding REST API views via an HTTP POST request, and the settings name the three of them, REGISTER_VERIFICATION_URL, RESET_PASSWORD_VERIFICATION_URL and REGISTER_EMAIL_VERIFICATION_URL.

### Does django-rest-registration support JWT?

No. The documentation states there is no JWT support, and points at a cookbook entry for implementing one, or at using Django REST Registration alongside a library such as django-rest-framework-simplejwt. The library's own authentication is session based or token based.

### What are the current limitations of django-rest-registration?

It supports only one email per user, as a model field, and it has no JWT support. The views cover registration with verification, login and logout, user profile retrieval and update, reset password, change password, and register or change e-mail.

## Sources

- [apragacz/django-rest-registration on GitHub](https://github.com/apragacz/django-rest-registration)
- [License: MIT](https://github.com/apragacz/django-rest-registration/blob/master/LICENSE)
- [Project website](https://django-rest-registration.readthedocs.io/)
- [README](https://github.com/apragacz/django-rest-registration/blob/master/README.md)
- [Releases](https://github.com/apragacz/django-rest-registration/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apragacz-django-rest-registration