> ## Documentation Index
> Fetch the complete documentation index at: https://docs.doola.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Authenticate with the raw API key in the Authorization header. Never add a Bearer prefix.
> Use the sandbox base URL https://api.test.doola.com and a dk_test_ key in examples unless the user asks for production.
> Send an Idempotency-Key header on POST /v1/partner/customers and POST /v1/partner/companies. No other endpoint takes one.
> Every response is wrapped as {payload, error}. Read fields from payload and branch on error.code, never on the message.
> Drive formation progress from webhooks plus a reconciliation sweep, never a polling loop.
> Embedded SDK (@doola/js): the dk_ key stays on the server and mints customer sessions; the browser gets only a pk_ key and the session. onFormed carries only companyId and can fire more than once. Before charging, read the company with the dk_ key, require formationSubmissionStatus AWAITING_PAYMENT, check the owner's email, and price on the server. Then POST payment-confirmed, which answers 200 with an empty body, and replace the SDK element with a new doola.create() (never append a second one).
> The doola Formation MCP server at https://mcp.doola.com is for founders forming their own company with their own doola account. Partners integrate the Partner API or the Embedded SDK. The /mcp endpoint on this docs site only searches these docs.
> For a full capability summary with the rules above, read https://docs.doola.com/skill.md.

# SS-4 signature needed again

> Handle FORMATION_SIGNATURE_SS4_RESET by re-presenting the SS-4 after a name change voids an existing signature.

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](/api/domain-objects#signature-requirement) back to `PENDING` and raises `FORMATION_SIGNATURE_SS4_RESET`.

You are told by the `signature_ss4_reset` webhook. See [Required actions](/api/required-actions) for the payload, the status model, and how to read actions back.

<Info>
  This action is **not** resolved through the [resolution endpoint](/api/required-actions/name-options#submitting-new-names). It closes by itself when the replacement signature completes. Posting a resolution for it returns `422 E_REQUIRED_ACTION_NOT_RESOLVABLE`.
</Info>

## When it fires

It is narrow. All three have to be true:

* the company requires SS-4 because no person supplies an SSN in a valid format (an ITIN does not waive signing),
* they had **already signed** it, and
* a [replacement name](/api/required-actions/name-options) 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. This does not apply when the company is exempt from SS-4 signing.

## Resolving it

Exactly as you handled the first signature: create a signature session and present the link to your founder, as described in [SS-4 and Form 8821 signing](/api/non-us-formation#request-a-signing-session). 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.

<Note>
  The usual [SS-4 reminder cadence](/api/non-us-formation#reminders-are-yours-to-send) 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.
</Note>

## 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.