Authenticating and making your first API call
Get your API key and tenant ID from the portal, send your first POST /loans request, and understand the loanId and error shapes you will work with throughout every MOS integration
Get your API key and tenant ID from the portal, send your first POST /loans request, and understand the loanId and error shapes you will work with throughout every MOS integration
Before making your first call you need three things: a sandbox account, an API key, a tenant ID, and a client secret.
Every request to the MOS API must carry all three credentials as HTTP headers. There is no OAuth flow for system integrations; the headers are the only authentication mechanism required.
The API requires three headers on every request:
x-api-key — your API keyx-tyk-mos-client-secret — your client secret, provisioned at tenant approval and delivered via 1Passwordtenant-id — your tenant IDThere is no token exchange, no session, and no expiry on the key or client secret themselves. All three headers are required on every call. A request missing any of them will return 401 Unauthorized.
The single unauthenticated endpoint is GET /health, which returns the API's operational status. All other endpoints require the full header set.
If you are building a backend integration, store all three values as environment variables and inject them at request time. Do not embed them in client-side code or commit them to source control.
The entry point for every loan integration is POST /loans. This creates a loan record that anchors all documents, extracted data, and analytics events for that loan. The only required field in the request body is externalLoanId, which is your LOS loan number used to map MOS records back to your system.
curl -X POST https://api.mos.true.ai/v1/loans \
-H "x-api-key: YOUR_API_KEY" \
-H "x-tyk-mos-client-secret: YOUR_CLIENT_SECRET" \
-H "tenant-id: YOUR_TENANT_ID" \
-H "Content-Type: application/json" \
-d '{"externalLoanId": "your-los-loan-number"}'
Replace the placeholder values with your actual credentials. The externalLoanId value should match whatever identifier your LOS uses for this loan: a loan number, a GUID, or any string up to 255 characters.
A successful call returns HTTP 201 Created with a JSON body.
The POST /loans response contains the loan record as created. The field you need immediately is loanId:
{
"loanId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"externalLoanId": "your-los-loan-number",
"status": "Active",
"createdAt": "2026-06-09T14:32:00Z"
}
loanId is the MOS-generated UUID for this loan. It is the path parameter you pass to every subsequent call in the loan lifecycle: document uploads, document listing, extracted data retrieval, income clarity, and analytics. Store it alongside your external loan identifier in whatever database or cache your integration uses.
The status field begins as Active. Valid loan statuses are Active, Pending, Closed, and Cancelled. Status does not affect which endpoints are callable. It is informational and used for reporting purposes.
All error responses from the MOS API follow a consistent three-field structure:
{
"status": 400,
"message": "externalLoanId is required",
"error": "Bad Request"
}
| Field | Description |
|---|---|
status |
The HTTP status code as an integer, repeated in the body for convenience |
message |
A human-readable description of what went wrong |
error |
The standard HTTP reason phrase for that status code |
The status codes you will encounter most often:
message field identifies the specific problem.loanId, documentId, or other path parameter does not exist in your tenant's data.Always check the message field first when debugging. The error field maps to the HTTP spec; message is where the actionable detail lives.
With a loanId in hand, the next step is uploading documents and running the Loan Setup pipeline. The Loan Setup workflow handles automatic classification, field extraction, and data validation for every document you upload. See the Building the Loan Setup integration guide for the complete upload-to-extraction flow.
If you are building the income analysis step, review the Setting up Income Clarity guide, which requires Loan Setup to complete first.
Production reporting in MOS gives developers a direct way to retrieve structured report data for tenant workflows, operational monitoring, and downstream analytics. This guide walks through discovering available reports, generating Bank Statement Analysis output, applying filters, and exporting report rows for your own systems.
A technical walkthrough of the eight-stage processing pipeline—from SPLITTER through EXPORT—covering the document status lifecycle, classification and extraction confidence scores, review task triggers, and how to build reliable automation around the analytics event stream.
Check which documents are income-eligible, trigger the Candor calculation, poll for results, and re-run after new documents arrive — with a full audit trail of every calculation run available via the history endpoint.