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

# Founder address needed

> Handle FORMATION_FOUNDER_ADDRESS_REQUIRED by sending the founder's own US address for an Indiana or Illinois formation.

Indiana and Illinois reject a formation whose business or mailing address is the registered agent's address. When you create a company in either state with `provider: registeredAgent` on either address entry, doola still accepts the request (`201`), raises `FORMATION_FOUNDER_ADDRESS_REQUIRED` on the company and holds the formation until you send the founder's own address.

> [!NOTE]
>
> This is a transition period. A future release will reject such a request with `400 E_VALIDATION_FAILED` and `error.fields.addresses.code: E_ADDRESSES_INVALID`, so send the founder's address when you create the company.

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

> [!TIP]
>
> Avoid the action entirely: for a company in `IN` or `IL`, send both address entries with `provider: customer` and the founder's address when you [create the company](/api/formation#addresses).

## The flow

```mermaid theme={null}
sequenceDiagram
    participant P as Your backend
    participant D as doola API

    P->>D: Create company (IN or IL, registeredAgent address)
    D-->>P: 201, formationSubmissionStatus PENDING
    D-->>P: webhook company_founder_address_required
    Note over D: Formation held at PENDING
    P->>D: Submit resolution with the founder's address
    D-->>P: Action resolved
    D->>D: Formation continues
    D-->>P: webhook company_formation_submitted
```

While the action is open the company stays at `formationSubmissionStatus: PENDING`: nothing is filed and `company_formation_submitted` is not sent. Signing an SS-4 or Form 8821 is not blocked, and a signature made before you send the address stays valid.

## Sending the founder's address

Use the [resolution endpoint](/api/required-actions/name-options#submitting-new-names) with `actionCode: FORMATION_FOUNDER_ADDRESS_REQUIRED` and an `addresses` array: exactly one `business` and one `mailing` entry, both with `provider: customer` and `"country": "USA"` (exactly that value). The address does not have to be in Indiana or Illinois.

```bash theme={null}
curl https://api.test.doola.com/v1/partner/companies/{companyId}/required-actions/{requiredActionId}/resolution \
  -X POST \
  -H "Authorization: dk_test_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "actionCode": "FORMATION_FOUNDER_ADDRESS_REQUIRED",
    "addresses": [
      { "provider": "customer", "type": "business", "address": { "line1": "251 W 30th St", "city": "New York", "state": "NY", "postalCode": "10001", "country": "USA" } },
      { "provider": "customer", "type": "mailing",  "address": { "line1": "251 W 30th St", "city": "New York", "state": "NY", "postalCode": "10001", "country": "USA" } }
    ]
  }'
```

The response is the action, already `resolved`, with its full `history`. The endpoint takes no `Idempotency-Key`: a second call after the action closed returns `409 E_REQUIRED_ACTION_CLOSED`, so after a timeout read the action back instead of retrying. Unlike name options there is no state step to wait for: the addresses replace the company's business and mailing addresses at once, and the formation continues from where it was held.

## Errors

A body that breaks the rules above answers `400 E_VALIDATION_FAILED` with `error.fields.addresses.code` set to `E_ADDRESSES_INVALID`; the message names the rule that failed (a `registeredAgent` entry, an address outside the US, a missing type). The [full error table](/api/required-actions#errors) lists the rest.


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