Eligibility Inputs
Eligibility and Dedupe are independently optional. Submit at least one of Bureau, Banking or GST, or any combination. Obtain borrower authorization for all supplied financial information. Eligibility is preliminary and does not guarantee an offer or approval.
Journey creation and reuse
Omit the optional journeyID query parameter when Eligibility is your first call. The response returns data.journeyID. If Dedupe has already returned an ID, supply it here. Pass the same ID to Create A Journey, offer polling and handoff. You can use Eligibility without completing Dedupe first.
All four examples below are also selectable in the Eligibility API Reference.
Input structure
- Bureau:
typeisCIBIL,EXPERIAN,EQUIFAX, orCRIF. The existingconsentReferenceis retained.datais a JSON object. - Banking: An array of records. Each record has a
periodwithfromandtodate-times, atypeofCURRENT,SAVINGS, orCC, and adataJSON object. - GST: An array of records. Each record has a
period, atypeofGSTR-1,GSTR-2A_GSTR-2B, orGSTR-3B, and adataJSON object.
Period timestamps include a timezone and from must not be later than to. Each data object can contain nested properties. Your data can retain its existing structure. Contact Aarthik Labs to confirm support for your financial data provider. The values below are synthetic and do not prescribe a provider’s schema.
The comments beside data below explain its free-form shape. They are documentation annotations; omit comments from JSON sent to the API. In the API Reference, select JavaScript to see the same inline notes in executable examples.
Bureau only
Banking only
GST only
Bureau, Banking and GST
Start, then read Eligibility
The Start Eligibility API accepts the financial inputs with POST and returns HTTP 202, data.journeyID, and a pending operation. The Start response has no polling object. Store the ID and make the first Fetch Eligibility Results GET after acceptance. Follow the polling guidance in that GET response for later reads; do not resend financial information to poll.
The Fetch Eligibility Results API returns HTTP 200 for a successful read. data.status is the journey-level status; each lender has its own decision 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 ELIGIBLE, NOT_ELIGIBLE, or PENDING; individual lender statuses are preserved.
Lender decisions are ELIGIBLE, NOT_ELIGIBLE, SKIPPED, ERROR, or PENDING. An error is not a credit rejection. Eligibility does not guarantee an offer or approval. Follow data.polling.nextPoll while data.polling.shouldPoll is true; it is false for every non-pending journey status. Respect Retry-After on 429 and use backoff for transient failures. Do not restart the operation to poll.
Once the operation is terminal, use the same journeyID for Create A Journey and continue only where the lender result permits it. Retain the original borrower identity. Invalid, unknown or unauthorized journey IDs must not create replacement journeys.
Provisional terms per lender
Each entry in data.lenders includes the following fields alongside its eligibility decision. The terms are indicative, may change after further assessment, and are not a final offer or loan approval. They are populated when available for an eligible lender; otherwise the fields are null, including pending and ineligible results. Do not treat null as zero.
The Fetch Eligibility Results API shows these in the eligible and pending-with-one-eligible-lender examples. No offer ID or handoff URL is created by this preliminary assessment. Continue with Create A Journey, display the resulting actual offers and terms, and request handoff only after offer selection.