Engineering tickets titled “lending API” often mean “we want offers in our UI.” That is a core-banking project. What most product teams actually need is to send a logged-in business user into a complete application, keep attribution, and get paid if a lender funds. Those are different specs. Confusing them burns a quarter.
Loanable does not provide a public REST API that underwrites, prices, or books loans. Embedded solutions are a Loanable-branded or co-branded apply flow with partner attribution on your unique partner link. Loanable is not a lender. The file is matched to 150+ lenders. Funded deals pay 50/50 of Loanable profit, Monday ACH, no minimum. If your architecture diagram shows POST /offers, it does not describe this partnership.
When an apply flow is the correct “API”
When you need coverage across products, not a single credit box you control. When you cannot hold paper. When you should not tell users you approved them. When you can open a browser or webview. That is most SaaS, POS, and CRM vendors. A true decisioning API is for companies building a licensed lending program with their own capital or a bank partner who actually issued credentials. Do not invent those credentials in a pitch deck.
- Attributed URL instead of a tokenized offer object
- User-completed application instead of silent bureau pulls you do not run
- Marketplace matching instead of a single-box response
- Dashboard plus Monday ACH instead of webhook folklore
What you can still automate
You can automate the click, the deep link, the product type query, and the internal logging that a user started funding. You cannot automate a Loanable approval you never received. Working capital may fund as soon as 24 hours after a complete file; that still happens on the lender’s side. Large facilities up to $50M will not return from a JSON endpoint this week.
Rewrite the ticket before you staff it
Change “build lending API client” to “ship tracked apply flow and verify dashboard.” That staffing plan matches the product. If a future private integration exists, it will not be something this article should invent. Today’s honest embedded path is the application with your code on it.
Rewrite the architecture diagram in one meeting
Replace the box labeled Lending API with a box labeled Apply URL plus ref. Replace webhooks-from-underwriting with dashboard review. Replace offer objects with “user completed application.” If leadership wanted the first diagram, they wanted a bank program. If they wanted capital in-product this quarter, they wanted the second. Loanable embedded solutions are the second.
Leave a footnote that a public REST lending API is not available, so nobody resurrects the first diagram in a future sprint. 150+ lenders, 50/50 of profit, Monday ACH, as-soon-as-24-hour working capital, facilities up to $50M — all of that happens after unique partner link is used. None of it happens after a JSON POST you invented in Lucidchart.
Stop waiting on an API that is not the product. See Loanable embedded solutions and implement unique partner link as the integration, not a fictional REST underwriting layer.