Support

Overview

Credlab exposes two complementary ways to get applicant/credit-decision data out of the system:

• Webhooks — a Credlab staff member reviews a decided credit application and clicks Send to <your endpoint> on its dashboard, which pushes a thin notification to a URL you host. This is the primary, low-latency integration path: your system reacts as soon as staff push a decision, and resending after a correction is a normal, expected occurrence.
• Read API — a REST endpoint you can call on demand to fetch a single application or list/filter applications. Use this to fetch the full record a webhook notification points you at, for initial backfills, and as a reconciliation mechanism to catch any decisions your webhook receiver might have missed (network outage, deploy window, etc.).

In a typical integration, you configure a webhook endpoint to receive credit_application.decided notifications as staff send them, fetch the full application from the read API using the id the notification contains, and periodically poll the read API (filtered by decided_since) as a safety net to guarantee no decision is ever lost.

Authentication

Every API request is authenticated with a personal API token, scoped to the account(s) the token’s owner belongs to.

Setup (done by a Credlab account admin, once):

1. An account admin creates a dedicated user for the integration (e.g. netsuite-integration@yourcompany.com) — a service account, rather than a real person’s login, so the credential’s lifecycle is independent of any employee and API activity is clearly attributable to the integration. Add it to the relevant account as an account admin. This admin role is only to satisfy the token-management screen, which is admin-only — it grants the integration no extra API access. The read API scopes every request to the accounts the token’s user belongs to; account-admin versus regular-member makes no difference to what the token can read.
2. That user signs in and opens Settings → API Tokens (or visits https://credlab.app/api_tokens directly) to create an API token, then opens the token’s page to view and copy its value.
3. The generated token is a long-lived credential — treat it like a password. It can be viewed again on that page at any time, and revoked from there when no longer needed.

Making requests:

Every request must include two things:

• An Authorization header of the form:

  Authorization: token <token>
  

• An account_id parameter identifying which account to operate on (an account-prefixed id, e.g. acct_1a2b3c4d5e6f). The authenticated user must belong to that account — tokens are not account-scoped on their own, so account_id is required on every read-API call.

Authentication errors:

Condition	Status	Body
Missing or invalid Authorization token	401 Unauthorized	empty body
Missing account_id, or account_id for an account the token’s user does not belong to	422 Unprocessable Content	{"error": "account_id is required and must be an account you belong to"}