Idempotency: why one application must never reach a lender twice

The problem nobody plans for

A platform sends an application, but no response comes back — the connection dropped, the server answered too slowly or the user clicked the button again. The natural reaction is to try again. But what if the first request actually succeeded?

Without protection, the lender receives two identical applications. For the customer that can mean a double credit check, two calls from the lender or confusing duplicate offers. For the platform it means awkward clean-up and an unhappy partner.

What idempotency means

A request is idempotent if it can be repeated any number of times while the result stays the same as after the first one. To achieve that, every application needs a unique identifier assigned by the platform itself — for example, its own internal application number.

How it works in Apifly

In every request the platform includes its own application identifier, client_submission_id:

POST /api/submissions

{
  "client_submission_id": "app-10482",
  "lender_codes": ["lender-a", "lender-b"],
  "applicant": { ... },
  "application": { "amount": 3000, "term_months": 24 }
}

• The first time an application arrives, Apifly stores it, sends it to the selected lenders and responds with 202 Accepted.
• If the same client_submission_id arrives again, Apifly returns the stored application with 200 OK and does not send it to the lenders again.

So the status code alone tells you whether the application was just accepted or already known, and you can safely retry after any network error.

The same principle on the way back

Lenders also tend to send the same response more than once. Apifly filters out identical repeated responses, so they neither change the state of the application nor trigger extra notifications to your system. In turn, every webhook notification carries a stable event_id, so duplicates can be recognised on your side as well.

The takeaway

Idempotency is not an extra feature but a baseline requirement for any integration that deals with money and personal data. It is worth building once in the connector rather than separately in every integration with every lender.