Business Loan Dedupe
Dedupe is an optional check before collecting a full business credit application. Start with an authenticated POST, store data.journeyID, then use GET to read the operation and lender results. HTTP 202 means accepted; it does not mean the borrower passed Dedupe.
Omit journeyID to create a journey, or pass ?journeyID=<existing-journey-id> to reuse one for the same borrower. Keep borrowerProviderID stable. Reuse the idempotency key only for an exact retry, including after a timeout; never create a new journey merely because the response was lost.
Identifier modes
Both modes are available in the API request example selector. Supply at least one identifier. Identifier handling is configured for your application by Aarthik Labs. Do not send a mode field.
Hashing is separate from encryption. Unhashed identifiers are original values sent over authenticated HTTPS, not an unprotected transport. Keep API keys and identity data on your backend. Agree the hashed identifier representation with Aarthik Labs before implementation; the opaque values below are synthetic examples.
Anonymised (Hashed) Dedupe
Un-Anonymised (Un-Hashed) Dedupe
Start response and polling
The start POST returns HTTP 202 with data.status: PENDING and data.journeyID, without a polling object. Make the first Fetch Dedupe Results call after acceptance; use the polling guidance returned by that GET for subsequent reads. Both identifier examples in the API Reference show this accepted response.
A successful GET returns HTTP 200, even while processing is pending. Follow data.polling.nextPoll and stop when data.polling.shouldPoll is false. Do not repeat POST to poll. Respect Retry-After on 429.
Journey-level status
data.status is the overall Dedupe result for the journey. Each entry in data.lenders also has its own status, retaining detailed lender-specific values, including SKIPPED and ERROR.
SKIPPED counts as positive and ERROR counts as negative when calculating the journey outcome. The journey can only be CLEAR, NOT_CLEAR, or PENDING; individual lender statuses are preserved.
polling.shouldPoll is true only while the journey is PENDING. Inspect individual lender results to understand each lender’s outcome.
Lender results: pass, fail and errors
Each lender result also includes decisionReference, decidedAt, expiresAt and reasonCode when available. A borrower can pass one lender’s check and not pass another’s. Journey-level CLEAR is not universal lender clearance or loan approval.
Completed response
The Fetch Dedupe Results API Reference includes examples for all three journey statuses, including a pending journey with one lender already clear.
Continue with the same journey
Once results are terminal, continue only with lenders whose current result is CLEAR or SKIPPED. Use the returned data.journeyID as the journeyID query parameter for optional Eligibility and for Create A Journey. You can skip Eligibility. After Start, keep the same ID for offer polling and Hosted handoff.
For validation failures, fix the input before retrying. Do not retry authentication or access errors unchanged. For 429, follow Retry-After; for a transient dependency or server failure, retry with backoff and the same idempotency key. Do not substitute another journey for an invalid or unauthorized ID.