Skip to main content
The headless adapter allows you to customize various aspects of the headless authentication API, including user serialization, error messages, and frontend URL generation.

DefaultHeadlessAdapter

The DefaultHeadlessAdapter class provides default implementations for all adapter methods. You can override specific methods to customize behavior. Location: allauth.headless.adapter.DefaultHeadlessAdapter

Configuration

Specify your custom adapter in Django settings:

Creating a Custom Adapter

Extend DefaultHeadlessAdapter and override the methods you need:
Then configure it:

Adapter Methods

serialize_user

Serialize user data for API responses.
Parameters
User
Django user instance to serialize
Returns
dict
Dictionary containing user data
Default Implementation The default implementation converts the user to a dataclass and returns non-empty fields:
Customization Example
Note: If you need custom user payloads reflected in the OpenAPI specification, use get_user_dataclass() and user_as_dataclass() instead.

get_user_dataclass

Return a dataclass representing the user schema.
Returns
type
A Python dataclass type
Default Implementation The default implementation creates a dataclass with fields based on the user model:
  • id: User primary key (int, str, or UUID)
  • display: Display name (str)
  • email: Primary email address (Optional[str])
  • username: Username (str, if USER_MODEL_USERNAME_FIELD is set)
  • has_usable_password: Whether password is set (bool)
Customization Example

user_as_dataclass

Convert a user instance to the dataclass returned by get_user_dataclass().
Parameters
User
Django user instance
Returns
dataclass
Instance of the dataclass from get_user_dataclass()
Customization Example

get_frontend_url

Return the frontend URL for a given URL name.
Parameters
string
URL name (e.g., account_email_verification_sent, account_reset_password)
dict
URL parameters (e.g., key for verification links)
Returns
string
Frontend URL
Default Implementation Looks up URLs in HEADLESS_FRONTEND_URLS setting:
Customization Example
Use Case These URLs are used in email templates when the frontend is separate from the backend (e.g., SPA, mobile app).

error_messages

Dictionary of error messages.
Customization Example

Accessing the Adapter

You can access the configured adapter instance using get_adapter():

Common Customization Patterns

Adding Profile Data

Include related profile data in user serialization:

Including Permissions

Add user permissions to the serialized data:

Multi-tenant Support

Add tenant information:

Custom Display Name

Customize how display names are generated:

Localized Error Messages

Provide translated error messages:

Dynamic Frontend URLs

Generate frontend URLs based on request context:

Integration with OpenAPI Specification

When you customize get_user_dataclass(), the OpenAPI specification is automatically updated to reflect your custom schema. Example: After defining a custom dataclass with additional fields:
The OpenAPI spec will show:

Testing Custom Adapters

Test your custom adapter methods:

Best Practices

  1. Keep it simple: Only override methods you need to customize
  2. Call super(): Use super() to preserve default behavior when extending methods
  3. Avoid queries: Don’t make database queries in serialize_user() if possible; use select_related() or prefetch_related() before calling
  4. Use dataclasses: For OpenAPI integration, use get_user_dataclass() instead of overriding serialize_user()
  5. Test thoroughly: Write tests for all custom adapter methods
  6. Document changes: Document any custom behavior for your team
  7. Consider performance: Be mindful of performance when adding fields that require additional queries
string
default:"allauth.headless.adapter.DefaultHeadlessAdapter"
Path to custom adapter class
dict
default:"{}"
Mapping of URL names to frontend URL patterns
Example Configuration