DutyClaims Docs
Developer Hub

Build with the API without confusing partner types, portal roles, or host ownership.

This section is for engineers, solution architects, and technical partner teams. It explains how the external API model fits the human web-app model, which partner types exist, and where to start for auth, reference, downloads, and live contract work.

Alpha

The DutyClaims partner API is in early alpha. Routes, request shapes, response contracts, and auth patterns are all subject to change without notice. Pin to the contract hash shown on this page and treat every endpoint as potentially deprecated until a stable release is announced.

What to verify first

  1. Pick the correct partner type so tenancy, capabilities, and authority expectations are explicit.
  2. Confirm whether the integration targets sandbox or production and pin the docs render to the right contract hash.
  3. Read the auth, SDK, and webhook pages before you rely on async state changes or automated retries.
  4. Use the core workflow map to decide which route family you actually need first instead of browsing the whole reference at random.
  5. Before production or migration cutover, move through the launch checklist and migration guide instead of inventing your own readiness bar.

Current deployment fingerprint

  • Contract hash: ae140b8f3b926d06
  • Route coverage: 81 operations across 68 paths
  • Latest release entry: 574ac28 • bypassed checks
  • Downloads bundle: 13 generated artifacts

Portal roles vs partner types

ConceptWhat it answersExamples
Portal roleWhich human workspace should this signed-in user land in?importer, broker, partner_admin, admin, attorney
Partner typeWhat kind of external API tenant is this organization?broker, saas_partner, forwarder_or_tms, service_provider
CapabilityWhat is that tenant allowed to do?Diligence reads, submissions, financing, litigation enrollment, webhooks, authority shortcuts
Sandbox Only

Authentication

Managed credentials everywhere, plus sandbox-only OAuth client credentials for partner testing.

1 operations in the current contract

Open workflow notes
Provider Blocked

Diligence

Submit portfolios, poll job status, and retrieve reports or datasets while provider-backed automation remains gated.

5 operations in the current contract

Open workflow notes
Production

Partner Orgs

Partner organizations, capabilities, webhook endpoints, and managed credentials.

8 operations in the current contract

Open workflow notes
Production

Clients & Authority

Canonical client records, authority state, delegations, invitations, and POA assertions.

11 operations in the current contract

Open workflow notes
Production

Entries & Scans

Entry ingest, batch normalization, and portfolio scan lifecycle endpoints.

7 operations in the current contract

Open workflow notes
Production

Claims

Claim scoring, claim creation, status reads, and claim document delivery.

9 operations in the current contract

Open workflow notes
Production

Financing

Offers, agreement sessions, and advance or disbursement state.

8 operations in the current contract

Open workflow notes
Production

Litigation

Enrollment, readiness, package delivery, and docket status reads.

9 operations in the current contract

Open workflow notes
Production

Counterparty

Counterparty profiles, diligence cases, provider runs, monitoring enrollment, evidence, and partner-safe reports with truthful deployment-readiness guardrails.

13 operations in the current contract

Open workflow notes
Production

Notifications

Partner-triggered notifications, delivery analytics, and client notification history.

3 operations in the current contract

Open workflow notes
Production

Reporting

Partner dashboards, revenue ledgers, and export surfaces.

4 operations in the current contract

Open workflow notes
Production

Reference

Official HTS-backed search, countries, and health metadata.

3 operations in the current contract

Open workflow notes

Operating a white-label SaaS tenant?

Start with the white-labeling guide if you want the business and operating model first. If you are already configuring branding, launch data, or the hosted customer journey as a partner operator, use the workspace guide next. The developer hub still covers the external API model, but the human setup console now lives in the SaaS partner guide.

Partner type

Broker integration

Best when the external organization is a customs broker or brokerage that needs importer relationship management, delegated authority flows, partner emails, commissions, and broker-specific operational paths.

Maps to both worlds: broker is a partner type for the API platform and also a top-level portal role for humans in the web app.


Best for

  • Customs brokerages
  • Book-of-business client onboarding
  • Broker-managed client invites and delegation flows

How to start

  • Start with the developer quickstart, then review authentication and the clients and authority routes.
  • Expect broker-only authority shortcuts such as delegation updates and POA assertions to stay broker-scoped.

Partner type

SaaS partner integration

Best when the external organization is a compliance platform, ABI-adjacent system, duty-analytics product, or embedded trade workflow that needs structured API access without broker-human workspace semantics.

Still not a portal role by itself. `saas_partner` classifies the external tenant, while human operators use the `partner_admin` workspace on the main host.


Best for

  • Compliance SaaS products
  • ABI vendors
  • Embedded trade workflow platforms

How to start

  • Start with the developer hub and partner capability model.
  • Assume weaker default authority than broker flows unless the tenant has explicit capabilities.

Partner type

Forwarder or TMS integration

Best when the external organization brings shipment context, logistics workflow, or transportation operations but does not fit the broker portal model.

No portal role. This is an external API tenant classification for shipment- and workflow-centric partners.


Best for

  • Freight forwarders
  • Transportation management systems
  • Logistics operations platforms

How to start

  • Start with the same developer quickstart, but do not assume broker-only authority paths exist.
  • Treat this as a partner tenant with capabilities, not as a new top-level human role.

Partner type

Service provider integration

Best when the external organization is a general service partner, specialist vendor, or channel-style integration that needs a tenant record and API or webhook capability but not a dedicated first-party portal workspace.

No portal role. This is the generic external-partner bucket when a tenant is neither a broker nor a clearly productized SaaS or logistics system.


Best for

  • Specialist service vendors
  • Channel or referral-style partners
  • General external operators that do not fit a more specific category

How to start

  • Start by deciding which capabilities the tenant actually needs rather than inventing a new portal role.
  • Use this type sparingly and document what the partner is expected to do.

Recommended developer path

  1. Pick the correct partner type first so tenant classification and capability expectations are explicit from day one.
  2. Read quickstart, SDK quickstarts, environments, auth, and webhooks before you write integration code.
  3. Use the workflow map to narrow the route families you actually need.
  4. Use the migration guide if you still touch /api/diligence/* or /broker/v1/* paths.
  5. Use the production launch checklist before requesting live credentials or cutover approval.
  6. Use the live interactive reference for exact request and response contracts.
  7. Keep the raw OpenAPI document and generated downloads pinned to the same release or deployment you are targeting.