Can we update this to use the imperative mood? ("Creates" -> "Create")

Let's be explicit and say invalid_date here.

Let's be explicit and say last_updated here.

Same here.

Same here.

I know we should already have some validation from the field type, but can we explicitly do kwargs['valid'] != False?

Can you alphabetize all the keys? Helps keep it clear where new ones go.
Also, all these should have a 'added_in': '5.0'. Same with all places where we describe a new field.

This has to go before Args.
Under the hood, Version Added is a .. versionadded::, which is a paragraph-following/generating construct. Args, Returns, and Raises are special block-generating directives meant to appear after the paragraph-generating content is done.
Same below.

For the else clause, are we handling None/''? We should probably just be explicit with one or the other (probably None).
Same below.

If we're not modifying this, we should provide it inline where we're using it.

We should maybe create some central concept of what the default token generator is. Maybe this lives in Djblets, as a DJBLETS_DEFAULT_API_TOKEN_GENERATOR, and a function for getting it from the registry?
This can be a follow-up. Not a P0 for this change or related changes. Given time constraints, this can also just be tracked in Asana for now.

Let's simplify this a bit.

valid = kwargs.get('valid')

if valid is True:
    return INVALID_FORM_DATA, ....
elif value is False:
    ...

Let's avoid setting the key twice and instead compute as one statement.

Paren should be on the previous line, with no trailing , (given that it's a function call).

Let's make this part of the call, so we have that state all together.
Same below.

"expiration date" is more in line with the language we tend to use in the docs (I just found out, this is a regional difference).

This form for function definitions should only be used if we can't fit argument names and values on a single line. These will all fit, so let's start them off on the create_webapi_token line and then align each next one with that.

Rather than this form, let's pull this out and pre-compute the generator ID.
In fact, we should allow the caller to specify a generator ID and token info (default to None, set to these if not specified), so that we can more easily test with variations on the tokens.

As above, we standardize on "expiration date."

No blank line here.

Let's pull out the ID before we call this, to avoid the chaining.

Rather than True or False (here and in the resulting errors), we should use true or false, because these will be values going into the API rather than the Python constants for them.

Let's pull this out to avoid the chaining.

We try hard to avoid the ternary if .. else in statements. They're a bit harder to read and format.
Instead, can we pre-compute the expected values at the top of the function, and compare against those?

Ship It!