Importers and claim owners
Use the importer workspace to onboard the company, create claims, manage documents, and coordinate with brokers or attorneys from one portal.
DutyClaims now has two distinct documentation tracks: plain-language guides for people using the product and developer documentation for teams building integrations. Start with your role so you land on the right instructions immediately.
Portal role: importer
Use the importer workspace to onboard the company, create claims, manage documents, and coordinate with brokers or attorneys from one portal.
Portal role: broker
Use the broker workspace to register the brokerage, work the client queue, invite importers, and manage commissions, payouts, and API keys.
Portal role: partner_admin
Use the partner-admin workspace to configure the hosted tenant, prepare branding and launch data, and understand the customer-safe hosted flow the SaaS partner is operating.
Portal role: attorney
Use the attorney workspace to onboard the firm, manage representations, run deadlines, work matters, move protests and CIT matters through explicit legal-operating tracks, and control bounded external matter sharing.
Portal role: admin
Use the admin and internal-ops workspaces to run approvals, work the claims pipeline, manage diligence and seller data rooms, inspect partner readiness, debug delivery health, and publish updates.
Which human workspace a signed-in user opens: importer, broker, partner_admin, admin, or attorney.
What kind of external API tenant an organization is: broker, SaaS partner, forwarder or TMS, or service provider.
What an API tenant is allowed to do once it is onboarded.
Diligence analyst work, seller data rooms, and secure attorney-share recipients stay inside the admin or attorney guides; white-label SaaS partner setup now has its own dedicated partner-admin guide.
Start here if you are building on the API and need the partner model, host split, and practical integration path before reading raw route docs.
Open →How the hosted partner model works, why SaaS teams use it, and what DutyClaims handles behind the branded experience.
Open →Credentials, first requests, generated examples, and the safest order to integrate.
Open →Copy-paste TypeScript starters for canonical partner flows, diligence compatibility, broker aliases, and webhook verification.
Open →Canonical domains, sandbox versus production rules, release pinning, and environment scope.
Open →Production managed credentials first, sandbox OAuth where explicitly supported, plus current header semantics.
Open →Current API families, representative routes, and the route order most partner teams implement first.
Open →Endpoint registration, signature verification, sandbox test events, and delivery debugging.
Open →Problem payload anatomy, request IDs, retry discipline, and problem-type troubleshooting paths.
Open →Vulnerability reporting contact, security.txt locations, disclosure expectations, and good-faith testing boundaries.
Open →Go-live proof points for credentials, tracing, idempotency, webhooks, support handoff, and cutover discipline.
Open →Move legacy diligence and broker-compatibility traffic onto canonical `/v1/*` routes without losing operational visibility.
Open →The live interactive reference stays on the API host so contract and route behavior remain aligned.
Open →Workspace guides
Role-based guides for portal users
API operations
12 workflow families across 81 operations.
Contract hash
Current docs render fingerprint
Downloads
574ac28 • bypassed checks
Clients, claims, financing, litigation, notifications, revenue, webhooks, and reference data are the truthful v1 production surface today.
Open related docsOAuth client-credentials token issuance is available for sandbox partner integrations. Production access still centers on managed credentials.
Open related docsDiligence and counterparty automation stay explicitly provider-gated until paid external provider activation is complete. The docs keep that boundary visible.
Open related docs