Authentication
Every REST v1 request requires an HTTP Bearer credential. Create an API key in Settings → Integrations, copy it when it is shown, and send it in the Authorization header.
Funding Machine accepts existing fmk_ API keys and fmo_ OAuth access tokens. It does not accept an iframe or browser session as API authentication.
Download the Postman collection, import it, and replace the bearerToken collection variable with your key.
API keys can read applicant data. Store them in a secret manager, never embed them in browser code, and revoke a key immediately if it is exposed.
Location and agency keys
A location key is permanently pinned to the CRM location where it was created. Passing a different locationId does not redirect it to another account.
An agency key can reach currently installed locations owned by its company. Call GET /locations to discover them, then pass the selected locationId as a query parameter on other requests. A foreign or transferred-out location is refused; the read does not run against that location.
Read-only guarantee
Version 1 contains GET operations only. It cannot start credit pulls, run underwriting, change funding plans, send messages, or touch billing.
Credit-report permission
All REST reads require read. Stored raw JSON (GET /credit-reports) and PDF
download URLs (GET /credit-reports/pdf-url) also require credit_reports,
matching the MCP tools. Credentials missing read receive 403 forbidden
before report data is read. Requests with read consume
the shared durable quota before the credit_reports check: a missing report
permission returns 403 while quota remains, then 429 when it is exhausted.
Credit summaries and
underwriting results remain available with read alone.
API keys default to read. To enable raw reports, create a replacement key with
Allow full credit reports selected in Settings → Integrations. OAuth clients
must explicitly request read credit_reports and receive Operator consent;
refresh preserves the approved scopes and never adds report access. Location
and agency keys and OAuth tokens all use the same permission checks.
Request arguments are audited with personal values masked. Structural record
IDs remain available for troubleshooting; report payloads and bearer tokens
are not included in argument summaries.
