Integration Overview
The Slate integration covers the full loan lifecycle. Your platform discovers products and quotes a serviceability scenario on behalf of a broker (pre-submission), lodges the full application reusing the same LIXI CAL shapes (submission), then tracks it to a lender decision (post-submission).
The loan lifecycle
The same scenario flows through three stages, from a serviceability quote to a tracked lender decision.
Pre-submission
/api/v1/pre-submission/productsList products. View the products available to you.
/api/v1/pre-submission/serviceabilityCheck serviceability. Send a declared scenario; receive an indicative outcome.
/api/v1/pre-submission/serviceability/{preSubmissionRequestUid}Fetch a previous check. Re-fetch the indicative result of an earlier check by its preSubmissionRequestUid.
/api/v1/pre-submission/serviceability/{preSubmissionRequestUid}/repayment-scheduleFull repayment schedule. The full monthly repayment schedule for the proposed loan.
/api/v1/pre-submission/{preSubmissionRequestUid}/required-documentsList required documents. The evidence the broker collects up front, resolved against the declared scenario.
/api/v1/pre-submission/{preSubmissionRequestUid}/documentsUpload required documents. Upload each file in a single multipart request, against the same scenario.
Submission
/api/v1/channel-submissions/xmlSubmit the application. Lodge the full application once the borrower proceeds, reusing the same LIXI CAL package as the serviceability check.
Post-submission
{your callback URL}Receive status updates. Slate posts a back-channel message to your callback URL for each lifecycle event as the application moves toward a decision.
/api/v1/channel-submissions/{submissionUid}Poll submission status. Poll this endpoint for the current ingestion and decision status.
To correct or re-lodge after submission, resubmit the same call with the same identifiers; Slate reprocesses the existing application rather than creating a new one.
What pre-qualification does
You send a scenario containing the number of applicants and dependants, declared incomes, liabilities, monthly expenses, a residential postcode, the security property's estimated value, and a single proposed loan with its purpose.
Slate evaluates the scenario against live product rules and returns an indicative outcome plus a breakdown of the key serviceability inputs. The proposed loan comes back as one unified set of figures (repayments, LVR, and a blended rate); where Slate services it as a primary plus deposit-boost split, that split is included as accessory splits detail.
Use this to give brokers a fast, structured read on how a scenario sits before committing to a full application.
Authentication
The API uses machine-to-machine (M2M) credentials issued by Frontegg.
During onboarding your Slate integration manager provides, per environment: a Client ID and secret scoped to the PreSubmissionPartner credential, your Frontegg tenant host, your channel code (used at submission), and confirmation that the credential carries the submission permission.
Exchange the Client ID and secret for a short-lived access token using Frontegg API token authentication, against your tenant host (see Environments):
POST https://<your-tenant>.frontegg.com/identity/resources/auth/v2/api-token
{ "clientId": "...", "secret": "..." }
The access token is returned in the accessToken field. Include it as a Bearer token on every API request:
Authorization: Bearer <access-token>
Tokens expire after one hour (expiresIn, in seconds). Re-authenticate before expiry rather than on a 401.
Environments
Build and certify against UAT first, then repoint to production. Your integration manager confirms your exact tenant host and issues separate credentials for each environment. Examples in these guides use the production base URL.
| Environment | API base URL | Frontegg tenant host |
|---|---|---|
| UAT | https://api.uat.slateos.ai | https://slate-uat.frontegg.com |
| Production | https://api.slateos.ai | https://slate.frontegg.com |
Endpoints
| Stage | Purpose | Method and path |
|---|---|---|
| Pre-submission | List available products | GET /api/v1/pre-submission/products |
| Pre-submission | Check serviceability (JSON) | POST /api/v1/pre-submission/serviceability |
| Pre-submission | Check serviceability (LIXI CAL) | POST /api/v1/pre-submission/serviceability with an XML body |
| Pre-submission | Fetch a previous check | GET /api/v1/pre-submission/serviceability/{preSubmissionRequestUid} |
| Pre-submission | Full repayment schedule | GET /api/v1/pre-submission/serviceability/{preSubmissionRequestUid}/repayment-schedule |
| Pre-submission | List required documents | GET /api/v1/pre-submission/{preSubmissionRequestUid}/required-documents |
| Pre-submission | Upload a document | POST /api/v1/pre-submission/{preSubmissionRequestUid}/documents |
| Pre-submission | List uploaded documents | GET /api/v1/pre-submission/{preSubmissionRequestUid}/documents |
| Submission | Submit an application | POST /api/v1/channel-submissions/xml |
| Post-submission | Get submission status | GET /api/v1/channel-submissions/{submissionUid} (see Status updates) |
All requests go to your environment's API base URL and carry the Bearer token. See the API Reference for full schemas.
Rate limits
Requests are limited per credential: up to 20 per second, with short bursts to 40. Exceeding the limit returns 429 with a Retry-After header (see rate_limited). Back off for the indicated interval, then retry.
Audit trail and linkage
Every serviceability call, including rejected calls, is recorded against the returned preSubmissionRequestUid. This identifier is the authoritative reference for any dispute or support inquiry.
The unique preSubmissionRequestUid is what links a quote to its application. Pass it at submission as the optional X-PreSubmission-Ref header (for example, psr_01ARZ3NDEKTSV4RRFFQ69G5FAV) to tie the lodged application to that specific quote. A partnerScenarioReference supplied on the serviceability call is echoed back in the response and can be passed again at submission via the X-Partner-Scenario-Reference header; it is a non-unique partner trace reference for your own correlation, not the linkage key.
You may also send an optional X-Request-ID header on any request. Slate echoes it back as the request_uid on the error envelope, and assigns a req_ identifier when you do not send one. Either way, you get a per-request correlation key for support.
Next steps
Follow the Quickstart to make your first call end to end. For pre-submission, see Products for the product list, Serviceability Request Fields for a field-by-field breakdown of the request, LIXI CAL to send a LIXI package instead of JSON, and Required Documents for the evidence list and how to upload it. For submission and after, see Submission to lodge an application, Status updates to track it to a decision, and Resubmission to correct or re-lodge it. The Error Reference documents error codes, and the API Reference has the full schemas.