Email verification code: Incorrect code

[haavardnk]

I am trying to implement allauth headless. While doing so, I want to only use codes by mail, as I do not have a web frontend.
I have set the following:

HEADLESS_ONLY = True
ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_EMAIL_VERIFICATION = "mandatory"
ACCOUNT_EMAIL_VERIFICATION_BY_CODE_ENABLED = True
ACCOUNT_LOGIN_BY_CODE_ENABLED = True
ACCOUNT_AUTHENTICATION_METHOD = "email"

When signing up on _allauth/app/v1/auth/signup i get the 401 with verify_email pending, and I get the code on email.

When sending the code with POST to _allauth/app/v1/auth/email/verify with the json body:

{
    "key":"DNF9HM"
}

I get {status: 400, errors: [{message: Incorrect code., code: incorrect_code, param: key}]} no matter what.

Any idea why this is happening?

[pennersr]

I cannot confirm this, this works fine with the example project. You can easily switch it over to app as follows:

modified   examples/react-spa/frontend/src/lib/allauth.js
@@ -5,7 +5,7 @@ const Client = Object.freeze({
   BROWSER: 'browser'
 })
 
-const CLIENT = Client.BROWSER
+const CLIENT = Client.APP
 
 const BASE_URL = `/_allauth/${CLIENT}/v1`
 const ACCEPT_JSON = {

Then, using your settings everything just works.

[haavardnk]

Hmm, I don't really understand this. Nothing makes sense that it should return invalid at all times. Using normal email verification works fine. It also worked fine using the code when I was not using headless, and also when using dj-rest-auth, but is always invalid when I use the allauth headless API.
I am testing the API with Postman, and have also made a test in my Flutter app.

I just tested without ACCOUNT_EMAIL_VERIFICATION_BY_CODE_ENABLED = True

Sending to the exact same API the JSON payload with key from email:

{
    "key":"sgziqmblnqmxtodrg0u7phdzttysne35lcczxnplz3ydffmwlqpft2fn5nsj49kq"
}

And that works fine. It is just when verification by code is enabled.

[pennersr]

I suspect that the pending stage in the session is lost at the time you hand over the key. Are you handing over the session token? Can you double check the session endpoint to see if the token flow has is_pending: true ? Note that the link flow is not session dependent, which could explain why that is working regardless.