Skip to main content
Can’t find your answer? Email engineering@doola.com. For the Partner API, see its own FAQ.

​
Business

The same formation as through the Partner API: the state filing, the EIN, the registered agent and the governance document, an Operating Agreement or Bylaws. See What is included in a formation?.
According to your partner agreement. Nothing is filed for a formation until you confirm payment for it.
You do. The SDK never shows your price. The only amount the founder sees inside it is the state filing fee for their state and entity type, which the state charges, so your checkout can show the same number.
The flow carries your logo, colors and font, and no “Powered by doola” line. doola’s name appears only in a few places: as the included registered agent on the Addresses step and the review, in the message for an email that already has its own doola account, and in the documents themselves, which are doola’s and the state’s. See What stays doola.
Yes. SDK companies are ordinary companies in your partner account: you read them, download their documents and answer their required actions through the Partner API, and their webhooks arrive at the same endpoint. For new company names, the founder can also answer in the SDK.
No, and that is deliberate. doola keeps the wizard in line with each state’s and the IRS’s rules and ships changes without any work on your side. You control how it looks through branding.

​
Payments

No. You charge the founder in your own checkout, with your own payment provider, at your own price. doola never sees their card.
It tells doola to start the formation. doola does not check your payment provider: partnerReference is stored for your reference and never verified. So you decide when to call it, for example straight after a card payment, once an invoice is paid, or right away for a free offer.
The formation stays at AWAITING_PAYMENT, and nothing is filed. Whenever the founder comes back to the SDK, they see that payment is pending and can reopen your checkout. To withdraw it for good, contact doola to cancel it.
Refunds to the founder are yours, under your own policy. If doola answers a confirmation with 409 E_COMPANY_CANCELLED, the formation was cancelled and the payment was not applied, so refund the founder. Once you have confirmed, filing has started; contact doola about the formation if the founder wants to stop.
Not in the SDK today. Every SDK formation is the standard formation.
No. The first webhook for an SDK company is company_formation_submitted, after you confirm payment. Your page learns about the submission through onFormed, so save the companyId with your order as soon as your checkout opens. See Keep your records in step.

​
The founder’s experience

No. They are signed in to your product, and your server vouches for them when it creates their session. They never see a doola sign-in.
The wizard takes most founders a few minutes. After you confirm payment, state filing usually takes 2 to 5 business days, and the EIN follows once the state approves. The founder follows both on their dashboard.
Not through the SDK. Each customer forms one company, and from then on the SDK shows them that company’s dashboard. A customer who already has a company in your account, including one you created through the Partner API, sees its dashboard too.
Not in the SDK. Before you confirm payment, ask doola to cancel the formation; the founder can then start again. After you confirm, contact doola.
Their progress is saved on every step. Within 7 days, in the same browser, they continue where they stopped. Any SSN or ITIN they typed is asked for again, because it is never saved.
Yes. Founders anywhere can form a US company. Without an SSN, they sign the IRS Form SS-4 inside the SDK after you confirm payment.
Yes. On screens 640px wide or narrower, the SDK opens full screen so the keyboard never covers a field. See Presentation and mobile.
English. When more languages ship, your integration picks them up through the locale option, with no change to how you embed the SDK.

​
Data and security

No. The founder types them into the SDK’s iframe, which is served by doola and sends them straight to doola. Your page, your servers, your error tracking and your session replay never see them. See Security and data.
script-src https://js.doola.com and frame-src https://sdk.doola.com in your CSP, and the doola-js Trusted Types policy if you enforce Trusted Types. Nothing else. See Content Security Policy.
No. Sessions live in memory. Browsers that block storage in iframes still run the whole flow; the founder’s unfinished wizard is then kept only until they leave the page.
Very little. It acts as one customer, only in the SDK, for at most 10 minutes. It cannot read any other customer or call the Partner API.

​
Integration

Any. @doola/js is framework-free: you append an element. Embed the SDK shows React, Next.js and Vue, and the session route works on any server language.
Replace the SDK element with a new one after you confirm, for example element.replaceWith(doola.create()). The payment screen does not watch for your confirmation by itself, and each create() is its own iframe, so never leave the old one on the page.
Not step by step. You receive onLoaderStart when the SDK first shows something and onFormed when the founder submits.
Nothing on your side. The wizard and the loader update in place, and they stay compatible with every @doola/js release in the same major version. Update the package when you want new options.
Call doola.destroy() when the first user signs out, then loadDoola() again for the next one.
Creating sessions is limited to 600 a minute for your partner account. Your other Partner API calls share the Partner API’s limit. On 429 E_RATE_LIMITED, wait the Retry-After seconds.

​
Troubleshooting

The iframe was probably blocked. Check your CSP’s frame-src for https://sdk.doola.com (or https://sdk.test.doola.com with test keys), and look for render_error in onLoadError. See render_error.
Your session route failed for a reason other than a sign-out or a 409, such as a 5xx, a timeout or an invalid response. Each Try again calls your route again, up to three times, and every failure reaches onAuthError as mint_failed. Check your route’s logs and the doola code that onFailure logs.
Your domain is not yet on doola’s list for embedded signing. Send doola every domain that hosts the SDK. Meanwhile, the founder can use the “Open it in a new tab” link.
Their email already belongs to a doola account of their own, outside your partner account, or to a Partner Portal user (testing with your own email does this). If your route forwards only the status, any 409 arrives as email_in_use: forward doola’s code so an externalCustomerId conflict arrives as external_id_conflict instead, and check doolaCode in your server logs.
Replace the SDK element with a new doola.create(). The payment screen only changes when a new element mounts.
That is expected: it fires on submit and every time the founder asks to pay. Key your order and your charge on companyId.
The request probably reached your route without your sign-in cookie. If the route is on another domain than your page, call it with credentials: 'include' and allow that in your CORS settings.
A different publishable key needs the old instance destroyed first. Call doola.destroy(), then loadDoola() again.
Last modified on October 8, 2026