> ## 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.
# Testing
> Run the whole SDK flow in the test environment: wizard, payment, signing, filing and EIN, with nothing filed and nothing charged.
The test environment is a complete copy of production. Use your test keys and the SDK talks to it automatically: the `pk_test_` key loads the app from `sdk.test.doola.com`, and the `dk_test_` key calls `api.test.doola.com`. Nothing is ever filed with a state or the IRS.
| | Test | Live |
| - | - | - |
| Publishable key | `pk_test_...` | `pk_live_...` |
| Secret key | `dk_test_...` | `dk_live_...` |
| Embedded app | `https://sdk.test.doola.com` | `https://sdk.doola.com` |
| Partner API | `https://api.test.doola.com` | `https://api.doola.com` |
| Branding and webhooks | Set in your sandbox portal account | Set in your production portal account |
## Run a formation end to end
Each customer forms one company, so every run needs a fresh one. Sign in to your app as a new user, or send a new email and `externalCustomerId` when you mint the session. Plus-addresses such as `you+sdk42@yourcompany.com` work well.
Use realistic but made-up details. Leave the SSN empty to see the signing flow for founders without one.
Take the payment with your provider's test mode, then confirm it with your `dk_test_` key, exactly as in production. Mount the SDK again: the founder's dashboard opens, on the signing step if no SSN was given.
Sign the SS-4 inside the SDK. The test signing pages carry a "DEMO" watermark, and nothing reaches the IRS.
Wait for `company_formation_submitted`, then use the [sandbox playground](/api/sandbox-playground) to complete the formation and issue the EIN on demand. Each call fires the real webhooks, and the documents appear on the founder's dashboard.
**Confirm payment before you use the playground.** Like production, the playground never forms an unpaid company. It refuses one that is still `AWAITING_PAYMENT` with `422 E_FORMATION_AWAITING_PAYMENT`, and a cancelled one with `409 E_COMPANY_CANCELLED`, and leaves it unchanged.
## Scenarios worth testing
| Scenario | How | Expect |
| - | - | - |
| LLC and C-Corp | Pick each on the Entity step | Members and ownership for an LLC, officers and shares for a C-Corp |
| Founder outside the US | Choose "I live outside the US", no SSN | The SS-4 signing step after payment |
| The founder leaves mid-wizard | Close the tab, come back later in the same browser | The wizard resumes where they left off, and asks for any SSN again |
| The founder leaves before paying | Close your checkout, come back in 10 minutes | "Payment pending." with **Continue to payment**, which fires `onFormed` again |
| A double submit | Press **Pay** twice, or open checkout in two tabs | One charge, one confirmation |
| A failed confirmation | Make your confirmation call fail once | Your retry or sweep confirms it later |
| A cancelled formation | Ask doola to cancel a test formation, then confirm it | `409 E_COMPANY_CANCELLED`, and your refund path runs |
| Your user signs out | Sign out in another tab while the SDK is open | `onAuthError` with `partner_session_expired` on the next renewal |
| Your session route fails | Make it answer 503 | "We could not start your session" with **Try again**, `mint_failed` on each try, and "Please contact the team you signed up with." after three |
| New company names needed | Ask doola to raise the action on a test company | The Required action banner, and "Choose new company name" on the dashboard |
| An email that has its own doola account | Mint a session for that email | `email_in_use`, and with the code forwarded the SDK explains it to the founder |
| Phones | A viewport 640px wide or narrower | The SDK opens full screen, and closes when you remove it |
| Safari and iOS Safari | Real devices, not only a desktop emulator | The full flow, including signing |
| A blocked frame | Remove `sdk.test.doola.com` from your CSP's `frame-src` | `render_error` from `onLoadError` within 20 seconds, and your fallback |
## Signing on your test domains
Embedded signing renders only on domains doola has allowed, and that includes your staging and preview domains. Send them to doola before you test signing there. Until then, the founder's new-tab link still works.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.