Skip to main content
This section gives developers a high-level understanding of student loan refinancing as a product category and how to integrate with Credible using Prefill API and the Student Loan Refi Platform API (server-to-server lead submission + offer retrieval).

What “Student Loan Refinance” Means (Product Overview)

Student loan refinance replaces one or more existing student loans with a new private loan (often with a different lender/servicer). Typical borrower goals:
  • Lower monthly payment (often by extending term length)
  • Maximize savings (reduce APR / total interest)
  • Faster debt payoff (shorter term, higher payment)
Key implications for integrators:
  • Prequalification is risk-based and depends on borrower attributes (income, housing payment, employment status, education, etc.).
  • Not all leads will return offers; a lead can be processed successfully and still return no offers.
  • Offers are time-bound (see summary.expiresAt) and should be presented with required disclosures.

Integration Surfaces: Prefill API vs Platform API

1) Prefill API (best for “handoff into Credible”)

Use when you want Credible to handle more of the application UX and you primarily want to reduce user friction by pre-populating known fields. Typical usage
  • You have a user in your experience → you collect some inputs → you create a prefilled handoff into Credible’s flow.
When to choose it
  • You prefer a lighter integration.
  • You do not need to display a ranked list of offers natively.

2) Student Loan Refi Platform API (best for “native offers in partner UI”)

Use when you want to submit leads server-to-server, then retrieve and render prequalified offers in your UI. Typical usage
  • Your backend submits a lead → you poll or receive a callback → you render offers → user clicks handoffLink for the chosen offer.
When to choose it
  • You want a deeper integration and native offer presentation.
  • You need full lifecycle tracking via partnerLeadId and offer uuids.

Student Loan Refi Platform API

Core Concepts and Rules

Server-to-server only

Requests must be initiated from your backend. Do not call these endpoints directly from a browser.

Account association

Every lead is associated to a Credible account by borrower email:
  • If the borrower is new, Credible creates an account; borrower views results on partner site.
  • If the borrower already exists, no new account is created; borrower may be prompted to authenticate when clicking through.

Consents (mandatory for platform)

Before sending borrower data to Credible the first time, you must collect and store the borrower’s acceptance of Credible’s terms/disclosures and pass it in borrower.consentData. By submitting consentData, you attest that you collected the proper consent.

Async vs sync behavior

  • Lead submission is synchronous for acceptance (you get a uuid and initial status like created).
  • Offer generation is often asynchronous (status may be in_progress before success), so you must:
    • Poll GET /leads/:uuid, or
    • Use callbacks if your integration supports them.

End-to-End Transaction Flow (Polling)

+------------------+         +---------------------+
| Partner Backend  |         | Credible Platform   |
+------------------+         +---------------------+
        |                               |
        | 1) POST /oauth2/token         |
        |------------------------------>|
        |<------------------------------|
        |        accessToken            |
        |                               |
        | 2) POST /refi/v2/leads        |
        |   (Lead Input Data)           |
        |------------------------------>|
        |<------------------------------|
        |   201 Created: { uuid, ... }  |
        |                               |
        | 3) GET /refi/v2/leads/:uuid   |
        |------------------------------>|
        |<------------------------------|
        |  { status: in_progress }      |
        |                               |
        | 4) GET /refi/v2/leads/:uuid   |
        |------------------------------>|
        |<------------------------------|
        | { status: success, offers[] } |
        |                               |
        | 5) Render offers + disclosures|
        | 6) User clicks handoffLink    |

End-to-End Transaction Flow (Callback)

+------------------+         +---------------------+
| Partner Backend  |         | Credible Platform   |
+------------------+         +---------------------+
        |                               |
        | 1) POST /refi/v2/leads        |
        |   (includes callbackUrl)      |
        |------------------------------>|
        |<------------------------------|
        |   201 Created: { uuid }       |
        |                               |
        |        ...processing...       |
        |                               |
        | 2) POST callbackUrl (results) |
        |<------------------------------|
        |  (partner returns 2xx only)   |

Object Model

LeadInputData
  ├── partnerLeadId (your tracking key)
  ├── partnerCampaignId (optional attribution)
  ├── requestedLoanAmount
  └── borrower
        ├── identity (name, email, dob, phone, ssn/last4)
        ├── financials (income, housingPayment, netWorth)
        ├── education[] (degree + OPEID schoolKey)
        ├── address
        └── consentData (required for first-time submission)

Lead (result)
  ├── uuid
  ├── status (created | in_progress | success | failed)
  ├── outcome (eligible | declined | apply_manually | cosigner_needed)
  ├── summary (expiresAt, requestedLoanAmount)
  ├── loanOffers[] (ranked by recommendationScore)
  └── disclosures (privacyPolicyText, generalDisclosures, lenderDisclosure)

Faster Offers processing Retrieval

Credible makes it possible to recieve partial results, creating the ability to display offer batches back to users on the client side faster than waiting for the entire loan request to process using the following integration setup.
+------------------+          +---------------------+
| Partner Backend  |          | Credible Platform   |
+------------------+          +---------------------+
        |                                |
        | 1) GET /leads/:uuid/internal   |
        |------------------------------->|
        |<-------------------------------|
        |   offers[] (internal)          |
        |                                |
        | 2) Render internal offers      |
        |                                |
        | 3) GET /leads/:uuid/external   |
        |------------------------------->|
        |<-------------------------------|
        |   offers[] (external)          |
        |                                |
        | 4) Append external offers      |