API Conventions

The LendAPI REST API uses resource URLs, JSON request bodies and JSON responses. This page describes the patterns shared across endpoints, so you can write one client that handles responses, errors and paging the same way everywhere. For the details of each endpoint, see the API reference.

Request and response format

Requests

• Base URL: https://app.lendapi.com/api/v1/ for both Sandbox and Production. Your key picks the environment. See Sandbox and Live.
• Authentication: Authorization: Bearer <your API key> on every request. See Authentication.
• Body format: JSON. Send Content-Type: application/json on every request with a body. Some endpoints, such as Run Decision, reject other content types with 415.
• Trailing slash: paths end with a slash, for example /application/, unless the reference shows otherwise. Copy paths exactly from the reference.
• IDs: applications, decision trees, pricing engines and sub-tenants are identified by a UUID, for example d130f351-26a1-4698-9b64-92ae8c46c644. Some resources, such as products, variables and outcomes, use integer IDs.

Responses

Successful responses are JSON objects. Most include these top-level fields:

Other fields depend on the endpoint. For example, creating an application:

curl -X POST https://app.lendapi.com/api/v1/application/ \
  -H "Authorization: Bearer test_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"first_name": "Jane", "last_name": "Doe", "email": "[email protected]", "product_id": 101}'

{
  "object": "application",
  "url": "api/v1/application/",
  "id": "d130f351-26a1-4698-9b64-92ae8c46c644",
  "app_number": 48213,
  "customer_id": 9921,
  "redirect_url": "https://apply.example.com/v2/application/product/abc123/d130f351-26a1-4698-9b64-92ae8c46c644/"
}

👍

Ignore unknown fields

Read the fields you need by name and ignore any you don't recognize. New fields may be added to responses without notice.

Dates and numbers

• Date of birth (birth_date when creating an application) must be a string in MM/DD/YYYY format, for example 11/01/1991. Other formats are rejected with 400 and the message "Date of birth format should be mm/dd/yyyy".
• Application timestamps returned by Get an application (app_created) are formatted for display in your workspace's time zone, for example 03/14/2026 02:05 PM PST. Don't parse them as ISO 8601.
• Applicant identifiers that look like numbers, such as ssn, zipcode and mobile, must be sent as JSON strings, for example "02134". This also keeps leading zeros.

Handle errors

Status codes at a glance

🚧

400 vs 404

Some endpoints return 400 for an ID that doesn't exist, and others return 404. Treat both as "this ID is not valid for this key and environment." A common cause is using a live ID with a test key, or the other way around.

Error payloads

Most errors have a type and an errors field:

• type: a machine-readable error category. See the table below.
• errors: a human-readable message, or, for field validation errors, an object mapping each field to a list of problems.

Some endpoints and situations use a different shape. To handle every case, check the HTTP status first. Then read errors, message, or detail, whichever is present.

{
  "type": "invalid_request_error",
  "errors": "Invalid decision tree ID"
}

{
  "type": "invalid_request_error",
  "errors": {
    "params": ["This field is required."]
  }
}

{
  "message": "Insufficient data. Missing fields: email"
}

Handling tips

1. Branch on the HTTP status first, then read the error body. Don't rely on one error shape.
2. Retry only what can succeed later. Retry 429 and 500 with backoff. Don't retry 400, 401, 403, 404 or 415 without changing the request.
3. Log the error body (without your API key) so support can help you quickly.
4. Match IDs to the environment. Sandbox IDs don't exist in Production. A test key can't see live records, and a live key can't see test records.

Paging and rate limits

Pagination

List endpoints, such as List all Decisions, List all Pricing Engines and List all Sub Tenants, use offset pagination with two query parameters:

These endpoints return results newest first. The response's has_more field is true when more items exist after this page.

curl "https://app.lendapi.com/api/v1/decisions/?start=20&size=20" \
  -H "Authorization: Bearer test_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

To read every item, start at start=0 and keep adding size to start until has_more is false. If start or size isn't a valid integer, the request fails with 400.

Rate limits

API requests are rate-limited per tenant. The limit is shared by all of your tenant's API keys. When you go over it, LendAPI returns 429 with this body:

{
  "error": "too_many_requests",
  "message": "Rate limit exceeded. Try again later."
}

When you receive a 429:

1. Pause before retrying. Wait a few seconds, and back off further if you get 429 again.
2. Spread bulk jobs out instead of sending them all at once.
3. Contact LendAPI if your normal traffic needs a higher limit.

Related guides