Skip to main content
An SS-4 is signed against a specific company name. When a replacement name is accepted after a rejection round, the signature your founder already gave no longer matches the company, so it is void. doola flips the company’s SS4 signature requirement back to PENDING and raises FORMATION_SIGNATURE_SS4_RESET. You are told by the signature_ss4_reset webhook. See Required actions for the payload, the status model, and how to read actions back.
This action is not resolved through the resolution endpoint. It closes by itself when the replacement signature completes. Posting a resolution for it returns 422 E_REQUIRED_ACTION_NOT_RESOLVABLE.

​
When it fires

It is narrow. All three have to be true:
  • the founder is non-US, so an SS-4 was required at all,
  • they had already signed it, and
  • a replacement name was then accepted.
A founder who had not signed yet gets no action and no event — their pending SS-4 simply carries the new name when they do sign. A US-founder company never has an SS-4 in the first place, so this never applies.

​
Resolving it

Exactly as you handled the first signature: create a signature session and present the link to your founder, as described in Non-US founders. Nothing about the signing flow changes — the link is short-lived and the founder signs the regenerated SS-4 carrying the new company name. That signature is the resolution: the action lands on resolved, and the EIN application continues.
The usual SS-4 reminder cadence resumes with the reset, so signature_ss4_reminder_due keeps arriving until the replacement is signed. Treat those as you already do — they are the same reminders, now for the new signature.

​
What to show your user

The reason on this action is short (SS4 must be signed again.), so the useful context is what preceded it: their company got a new name, and the form authorizing doola to obtain the EIN has to match it. Presenting the signing link with that framing avoids a founder wondering why they are signing the same document twice.