Two ways to launch capital
in your product, both fast.
Drop in one component, or build every screen yourself on the API. Both are white label. Both run on the same engine.
Integrate this afternoon.
Drop in one element and mint a token for the customer, or make a single API call. Either way the offer, the application, the money and every payment after it already work. You are only deciding where they sit in your product.
The whole product, in one element
<slate-capital env="live" user-token="{token}"></slate-capital>That is the integration.
It renders the offer, the application, the money and every payment after it, and it picks its own state, so the same embed covers a customer with no offer and a customer nine payments in.
The two lines around it
Once, on the page
<script async type="module" src="https://components.tryslatehq.com/slate.esm.js"></script>And a token for the customer, minted on your server
const { token } = await fetch(
'https://api.tryslatehq.com/user-session-token',
{
method: 'POST',
headers: { 'x-api-key': process.env.SLATE_API_KEY },
body: JSON.stringify({ externalId: 'cus_123' }),
},
).then((r) => r.json())$50,000 available to draw
Terms are set. Draw what you need, when you need it.
Capital
ACTIVERemaining
$10,781
Next payment 15 Feb
Upcoming payments
Recent payments
Your customers get the money.You ship one line.
The offer, the application, the money and every payment after it, inside your product. Underwriting, compliance, money movement and servicing stay on our side.
<slate-capital env="live" user-token="{token}"></slate-capital>The same element, in whatever state that customer is in.
$50,000 to draw
$10,781
Next payment 15 Feb
Upcoming
$50,000 available to draw
Terms are set. Draw what you need, when you need it.
Capital
ACTIVERemaining
$10,781
Next payment 15 Feb
Upcoming payments
Recent payments
Your customers never see us.
One component, your theme. Set it once and every offer looks like something you built. Or build on the API and skip the theming altogether: none of it is ours to begin with, so every screen is yours from the first pixel.
Preview
$12,400 available
Bridges Friday’s payroll while March receivables are still clearing.
A feature, not a mailer
It sits in the flow, beside the number that prompted it.
No application
No form, no upload, no credit pull. The amount is set.
How much do you want to own?
You can start on one and move to the other.
Ready to launch
One component, the whole journey.
Drop it in and your customers see the offer, apply, take the money and manage what they owe without leaving your product. You set the logo, the name and the colours in the dashboard.
- Every state, from no offer to paid off
- Your logo, name and colours
Build on the API
Every screen yours, same engine.
Create customers, attach the data you already have, read who is approved, open applications and follow agreements. Only who draws the pixels changes.
- Typed SDK, or plain REST
- Every screen and every word yours
Whichever you pick, none of it stops being yours.
The two routes differ in how much of the screen you draw. Nothing else about it changes hands.
Your brand
Logo, name, and the colours for the application and the offer banner, set in the dashboard.
Your domain
Approved, funded and paid go out from a domain you own, so nothing arrives from us.
Your call to action
Turn our dialogs off and the button, the copy and the flow around it are yours.
Your keys and your team
Sandbox and live, API keys, webhook endpoints, and who can see what.
First-class developer experience.
We are a small team that has integrated a lot of other people’s financial APIs.
This is the one we wanted to find.
Or let an agent write it
It scans your codebase, writes the integration and opens a pull request. Nothing touches your main branch until you merge it.
install.slate.cxA sandbox you cannot break
Run your own customer data through the whole flow. The client points here until you change one line, so nothing real moves by accident.
Open the sandboxYou always know what happened
More than thirty events, signed with HMAC so you can prove they came from us, and retried when your server is down.
Every event, and how to verify oneFAQ
We do. Every advance is funded in full through facilities we manage, and the credit risk sits with us, so it never reaches your balance sheet and you carry no credit exposure. Collections are ours too: when someone cannot pay, our team makes the call and works out the plan, and your support queue never sees it.
Bring an engineer to the first call.
We will run your own data through the sandbox and show you what comes back before you commit to anything.