API Views

There are two views used in the registration workflow:


rest_registration.api.views.register(request, *args, **kwargs)


rest_registration.api.views.verify_registration(request, *args, **kwargs)

Assuming that the Django REST registration views are served at https://backend-host/api/v1/accounts/ then the register, verify_registration views are served as:

  • https://backend-host/api/v1/accounts/register/

  • https://backend-host/api/v1/accounts/verify-registration/


Verification workflow

Let’s describe it by example. We’re assuming that:

Then the verification workflow looks as follows:

  1. The user who wants to register itself sends AJAX POST request to https://backend-host/api/v1/accounts/register/ endpoint. Usually this happens via front-end aplication, which could be hosted on https://frontend-host/.

  2. Assuming the registration was correct, The register endpoint will generate an e-mail which will contain an URL which the newly registered user should click to activate his/her account. the URL would be in a form:

    https://frontend-host/verify-user/?user_id=<user id>&timestamp=<timestamp>&signature=<signature>

    (You can change the way the URL is generated by overriding ‘VERIFICATION_URL_BUILDER’)

  3. The frontend endpoint (which is not provided by Django REST Registration) https://frontend-host/verify-user/ would receive following GET parameters:

    • user_id

    • timestamp

    • signature

    and then it should perform AJAX request to https://backend-host/api/v1/accounts/verify-registration/ via HTTP POST with following JSON payload:

        "user_id": "<user id>",
        "timestamp": "<timestamp>",
        "signature": "<signature>"

    and then show a message to the user depending on the response from backend server.

Default serializers


class rest_registration.api.serializers.DefaultRegisterUserSerializer(*args, **kwargs)[source]

Default serializer used for user registration. It will use these:

to automagically generate the required serializer fields.


There are many cases where only a small bit of additional logic needs to be injected into the registration process, and writing a custom workflow to support this represents an unnecessary amount of work. A more lightweight customization option is provided through two custom signals which the built-in registration workflows send, and custom workflows are encouraged to send, at specific points during the registration process; functions listening for these signals can then add whatever logic is needed.

For general documentation on signals and the Django dispatcher, consult Django’s signals documentation. This documentation assumes that you are familiar with how signals work and the process of writing and connecting functions which will listen for signals.


Sent when a user account is activated (not applicable to all workflows). Provides the following arguments:


None - No class is sending this signal


A user-model instance representing the activated account.


The Request in which the account was activated.

This signal is automatically sent for you by the base register(), so unless you’ve overridden it you should not need to explicitly send it.


Sent when a new user account is registered. Provides the following arguments:


None - No class is sending this signal


A user-model instance representing the new account.


The Request in which the account was registered.

List of settings

These settings can be used to configure registration workflow. You should add them as keys (with values) to your settings.REST_REGISTRATION dict.


Default: True

If enabled, then users are able to register (create new account).

One can disable it if for instance accounts should not be registered by external users but rather should be created only by admin user.


Default: 'rest_registration.api.serializers.DefaultRegisterUserSerializer'

The serializer used by register endpoint. It is used to validate the input data and save (create) the newly registered user. You can use your custom serializer to customise validation logic and the way the user is created in the database.


Default: True

Used by DefaultRegisterUserSerializer. If True, the serializer requires additional field password_confirm which value should be the same as the value of password field.

It may be useful to disable it if you perform password confirmation at the frontend level.


Default: 'rest_registration.api.serializers.DefaultUserProfileSerializer'

The default serializer used by register endpoint. It is used output the data associated with the newly registered user. You can use your custom serializer to customise the output representation of the user.


Default: True

If enabled, then newly registered user will not be verified (user field specified by ‘USER_VERIFICATION_FLAG_FIELD’ will be false), and verification e-mail with activation link will be sent to the user email (specified by USER_EMAIL_FIELD).


Default: 'rest_registration.verification_notifications.send_register_verification_email_notification'

By default the email sender function will work with the build-in email sending mechanism.

You can handle email sending all by yourself by overriding this setting.


Default: datetime.timedelta(days=7)

Specifies how long the activation link will be valid.


Default: None

Frontend URL to which the query parameters will be appended to create the activation link for newly registered user.


Default: False

No description available, please add it here!



{'body': 'rest_registration/register/body.txt',
 'subject': 'rest_registration/register/subject.txt'}

Directory of templates used to generate the verification email. There are separate templates for email body and subject. If you want to generate html emails please refer to HTML e-mail configuration.


Default: False

Specifies whether a user will be logged in automatically when they verify their registration.