Skip to content

Intake API overview

Submit a Home, Auto or Bundle insurance application in one request. Credify stores it as a draft and sends the customer a secure link to review and confirm it. Nothing is rated until the customer confirms.

POST https://api.getcredify.com/intake
Authorization: Bearer <your API key>
Content-Type: application/json

There is one production host and no separate sandbox: a test key is how you test. Request bodies can be up to 256 KB.

product Sections
Home customer, address, home, demographics
Auto customer, address, auto, demographics. The Auto flow also asks about an existing homeowners policy, so home.home_has_prior_insurance and home.home_prior_carrier_name are accepted too.
Bundle customer, address, home, auto, demographics

Field-by-field detail: Applicant fields, Home, Auto, Bundle.

  • A bad value never fails the request. Only values that can’t be used at all are dropped, such as a date that isn’t a date, a phone without 10 digits or an SSN that isn’t 9 digits. Each drop is reported in warnings.
  • Use exact code values for enum fields. An unknown value is not corrected or mapped. The customer sees that field empty and flagged on the review page, and has to pick a valid option before they can submit.
  • Send what you have. Anything missing is completed by the customer on the review page. missingCriticalFields in the response lists the contact details you didn’t send.
  • SSNs are encrypted at rest and never stored in plain text.

With a live key, the link goes out during the request itself, before the 201 returns:

  • By text when consent.sms_review_link is true and a valid phone is present. Ask the customer before you set it.
  • By email whenever a valid email is present. The email is transactional, so it does not need consent.
  • Both messages carry the same link, and each channel is used at most once per application. Use the resend action to send it again.

A test key never contacts the customer.

Every application is credited to your firm by the key that sent it.

  • clientRef in the response identifies the application in your reporting and links it to any commission it earns. Store it.
  • sub_id in the request is your own campaign or placement label, such as "spring-2026-email". It is shown in your reporting so you can see which channels produce applications.

If you also embed the widget, it is attributed separately with your public partner ID. The two never mix: the Intake API refuses a cp_ ID, and the widget ignores anything that isn’t one.

call.id is the idempotency key. Use your own record id for the application, so it is unique per application and stable across retries.

  • Re-sending a call.id you already sent returns the existing draft with 200 and "idempotent": true. No duplicate is created and the customer is not messaged again.
  • call.id values are scoped to your firm, so another partner’s ids can never collide with yours.
  • Retry 429, 5xx and timeouts with the same call.id. A request can time out after 30 seconds even though the draft was created; the retry returns it.
  • Never reuse a call.id for a different customer. The retry returns the first customer’s draft.

Each key can make 120 requests a minute. Over that, requests receive 429 with a Retry-After header giving the seconds to wait.

Applications are rated in TX and NJ today. Applications from other states are stored and flagged with unsupported_state:<state> in warnings.