Skip to content
WorkspaceDarkLight
Contents

Changelog

What changed

Every change to /v1, newest first.

How versions work

There is one version, /v1. Every /v1 answer carries Creditcrest-Version, the date of the newest entry here: now 2026-11-09. Log it, and when it changes, read down to the date you last read.

A new endpoint, a new field in an answer, a new optional field in a request and a new value of a field are additions: read answers so that a field or value you do not know is passed over. A change that could stop working code — a field removed, renamed or newly required — is marked Breaking.

  1. Signing up before applying, and an application filled in from it

    A lender may let people make an account before it takes applications: a name, an email and a mobile, each confirmed with a code, on its hosted pages. POST /v1/l/{tenant}/applications/prefill gives a lender’s own form what to fill in once the applicant has proved both contacts: the name a sign-up saved, or a returning customer’s details from their last application, and found: false for anyone else. GET /v1/l/{tenant}/sign-ups lists the people who said yes to the lender’s marketing emails, with the version of the question and when it was answered. Nothing else changed.

  2. Creditcrest Score 3.0: a model borrower for each loan type, starting at 800

    A rating is the gap between the applicant and the model borrower, laid on its rating: it starts at 800, 150 points is ten times the odds, and there is no upper or lower limit. Each loan type (small, medium, personal, secured, car, business) has its own model borrower, with a profile shared across lenders as figures only, never mixed with another type; each lender’s copy keeps its own rating, moved by its own closed loans. A lender adds its outcomes to the shared profile only once it agrees. New records carry ratingScale "800/150"; older ones, at 1500 and 400, keep their classes and are read on the new scale. Send loanType to /v1/score and /v1/score/model-borrower. The model borrower’s repaidAt1500 is now repaidAtBase.

  3. Creditcrest Contracts

    Write a contract once as a template, fill it in, have every party sign it with Creditcrest Sign and keep it, with its history, its end date and its renewal, in your own records and your own name. Under /v1/l/{tenant}/contracts and /v1/l/{tenant}/contract-templates; GET /v1/contracts says what it does. New webhooks: agreement.sent, agreement.signed, agreement.completed, agreement.declined and agreement.withdrawn. $1.65 a completed contract, however many sign it.

    1 endpoint

  4. Statement reads more merchants: a register of web addresses, words for places to eat, and more of the bank’s own wording

    A card line no rule reads that carries a business’s own web address ("ETSY.COM*AU") is now read from Wikidata’s register of notable businesses’ websites (CC0): the `listed` band, its `evidence.place` `{ name, domain, register: 'Wikidata' }`, money out only and never under `strict`. Banks, lenders, payment platforms, gambling and anything that is two things a payment could be are left out of it. About 110 words that name a place to eat in nearly every Australian place that carries them (LAKSA, SHAWARMA, BIRYANI) read as eating out, in the `kind` band; GROCER and GROCERS as groceries. An app bank’s automatic covers and forwards between savers are transfers, and interest it writes twice is interest. A line that names the holder among a payment’s words is their own money moving (`own_account`) unless another person is named as the payee, and an application’s statement file passes its holders’ names to the reader. "AUD 7-ELEVEN" keeps its 7.

  5. Each policy test not passed, in the policy’s own words, with what it found

    An application’s policy record (a case’s `creditcrest.policy`, GET /v1/l/{tenant}/cases/{ref}) now keeps `reasons`: each condition not met and each referral, with its `id`, its `kind` (`rule` or `refer`), the `condition` as the policy wrote it, what was `found`, written as the policy writes figures (`1`, `$150`, `4.5%`; each part of a compound test named), and `provisional` where it read the surplus worked out at arrival. A Creditcrest Statement opened from the application lists them under the policy’s counts, closed until opened. Records made before keep their tests’ names alone.

  6. Each lender’s own split of essential and discretionary spending

    A lender may set which spending its policy counts as discretionary (its settings, `operations.discretionary`: any of groceries, utilities, phone and internet, insurance, transport, health, education and childcare, eating out, shopping, entertainment and travel; rent, strata, bank fees and government charges are always essential). Unset, Creditcrest’s own: eating out, shopping, entertainment and travel. A reading’s `expenses.monthly` and `expenses.byCategory[].group` follow it, and say so in `expenses.discretionary`; a bank statement’s analysis (1.3) records it in `analysis.split`, groups its categories by it, and adds EX25 discretionary beside EX24 essentials; EX20 and EX21 keep their fixed categories. The statement’s page puts Creditcrest’s Score, policy, suggestion and holder check in a band across the top, calls each thing to look at a red flag, headlines only the figures that say something, and links every line in its categories to the same line in its transactions.

  7. Overdrawn fees apart from dishonours; external transfers; a statement that reads newest first

    A bank statement’s analysis (1.2) counts dishonours as payments refused alone, and overdrawn fees as figures of their own: RL23 to RL25, each account’s `overdrawnFees`, a reading’s `recent.days30.overdrawnFees` and `recent.days90.overdrawnFees`, the signal `overdrawn_fees`, and Decisioning’s new fields `overdrawn fees in the last 30 days` and `overdrawn fees in the last 90 days`. Decisioning’s `dishonours in the last 30 days` and `dishonours in the last 90 days` no longer count overdrawn fees. A payment to or from another person (`person`) is now an external transfer, in the transfer group, and like the transfers is left out of spending: a reading’s `outgoings.excludes` names `transfer` and `person`, and EX16 gives external transfers a month beside EX22, not in it. New figures EX23 commitments and EX24 essentials: with EX21, RL08, EX15 and EX17 they add up to EX22. New indications, each a share of income: RL26 gambling, RL27 cash withdrawn within 5 days of income, RL28 external transfers, RL29 cash and external transfers. The page opens on where a month’s regular income goes, as a waterfall, and at most five things to look at, one line for each kind; each income source and credit provider is one line with its calendar and its transactions; spending in conduct is two lines; every list runs newest first. Each bank is shown with its own logo from the open-banking register, and a lender’s logo is on its staff pages and heads the PDFs it hands its borrowers. GET /v1/statement/document/sample takes two more invented applicants, `example=strong` and `example=steady`.

  8. A seal is checked only against a key the server holds by that name

    POST /v1/sign/verify, POST /v1/sign/evidence and a signing link now find a seal’s key only among the keys the server was given, by exactly the name the seal gives. Before, a seal could name its key so that the check found something that was not a key at all, and a seal made that way could pass. Evidence and links sealed with Creditcrest’s own keys are unchanged and still check.

  9. Each dishonour tied to the payment it refused; cash a group of its own; a lender’s logo

    A bank statement’s analysis (1.1) lists each dishonour once — the debit, the money coming back and the fee are one, where they had been up to three — and each overdrawn fee, with the payment it was and how that was found (analysis.dishonours: returned, named, due or overdrew), the payment that went out after it, and each credit provider’s dishonours. RL01 to RL03 and Decisioning’s dishonour fields count the same. New figures: RL19 repayments to credit providers dishonoured, RL20 cash in the last 30 days, RL21 and RL22 cash withdrawn within three days of pay, a month and as a share of that pay. Cash withdrawals are a group of the taxonomy of their own (`cash`, where they were `unknown`), so a reading’s expenses gain `cash`. A transfer between the holder’s own accounts is marked (detail `own_account`) and names the other account; any other transfer names its other side. Each account gives its median day-end balance and the income paid into it. A lender’s brand takes a logo (`brand.logo`, set on its settings page), shown on its pages, its messages and the statements it is given, now titled Creditcrest Statement.

  10. The bank statement says what a credit assessor needs

    A bank statement made with Creditcrest’s reading (standard version 1.1) now carries its analysis, sealed with it: more than 70 figures, each with a reference (IN01 regular income, RL02 dishonours in the last 90 days, LI09 repayments due in the next 30 days, PO01 surplus …) and the Decisioning field that reads the same figure; every income stream and every credit provider with a status — ongoing, skipped, stopped or irregular — and its next date; when a loan may end, where the loan paid in is on the statement; dishonours and days below zero over 30 days, 90 days and the period; and each category’s parties. Each transaction carries the party Creditcrest named and what its words settle (a dishonour, a small-amount lender, which benefit). The page leads with the figures and the things to look at, draws the balance at the end of every day and each stream on a calendar, opens each category onto its parties and their transactions, and searches, filters and sorts the transactions two ways. A PDF statement now gives the holder, their address, the bank, the BSB and the account number from the page above its transactions, and a statement of several accounts is several accounts.

  11. Creditcrest bank statement: one standard for every source

    POST /v1/statement/document makes a bank statement in Creditcrest’s own standard from whatever the data came as: a statement file, banking data in the Consumer Data Right’s shape (as an open-banking provider passes it through), illion’s raw data file, or accounts in the standard’s open input. The answer is the same JSON whichever it was: who holds the accounts, each account’s bank, BSB and last four digits, its opening, closing and available balances, money in and out month by month, every transaction with the balance after it, the checks the statement allows, and a seal, HMAC-SHA256 with its SHA-256 beside it. format=html gives it as a page to read, print or keep, with the JSON inside it. POST /v1/statement/document/verify says whether one is as Creditcrest made it, POST /v1/statement/document/render draws a kept one again, and GET /v1/statement/document/schema is the standard as JSON Schema. Priced as a statement read; checking and drawing are free. On the hosted pages a statement is now made each time a bank is connected or one is added on the Banking tab, and kept in the lender’s own records beside the reading.

  12. An app’s split of a payment is the holder’s own money

    A line written as a saver’s name and a share, “Essentials (40%)”, is an app moving part of a payment into a saver, and is read as a transfer. The share arriving in the saver the same day for the same amount, under whatever name it carries (often the bank the payment came from), is read as a transfer beside it, where it was read as income before. Both are in a new confidence band, paired, and the evidence’s matched names the split. A year’s statement of several accounts no longer dates the second account’s June a year early.

  13. Creditcrest Extract, with a page to try it on

    POST /v1/statement/extract is now Creditcrest Extract, part of Statement and priced as a statement read, with a page at /extract that reads an invented file of each kind, or your own, and keeps nothing. A file that prints no balance beside its rows (OFX, QFX, QBO, QIF, MT940, camt) now answers checks.balanceChain as null, where it counted balances its reader had added up itself; and a QIF file, which states no closing balance, answers checks.reconciles as null.

  14. Scanned statements are read by text recognition

    A scanned statement, a PDF whose pages are pictures with no text in them, is now read rather than refused: each page is read by text recognition that runs where the reader runs, nothing sent anywhere, and then read as any PDF, with its printed balances checked against the rows. Pictures in JPEG, in fax compression (Group 3 and Group 4) or uncompressed are read; up to 40 pages of one statement. The reading starts with a warning that it was a scan, and POST /v1/statement/extract adds recognition: the pages read that way, the words read and how surely.

  15. Statements as PDFs, workbooks and accounting files, and the reader on its own

    POST /v1/statement, the Statement and Enrich pages and the console now read a statement as whatever file it is: the PDF statement a bank issues (encrypted or not; a password-locked one with its password), an Excel workbook (.xlsx or .xls), an OpenDocument spreadsheet, OFX, QFX or QBO (Quicken, QuickBooks, MYOB, Xero), QIF, SWIFT MT940 and ISO 20022 camt.053, as well as CSV. Send the file as the body with its own content type, as a multipart "file", or as base64 in JSON {file}. A PDF’s table is worked out from where its words sit and checked against its own printed balances. POST /v1/statement/extract returns the transactions alone, with the period, the opening and closing balances and whether the statement’s arithmetic agrees with what was read, for a program with categories of its own.

  16. A complete setting: every line a category, and accuracy over all lines

    setting=complete reads as broad and then gives every line nothing read a category: the model’s most likely spending line for money out, a transfer for money in, in a new confidence band, guessed, with evidence.guess saying how (model or direction) and the model’s probability. A guess never says income, a commitment, gambling or a transfer out. It is for comparing Statement with services that categorise every line; it is never the default and has no precision floor. GET /v1/statement/accuracy now carries recall, the share of all lines read right, for every setting and set: accuracy over all lines, the figure such services quote.

  17. Statement and Enrich read a card line from a register of Australian places

    Where no rule reads a card line and no bank code settles it, Statement and Enrich now look its words up in a register of 724,000 Australian places (Overture Maps), matched with the suburb the line names by that suburb’s postcodes (G-NAF). Where every place that matches is the same kind of business, the line is read as it, in a new confidence band, listed, and the business is the third party (third_party.basis register); evidence.place gives its name, postcode and how many places matched. A name two places disagree about, a common word without its suburb in full, and a line whose own words point elsewhere are left unread. Balanced and broad only, money out only, and asked before the model. Measured on the payee registers: 63 of 63 right.

  18. Statement and Enrich read the code your bank connection sends

    Where an applicant connects their bank, the bank can send beside each description the merchant’s name, the card scheme’s merchant category code, the Consumer Data Right’s type for the line and a BPAY biller’s code; Statement now keeps them. Where no rule reads the words, a code that settles the line reads it, in a new confidence band, coded, and the merchant’s name is the third party (third_party.basis bank); evidence.bank says which code and what it is. A code whose businesses fall on different lines, such as a convenience store’s, reads nothing, and a name a rule knows keeps its own reading. Not under strict. POST /v1/enrich takes the same fields on each transaction as bank, and a statement file takes them in columns named Transaction type, Merchant, Merchant category code, BPAY biller code and BPAY biller. A coded reading is not yet measured on labelled statements, and its confidence, 0.9, says so.

  19. Service a loan from your own staff console

    POST /v1/l/:tenant/loans/:loanRef/actions takes every action LoanManager’s loan page takes — a payment, a settlement, a dishonour, a fee, a waiver, a refund, a hardship notice or decision, an arrangement ended, a write-off, a payout statement — by the same function: the same checks, the same ledger, the same webhooks. by is the work email of the person it is recorded as, active on your staff list, and their role there decides what they may do. lastSeq and requestsSeq are the loan’s as you read it: a change made since is a 409 conflict, never written over, so a call sent again is never recorded twice, and under the same Idempotency-Key it answers what it first posted. It answers the events posted and the loan as GET /v1/l/:tenant/loans/:loanRef does, and a payout statement the statement. GET /v1/l/:tenant/loans/:loanRef/actions says which actions are open on the loan now, who may take each, and the fields each takes. A field an action does not take is refused, not dropped. Not charged: servicing is in the take-rate on each advance.

  20. Bank connections for your own application form

    A lender with its own form connects the applicant’s bank through the API. POST /v1/l/:tenant/bank-connections takes the applicant’s name and email and a returnUrl on your own site, and answers with a url to send them to; they agree at their bank and come back to returnUrl with connection and status (ready or failed), and nothing personal. GET /v1/l/:tenant/bank-connections/:id says where it stands, with a summary once read: the accounts, the transactions and days they cover, and whether the account holder’s name matches. POST /v1/l/:tenant/applications takes statement: {connection}: the statement is read and kept exactly as on the hosted pages, the bank data consent given at the bank recorded with it. A connection is used once, before it expires, by whoever made it: the lender with any of its own keys, or the one sandbox key. It is part of Statement, and never charged on its own. Two new error codes: no_bank_connection and bank_unavailable.

  21. Your own console: the queue, the case file and every action, through the API

    For a lender with its own staff console. GET /v1/l/:tenant/cases is the work queue as the operations console shows it, and GET /v1/l/:tenant/cases/:ref the case file as data. POST /v1/l/:tenant/cases/:ref/actions takes every action a person takes in the console — take, verify, the ledger, the checklist, documents, notes, a statement, a credit enquiry, a conclusion, a second check, the contract, funding and payment — with by, the work email of the person on your staff list who did it. Their role on the list decides what they may do, by the console’s own rules, and the event names them. Send seq to refuse a change to a file that moved on, and an Idempotency-Key to have a retry done once. POST /v1/l/:tenant/cases/close-automated closes many files as automated submissions at once. GET and POST /v1/l/:tenant/staff keep the staff list itself, by an operations admin on it and by the Staff page’s rules. Your form proves the applicant’s email and mobile with POST /v1/identity/contact/start and …/check, and sends both tokens with the application, so the applicant is recorded as your customer and can sign the contract in their account. Billed as the console is: an outcome that stands, once per application; no call is charged on its own.

  22. The suites renamed, two products renamed, Operations in the Decisioning Suite, and loans by what the borrower asked for

    The four suites are now the Origination Suite, the Decisioning Suite, the Servicing Suite and the Compliance Suite (they were Creditcrest Originate, Decide, Service and Comply), and Operations is part of the Decisioning Suite rather than the Servicing Suite. No address, field or price line changed: the suites keep their keys (originate, decide, service, comply), Operations is still $0.15 a decision, and the Decisioning Suite’s per-decision total is now $2.15. Two products whose names repeated their suite’s are renamed: Creditcrest Decisioning is now Creditcrest Policy Engine, and Creditcrest Compliance is now Creditcrest Controls. Their keys and paths are unchanged (decisioning and compliance; /v1/decisioning/… and /v1/compliance), no price changed, and the one field that carried a name, GET /v1/compliance’s service, now says Creditcrest Controls. GET /v1/l/:tenant/loans takes asked, the staff list’s "Borrower asked for" filter: asked=statement lists the loans with a payout statement still owed, asked=complaint those with a complaint on file. It is applied as the staff list applies it, filters echoes it (an empty string when it is not given), and a value not on the list is left out and said in could_not_read.

  23. Price list version 4: lower prices for small lenders

    From 1 November 2026: $2.95 a decision for every service, and 0.85% of the first $5,000 of each advance, 0.36% to $50,000 and 0.036% above. An ID check is $1.10, a sanctions screen $0.55, a credit enquiry run $0.55, an advance paid $2.95, a PayTo agreement and a repayment collected $1.10 each. It replaces versions 2 and 3 before either took effect: the volume discounts stay, and version 3’s rises are withdrawn. GET /v1/usage and every invoice price each month at the list in force that month. /estimate says the list it used.

  24. Price list versions 2 and 3: volume discounts, and the month’s totals first

    GET /v1/usage answers volume (the month’s service fees, the discount taken off them and its tiers) and summary (per decision and API, on advances, checks, discounts, the total and the cost per funded loan). From 1 November 2026 a month’s service fees are 15% off from $25,000 to $100,000 and 30% off above. Version 3 would have raised Statement to $2.45 and the $5,000 to $50,000 band to 0.40% from 1 February 2027; version 4 withdrew it before it took effect.

  25. The month so far, and a spend alert

    GET /v1/usage answers spend: monthToDate, the month’s total so far; estimate, a straight line to the end of the current month in Sydney (null for any other month); alert, your spend alert in whole dollars, GST included, or null; reached, the highest of 0.5, 0.8 and 1 of the alert the month has reached, or null; and problems, anything wrong with how the alert is set, which never holds an invoice. With an alert set, its address is emailed at 50%, 80% and 100%, once each a month, and the console shows the same. Nothing is ever stopped by it. Set the amount and the address yourself, in your console’s Settings.

  26. Webhooks

    Creditcrest tells your own systems when something happens: an application submitted, decided or withdrawn, a contract signed, a loan funded, a repayment collected or failed, hardship asked for or arranged, a complaint received, the daily run done. Each notice is signed (Creditcrest-Signature, HMAC-SHA256 over the timestamp and the body), carries ids and what changed and never a borrower’s details, and is tried again for 72 hours. Test endpoints get sandbox records, live endpoints real ones. See /developers/webhooks.

  27. One error shape, retries counted once, and every answer’s shape

    A product’s own refusal (ok: false and its problems) now carries the error envelope too: error refused, type, its first problem as the message, doc_url, and param where the product knows the field. Its own fields are kept; a program that told the two apart by error being missing should read ok: false. Any POST made with a key takes an Idempotency-Key: the same request within 24 hours runs again and is counted once, with Idempotent-Replayed: true; a different one is 409, a malformed key 400. /openapi.json describes every success’s fields. Enrich readings carry category.detail: which benefit, fee or lender.

  28. A setting for how far Statement and Enrich read

    Enrich, Statement and Capacity take setting: strict (the rules alone, as before), balanced (the default: a modelled reading is added where its category stays at 95% precision or better) or broad (90%). A GET takes it in the query; a POST in the JSON body or the query, the body winning. Any other value is a 400 bad_request. A line the model read rather than a rule is in a new confidence band, modelled, with its score, threshold and words under evidence.model. Every answer says which setting it was read under: setting on the answer, and on each transaction. POST /v1/shadow takes it too, and a hosted lender chooses its own on its settings page.

  29. Request IDs, error types and an OpenAPI document

    Every answer carries a Request-Id header, and every /v1 error carries it again as request_id, with a type that says what to do and a doc_url to its entry in the error reference. Nothing that was in an error is changed: error is still the code. A keyed call’s answer states its rate limit (RateLimit-Policy), and every /v1 answer names the newest entry on this page (Creditcrest-Version). The whole API is described as OpenAPI 3.1 at /openapi.json, and for coding assistants at /llms.txt, both drawn from the same catalogue as this reference.

  30. GST is never added on topBreaking

    The price is what you pay: GST is never added on top, and a month costs the sum of its lines. GET /v1/usage answers total (what is payable) and gstIncluded (the GST that total includes once Creditcrest is registered for GST; nought before) in place of subtotalExGst, gst and totalIncGst, and has no GST line. The entries below describe GST as they stood when they were written.

  31. Decisions and advances on your usage

    GET /v1/usage now prices each application decided on your hosted pages and each advance, its take-rate banded on its own amount, with Launch terms if you hold a place. GST is its own line once Creditcrest charges it.

  32. Usage, kept and priced

    Every keyed call and every check Creditcrest runs for you is now kept, not only logged. GET /v1/usage shows your month and what it comes to at the published prices, GST on its own line. Test, sandbox and refused calls are never charged.

    5 endpoints

  33. Credit reporting, run for the lender

    The month’s contribution as it would be sent, with its SHA-256 and the check before approval (POST /v1/credit-reporting/prepare), and the lender’s filings replayed from its own events — each one’s step, due day, overdue flag and approval, and its enquiry log (POST /v1/credit-reporting/obligations). The lender holds the agreement with each body; nothing is stored.

  34. Shadow mode

    Test Creditcrest on your own applications before going live. POST /v1/shadow takes up to 50 applications, each with your own decision, and gives back a sealed comparison for each — where Creditcrest’s reading agrees with you and where it parts, with the rules, figures and transactions behind it — and a report. POST /v1/shadow/report reports over any period from the comparisons you kept; a hosted lender’s kept in its own records service are reported at GET /v1/l/<lender>/shadow. A lender’s configuration can be put in shadow: nothing reaches an applicant and no money moves. See it at /decisioning/shadow.

    3 endpoints

  35. Four suites and two front doors

    Sold as four suites — Creditcrest Originate, Decide, Service and Comply — and two front doors, the Statement API and Creditcrest for Brokers. This reference is grouped the same way. Enrich and Capacity are part of Statement, Record of Policy Engine and Intent of Score; Growth is Book and reports. No address changed.

  36. Creditcrest Sign

    Signing for any document. Ask for a signature and get a link; the signer reads, draws their signature, types their name and agrees; you get the evidence back — the drawing as strokes, sealed with the rest — with a certificate to keep. Require a drawing with requireDrawn. POST /v1/sign/certificate gives the certificate as a PDF. Nothing is stored on our side. Anyone holding the evidence can have it checked. Contracts in the hosted borrower account are signed the same way.

    5 endpoints

  37. Creditcrest Score: each lender’s own model borrower, risk classes, and a plain score

    A model borrower per lender, named for it, whose rating moves with every loan repaid or written off. Every applicant compared with it measure by measure, and put in a Creditcrest risk class, AAA to CC, each a range of the chance the loan is not repaid in full (riskClass, pd; D for a loan in default or written off). Every change to a borrower’s rating kept with its day, reason and class; a write-off with hardship relief counted apart; dishonours and defaults with their last dates. Or a plain score out of 1200. POST /v1/score/model-borrower and /v1/score/history hand the state back to lenders that keep their own records.

    7 endpoints

  38. Creditcrest Score

    Each applicant compared with your own repaid borrowers: a rating against the model borrower, every match shown, a suggested amount and term, and validation on your outcomes.

  39. A lender’s own operation, hosted

    For a lender whose operation runs on Creditcrest, every call behind its own key and all listed at GET /v1/l: applications sent by its own front end, with the same checks, sealed record and queue as the hosted pages; a ten-minute, single-use sign-in link to the operations console for its staff; the payments its borrowers asked for, settled or returned by its own program; the daily run that seals each account’s day and lists the debits, deadlines and messages due, sending nothing and moving no money; and the monthly funder pack — loan tape, borrowing base, vintage curves, roll rates, complaints and refunds. For any lender, POST /v1/decisioning/run runs its own policy text on an application and /v1/decisioning/shadow sets a candidate policy beside it.

    37 endpoints

  40. Statement reads the bank’s own words

    Fees, cash, transfers, pay, benefits, tax, rates and fines, card and loan repayments, debt collectors and every licensed bookmaker. BPAY billers by their code and short name. Accuracy published for every category. One name for each merchant, however the feed spells it. New signals for debt collection and pay advances. Pass holders with a statement and a transfer under the holder’s own name is read as their own money.

  41. API keys

    A key per lender, live or sandbox, scoped and dated. Calls that take a body need one; a sandbox key is one call away.

    3 endpoints

  42. Statement and Capacity, as data

    A bank statement read, and the loan it can service, for a program. An invented statement to build against. GET /v1 now lists every endpoint.

    15 endpoints

  43. The rest of the lifecycle

    Application to account: the inquiries record, identity and AML, the ledger and its book, payments, the borrower’s portal and messages, and the obligations around them.

    80 endpoints

  44. Enrich, Small Amount and the back book

    Transaction categories with the reason for each, small amount contracts costed in dollars, and what existing borrowers pay.

    7 endpoints

  45. The first endpoints

    Published home loans costed for one loan, the broker’s best interests file, a credit policy replayed, and the hardship clock.

    13 endpoints