Sandbox only. The playground exists only on
https://api.test.doola.com; the routes do not exist in production. Authenticate with your sandbox API key (dk_test_...), like any other request.The two milestones
Each endpoint runs the same operations production runs when the real milestone happens. Webhooks are emitted by the normal pipeline: signed, filtered by your event subscriptions, retried on failure, and visible in the Partner Portal delivery logs. Documents go through the real upload flow, and service statuses advance exactly as they do in production. The playground never fabricates an event, so what you build against it holds in production.
Walkthrough
You need a sandbox API key and a webhook endpoint configured in the Partner Portal (see Webhooks). If you just want to watch events arrive before wiring up your backend, a request inspector such as webhook.site works fine as the endpoint.1
Create a customer and a company
Use the regular Create customer and Create company calls with your sandbox key. Shortly after the company is created,
company_formation_submitted arrives at your webhook endpoint and formationSubmissionStatus becomes SUBMITTED. Nothing playground-specific yet: that event follows the normal create flow, in sandbox as in production, which is why the playground has no endpoint for it.2
Complete the formation
Trigger the “state confirms formation” milestone:Your endpoint receives
company_formation_completed and document_aoo_uploaded. On the company, formationFilingDate is set, the Articles of Organization appear in the documents list, and the Formation service advances to Completed. triggeredEvents additionally lists the entity type’s governance document event — document_corporatebylaws_uploaded for a CCorp, document_operatingagreement_uploaded for an LLC: doola generates the governance document shortly after the Articles are processed, and the event and document follow, exactly as in production.3
Complete EIN creation
Trigger the “IRS issues the EIN” milestone:Your endpoint receives
company_ein_issued and document_einletter_uploaded. On the company, ein is populated with the test value 12-3456789, the EIN letter appears in the documents list, and the EinCreation service advances to Completed.4
Verify
Fetch the company and confirm
formationFilingDate, ein, and the services[].status values; list its documents and download each one; and check the delivery log in the Partner Portal, which records every attempt with its HTTP status.What to expect
- Statuses advance asynchronously. The Formation and EinCreation
statusvalues (see Company services) are derived by doola’s systems moments after each call, not atomically within the response. React to the webhooks, or allow a short delay before asserting on the company, rather than asserting synchronously. - Documents are placeholders. The Articles of Organization and EIN letter are placeholder PDFs, but they flow through the real pipeline: list them and fetch download URLs exactly as in production. A CCorp’s Corporate Bylaws and an LLC’s Operating Agreement are generated from the company’s real formation data, exactly as in production.
- Test values are fixed. The EIN is always
12-3456789, andformationFilingDateis the date you made the call. A test note also appears in the company’sadminNotes. - Repeat calls re-fire webhooks. Calling a playground endpoint again re-runs the milestone:
company_formation_completedfires again, and the document events fire again with a freshdocumentId. That makes repeat calls a handy way to re-test your handler and its idempotency. The exception iscompany_ein_issued, which fires only on the first issuance, exactly as in production — a repeateincreation/completetherefore lists onlydocument_einletter_uploadedintriggeredEvents.
What the playground does not simulate
The playground models the standard US-founder flow. It has no endpoint for:company_formation_failedandcompany_filing_date_updateddocument_mail_uploaded(business mail)- The non-US founder signing milestones (the
signature_*and SS-4 / Form 8821 document events); see Non-US founders
Errors
The global error codes apply as usual. In production the routes themselves do not exist, so any call there returns a plain 404.