API Quickstart

Integrate from the current contract, not tribal knowledge.

DutyClaims v1 is documented around the same contract that drives the API reference, downloads, and changelog. Start here if you are a developer, solution architect, or technical partner contact, then move into auth and the API-hosted reference.

Review Auth SDK Quickstarts Live Reference

Before your first call

Confirm the correct partner type and tenant model before you decide how auth, capabilities, and authority should behave.
Issue or rotate a managed credential and confirm whether your integration uses Authorization: Bearer … or X-API-Key.
Download the generated starter files and keep them pinned to the same contract hash as the environment you are targeting.
Decide which environment you are targeting and pin the docs render to the matching contract hash and downloads bundle.
Register webhooks early so asynchronous status changes do not get lost behind endless polling loops.
Start with a low-risk workflow such as client creation, claim submission, or a sandbox webhook test before enabling production traffic.

Environments Fetch Artifacts

Current contract scope

The live v1 contract currently covers 81 documented operations across 68 paths.

Authentication: 1 operations
Diligence: 5 operations
Partner Orgs: 8 operations
Clients & Authority: 11 operations
Entries & Scans: 7 operations
Claims: 9 operations
Financing: 8 operations
Litigation: 9 operations
Counterparty: 13 operations
Notifications: 3 operations
Reporting: 4 operations
Reference: 3 operations

Generated auth example

#!/usr/bin/env bash
set -euo pipefail

API_BASE_URL="${API_BASE_URL:-https://api.dutyclaims.com}"
TOKEN="${TOKEN:-dcp_live_replace_me}"

curl "${API_BASE_URL}/v1/clients" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Accept: application/json"

Generated write-path example

#!/usr/bin/env bash
set -euo pipefail

API_BASE_URL="${API_BASE_URL:-https://api.dutyclaims.com}"
TOKEN="${TOKEN:-dcp_live_replace_me}"

curl -X POST "${API_BASE_URL}/v1/claims" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
  "clientId": "00000000-0000-4000-8000-000000000000",
  "partnerClientId": "example",
  "partnerClaimReference": "example",
  "importer": {
    "legalName": "example",
    "ein": "example",
    "contactName": "example",
    "email": "example"
  },
  "entries": [
    {}
  ]
}'

RF8 in the public API surface

RF8 is Red Flag 8 in the diligence model: the importer does not yet have confirmed public import history. Public developer docs expose RF8 only as report contract truth, not as a separate source-lookup API.

Read rf8Review from diligence report responses when you need RF8 status in an integration.
Treat history_confirmed as the only automated-clear outcome.
Treat no_history_found, unable_to_verify, and ambiguous_match as states that still require DutyClaims analyst handling or preserved review state.
Do not expect a public RF8 source configuration route or a standalone RF8 API in the current platform.

What stays internal

RF8 source credentials and deployment readiness.
Analyst evidence capture, override, and rerun workflow.
Whether the source behind RF8 is a direct vendor API or a normalized proxy.
Manual fallback SOP when the configured source is missing, stale, or ambiguous.

Those operational details remain in internal runbooks so external developers consume one stable contract without being asked to reason about DutyClaims operator controls.

Environment truth

Production

Production-ready surface

Clients, claims, financing, litigation, notifications, revenue, webhooks, and reference data are the truthful v1 production surface today.

Sandbox Only

Sandbox-only auth

OAuth client-credentials token issuance is available for sandbox partner integrations. Production access still centers on managed credentials.

Provider Blocked

Provider-gated automation

Diligence and counterparty automation stay explicitly provider-gated until paid external provider activation is complete. The docs keep that boundary visible.

Practical first-day sequence

Read the raw contract and check the current docs hash before you copy any snippet into your codebase.
Create or inspect the partner client record, then verify authority state if the workflow depends on delegations or POA shortcuts.
Create the claim or scan only after the client relationship is truthful.
Wire webhooks before you rely on long-running lifecycle transitions such as claim status, financing, or litigation updates.
Use the live reference for exact schema details and the generated examples only as starter code.