The API reference is precise at the route level. This page is the missing middle layer: which workflow families exist today, which ones most teams implement first, and where the truthful production boundary still stops.
Use this path when you are onboarding the partner tenant itself before any client, claim, or notification work begins.
Most broker and platform integrations should make the client relationship explicit before they try to create claims or issue notifications.
This is the main production path for most integrations that submit work into DutyClaims and then need a durable status surface.
These workflows sit downstream of partner onboarding and claims, and some remain intentionally gated by provider readiness or capability flags.
This is the safest default integration order for most partner teams: prove tenant readiness, create the client relationship, create the claim once authority is truthful, then observe status through reads and webhooks.
| Step | Route | Purpose | What to check next |
|---|---|---|---|
| 1 | GET /v1/partner-organizations/{partnerOrgId} | Read tenant state, environment, and the partner record you are about to act as. | Confirm sandbox versus production and that the partner org itself is the one you expect. |
| 2 | POST /v1/webhooks/endpoints | Register the listener before you depend on asynchronous status changes. | Store the signing secret and run a synthetic sandbox test before live traffic. |
| 3 | POST /v1/clients | Create or link the canonical partner client that later claims, offers, and notifications depend on. | Persist the returned client identifier instead of keying later requests off ad hoc importer strings. |
| 4 | GET /v1/clients/{clientId}/authority | Read delegation, POA, and current authority posture before assuming the relationship is actionable. | If authority is not truthful yet, fix that state before submitting the claim. |
| 5 | POST /v1/claims | Create the claim once the client relationship and importer identity are ready. | Use an idempotency key so a network retry does not create a duplicate claim. |
| 6 | GET /v1/claims/status | Read the list-style status surface while webhooks carry the asynchronous lifecycle edge. | Use `/v1/webhook-deliveries` when the webhook path and the status path disagree. |
Teams migrating from the earlier diligence-first surface should use this sequence when the partner workflow still revolves around bulk submission, job polling, report reads, and controlled resumption.
| Step | Route | Purpose | What to check next |
|---|---|---|---|
| 1 | POST /v1/diligence/submit | Submit the diligence portfolio with the current compatibility contract. | Record the returned job identifier immediately; later reads depend on it. |
| 2 | GET /v1/diligence/status/{jobId} | Poll the durable job status rather than inferring progress from queue timing. | Use the status payload to decide whether to read the report, dataset, or resume path next. |
| 3 | GET /v1/diligence/report/{jobId} | Read the report contract, including typed review detail such as `rf8Review`. | Treat report output as the public source of truth for diligence outcomes. |
| 4 | GET /v1/diligence/dataset/{jobId} | Fetch the dataset view when the downstream system needs the detailed rows, not just the summary report. | Keep dataset consumers pinned to the same contract version as the report readers. |
| 5 | POST /v1/diligence/jobs/{jobId}/resume | Resume only when the job is partial or failed and the operator workflow actually calls for it. | Treat resume as an explicit operational action, not as automatic blind retry behavior. |
RF8 uses a split documentation model on purpose. Public developer docs describe the contract-visible diligence result, while internal docs keep the operator-only source and review workflow.
rf8Review means in diligence report responses and how integrations should interpret the typed outcomes.rf8Review object instead of inferring RF8 from prose only.Partner organizations, capabilities, webhook endpoints, and managed credentials.
8 documented operations
/v1/partner-organizations/{partnerOrgId} Fetch partner organization state/v1/partner-organizations/{partnerOrgId}/branding Fetch partner branding and white-label policy state/v1/partner-organizations/{partnerOrgId}/branding Create or update partner branding and default delivery policy/v1/partner-organizations/{partnerOrgId}/capabilities Fetch partner capabilitiesPlus 4 more routes in the live reference.
Canonical client records, authority state, delegations, invitations, and POA assertions.
11 documented operations
/v1/client-invites/{token}/accept Accept a client invite/v1/clients List client accounts for the authenticated partner/v1/clients Create or link a canonical partner client/v1/clients/{clientId} Fetch a partner-scoped clientPlus 7 more routes in the live reference.
Claim scoring, claim creation, status reads, and claim document delivery.
9 documented operations
/v1/claim-scores Score normalized entries without creating a claim/v1/claims List partner-accessible claims/v1/claims Create a partner claim linked to a client relationship/v1/claims/{claimId} Fetch a partner-safe claim read modelPlus 5 more routes in the live reference.
Partner-triggered notifications, delivery analytics, and client notification history.
3 documented operations
/v1/notifications Request a tracked partner notification for one client/v1/notifications/analytics Fetch aggregate delivery and engagement analytics for partner notifications/v1/notifications/batches Request a tracked partner notification for a filtered client batchPartner dashboards, revenue ledgers, and export surfaces.
4 documented operations
/v1/partner/dashboard Fetch aggregate partner dashboard metrics and scoped revenue totals/v1/revenue/dashboard Fetch canonical partner revenue dashboard totals/v1/revenue/ledger List canonical revenue ledger entries for the authenticated partner/v1/revenue/ledger/export Export the partner revenue ledger as CSV or JSONEntry ingest, batch normalization, and portfolio scan lifecycle endpoints.
7 documented operations
/v1/entries/{entryNumber}/status Fetch entry ingest status for an entry number/v1/entries/batch Ingest a partner entry batch through a named adapter/v1/entries/ingest Ingest a single canonical entry/v1/portfolio-scans Create a durable portfolio scan jobPlus 3 more routes in the live reference.
Offers, agreement sessions, and advance or disbursement state.
8 documented operations
/v1/advances/{advanceId} Read a financing advance and its current disbursement state/v1/advances/{advanceId}/disbursement Initiate or queue disbursement for a financing advance/v1/agreements/{agreementId} Read financing agreement state/v1/agreements/{agreementId}/session Create or refresh a financing agreement signer sessionPlus 4 more routes in the live reference.
Enrollment, readiness, package delivery, and docket status reads.
9 documented operations
/v1/litigation/cases List litigation cases for the authenticated partner/v1/litigation/cases/{caseId} Fetch a litigation case and its partner-safe status summary/v1/litigation/cases/{caseId}/events List structured events for a litigation case/v1/litigation/cases/{caseId}/events Append a partner-originated litigation status or docket eventPlus 5 more routes in the live reference.
Official HTS-backed search, countries, and health metadata.
3 documented operations
/v1/health/public Return public API health and capability metadata/v1/reference/countries List supported reference countries/v1/reference/hts/search Search the synced official HTS release with DutyClaims overlay contextManaged credentials everywhere, plus sandbox-only OAuth client credentials for partner testing.
1 documented operations
/v1/oauth/token Issue a sandbox OAuth client-credentials tokenSubmit portfolios, poll job status, and retrieve reports or datasets while provider-backed automation remains gated.
5 documented operations
/v1/diligence/dataset/{jobId} Fetch entry-level dataset JSON, CSV, or XLSX/v1/diligence/jobs/{jobId}/resume Resume a failed or partial bulk job/v1/diligence/report/{jobId} Fetch diligence report JSON or PDF/v1/diligence/status/{jobId} Fetch diligence bulk-job statusPlus 1 more routes in the live reference.
Counterparty profiles, diligence cases, provider runs, monitoring enrollment, evidence, and partner-safe reports with truthful deployment-readiness guardrails.
13 documented operations
/v1/counterparties List counterparties for the authenticated partner/v1/counterparties Create a counterparty profile/v1/counterparties/{counterpartyId} Fetch a counterparty profile/v1/counterparty-diligence/cases List counterparty diligence casesPlus 9 more routes in the live reference.