FORMATION_NAME_OPTIONS_EXHAUSTED is raised when the state rejects every company name you submitted. The formation stops there until you send replacements, and the reason on the action usually names the exact names that were turned down, so you can put them in front of your user.
You are told by the company_name_options_required webhook. See Required actions for the payload, the status model, and how to read actions back.
The flow
Refiling and the accept-or-reject outcome are handled by doola’s operations team, so expect an action to sit insubmitted for as long as the state takes.
Submitting new names
One endpoint resolves every resolvable action, andactionCode says which one you are answering — it must match the action’s own actionCode, or the request is rejected.
status: "submitted", with its full history — you do not need a follow-up read.
The names replace the company’s existing options immediately, and the first-preference option also becomes the company’s name and entityTypeEnding. A company you read back afterwards reflects what you just sent, so refresh anything you cached.
This endpoint takes no
Idempotency-Key. Two identical submissions apply the names twice and append two submitted steps, so send it once and treat a network timeout as “read the action back” rather than “retry blindly”.Name option rules
The same rules as creating a company, because these names go to the state the same way.1
One to three names, in preference order
position sets the order and 1 is the first choice; omit it and doola uses the order you sent. The first preference becomes the company’s name if the state accepts it.2
Send a recognised ending
entityTypeEnding must be one of the endings listed under Name option. This check is case-sensitive, so send LLC, not llc.3
The ending must match the company's entity type
An LLC takes an LLC ending and a CCorp takes a corporate ending. An ending that is recognised but belongs to the other entity type is rejected rather than filed.
400 E_VALIDATION_FAILED, with the detail under error.fields.nameOptions — except an ending that is recognised but belongs to the wrong entity type, which is 400 E_NAME_OPTIONS_INVALID. The full error table lists the rest.
If the state rejects again
The action closes asrejected and doola raises a new action with the same code and a fresh requiredActionId, which arrives as another company_name_options_required webhook. Nothing reopens, so resolve against the new id — this is why your records should be keyed on requiredActionId rather than on the company.
After it resolves
Once a name is accepted the action closes asresolved and the formation continues from where it stopped.
One thing follows on: if your founder had already signed an SS-4 against the old name, that signature is now void, and doola raises an SS-4 signature needed again action for the replacement. Expect it as a second, separate webhook.