When platform engineering teams evaluate embedded credit infrastructure, the integration timeline question comes up in the first conversation. Two weeks sounds aggressive. For the teams that have done it, it is realistic when the API surface is well-designed and the documentation covers what developers actually need to know, not what the product team wants them to know.
This post is written for the engineers who will actually do the integration work. It covers the Lendforge API surface, the data flow from application to decision, the webhook patterns you will depend on, and the implementation decisions that most documentation leaves ambiguous. If your product team has already decided to integrate Lendforge, this is the reading that saves you the first week of discovery work.
The Three Core Endpoints
The Lendforge integration surface is intentionally small. There are three core endpoints that handle the vast majority of what you need for a live checkout integration.
The first is POST /v1/applications. This endpoint initiates a credit application. You pass the applicant's identity fields (name, date of birth, SSN last four or full SSN depending on your product configuration), the requested credit amount, and your platform's user identifier. If you are using platform behavioral data to augment underwriting, you also pass a platform_context object containing the user's transaction summary or a reference to a pre-ingested event batch. The response is synchronous for most configurations: you receive a decision object with a status of approved, declined, or referred. Decision latency at P95 is under 400ms for standard configurations; with pre-ingested platform data the model runs in parallel with bureau query so total latency does not increase proportionally.
The second is POST /v1/events. This is the platform data ingestion endpoint. You call this to send transaction events for a user, either in batch ahead of an anticipated application or in real time as transactions occur. You do not have to call it at all if you choose to send platform context inline with the application request, but the batch-ahead pattern is more reliable for users with longer platform history because it avoids hitting request size limits. The event schema is documented in the Lendforge developer portal; the short version is timestamp, amount, merchant category code, and transaction outcome per event.
The third is POST /v1/disbursements. Once you have an approved application and the user has accepted the terms, you call this to trigger loan origination and fund disbursement. Depending on your bank partner configuration, funds move to the merchant account or are applied as a checkout credit immediately. The response includes a loan identifier that becomes the reference for all subsequent repayment tracking.
Webhook Design: Where Most Integrations Break
The synchronous application response handles the happy path. Webhooks handle everything else, and this is where most integration issues occur.
Lendforge sends webhooks for four event classes: application.updated (status changes after initial decision), loan.disbursed (funds moved), repayment.received (payment processed), and loan.delinquent (payment missed, with a day-past-due count). Your webhook endpoint needs to handle all four, but in the first two weeks of integration you care primarily about application.updated and loan.disbursed.
The part the documentation does not emphasize enough: webhook delivery is at-least-once, not exactly-once. You will receive duplicate events, especially under retry conditions after a temporary endpoint failure. Your handler needs to be idempotent: receiving the same application.updated event twice should not produce two state transitions in your database. The event_id field on every webhook payload is stable across retries. Store it and check for duplicates before processing.
Webhook signature verification uses HMAC-SHA256 against a shared secret you set in the Lendforge dashboard. Do not skip this in staging even if it feels like overhead. The pattern trips up teams when they move to production and realize their endpoint is accepting unauthenticated payloads. The verification code is three lines in most languages; the Lendforge documentation has SDK-level helpers if you prefer not to write it yourself.
The Referred Decision and Manual Review
A referred application status means the model scored the applicant in a range where it cannot make an automated decision with sufficient confidence. This is not a decline; it is a hold for review. How you handle this depends on your product configuration.
If you are running Lendforge in fully-automated mode, the referred population gets a pending message and the application goes into a manual review queue on the Lendforge side. The outcome typically resolves within two business hours. Your platform should display a "decision pending" state and listen for the application.updated webhook that will carry the final decision.
If your compliance configuration requires that you review referred applications yourself before they proceed, you can configure a "manual review required" webhook routing that sends referred applications to your own review queue. This is common for platforms in regulated verticals or platforms that want to maintain closer oversight of the decline population. It adds operational overhead but gives you more control over the final decision distribution.
One implementation detail: your checkout UI needs to handle the pending state gracefully. If a user submits an application and gets a referred decision, they need a clear message that their application is being reviewed, a realistic time estimate, and a way to continue shopping or return to a different payment method without losing their cart state. This is not a Lendforge problem; it is a platform UI problem that teams consistently underestimate during scoping.
Testing in Sandbox Mode
The Lendforge sandbox is a full-featured replica of the production environment with synthetic data generation for all decision outcomes. You get deterministic decision results by setting specific test SSN values documented in the developer portal: one SSN range triggers automatic approvals, another triggers declines, and a third triggers referred outcomes. This lets you test all three branches of your UI without mocking at the application layer.
One thing to test explicitly that teams often miss: the behavior of your checkout flow when the Lendforge API returns a non-200 status. Rate limits, temporary service unavailability, and malformed request errors all return 4xx or 5xx responses. Your integration needs a defined fallback: show a generic error message and offer the user an alternative payment method. If you do not test this path in sandbox, you will encounter it for the first time in production during a traffic spike or deployment issue.
The sandbox also accepts live-format webhook payloads to your configured test endpoint. Run a full end-to-end test including webhook processing before you declare the integration complete. The webhook path is the one most likely to have bugs that are not visible from the API response alone.
The Two-Week Timeline in Practice
Here is roughly how the two weeks break down for a typical platform engineering team of two developers.
Days one and two: read the full API documentation, set up sandbox credentials, make your first test application call and verify the response structure. Wire up the webhook endpoint and verify signature verification. This is setup and orientation, not real integration work yet.
Days three through five: implement the application submission flow connected to your checkout UI. Handle synchronous approve and decline responses. Display the right UI state for each. This is the highest-visibility work and should go quickly since it is straightforward request-response logic.
Days six through nine: implement the pending state and application.updated webhook handler. Test referred-decision scenarios thoroughly. Add idempotency handling to your webhook processor. This is the part that takes longer than developers expect because the async state management is more complex than the synchronous happy path.
Days ten through twelve: wire up the disbursement call, test end-to-end with a sandbox approved application through to disbursement, run error scenario tests. Day thirteen: internal QA with the product team, fix any UI edge cases. Day fourteen: production credentials, real-environment smoke test, launch or schedule the rollout.
This timeline assumes your platform already has identity verification in place and that you are not simultaneously building income verification infrastructure. If you need to add document upload or income verification on your side, that is a separate workstream that runs in parallel with the Lendforge integration, not a dependency of it.
What Not to Build
The teams that overshoot the two-week timeline are usually the ones who try to build too much custom logic around the Lendforge API during the integration. Common examples: custom retry logic that duplicates Lendforge's built-in retries, custom webhook validation beyond HMAC verification, and custom decision routing logic that reimplements rules the model already handles.
The Lendforge API is designed to handle credit logic. Your platform's job is to collect the applicant's intent, pass it to Lendforge, display the result, and trigger the disbursement when the user accepts. Staying close to that scope in the first integration keeps the timeline realistic and avoids building surface area you will need to maintain long-term. You can always add platform-side customization after the baseline integration is live and you have real production data to learn from.