The Spinwheel API gives you user-permissioned credit data you can act on.
A user consents and verifies their identity — that's Connect. Their Debt Profile comes back with the credit report and every Liability on it. Each Liability is then individually addressable: refresh a balance live from the institution, request a payoff quote, make a payment.
REST over HTTPS, JSON in and JSON out. Every path is prefixed /v1:
POST https://sandbox-api.spinwheel.io/v1/users/connect/smsThe response envelope
Every response, success or failure, has the same two keys:
{
"status": {
"code": 400,
"desc": "FAILED_ELIGIBILITY",
"messages": [{ "desc": "User failed to meet eligibility requirements." }]
},
"data": { }
}data holds the result. On errors, status.desc is the machine-readable reason and status.messages[].desc is the human-readable one. Branch on status.desc alongside the HTTP status. Each endpoint's reference page lists what it returns.
Two statuses to watch
206 Partial Content is returned by Retrieve a User when the credit file is frozen, locked, fraud-flagged, referred or missing. Handle it as a partial result; status.messages says which condition applied.
429 rarely means you are sending too fast. Most are business rules — one credit report per user per day, five One-Time Passcode (OTP) attempts — that will not clear on backoff. See Rate Limits.
Order of operations
- Connect a user. Everything is scoped to a
userId, which only comes from a Connect flow: SMS, KBA, pre-verified or network token. - Order a Debt Profile.
POST /v1/users/USERID/debtProfilepulls the credit report and score and populates the user's Liabilities. Without it, a connected user has profile data only. - Act on Liabilities. Real-time balances, APR refreshes, payoff quotes and payments all operate per Liability.
Next
- API Authentication — your key and how to send it
- API Environments — sandbox, production and the secure hosts
- Rate Limits — what returns a 429
- Glossary — bureau codes and Spinwheel terms