Create intake
Creates a borrower and loan for one submission and returns an upload URL for it. Reusing a client_reference returns the same borrower and loan instead of creating another pair.
Requires the intake:write scope. Rate limit: 1000 requests per minute per key (the upload lane).
Authentication
Bearer token. Use ss_live_… for live data or ss_test_… for the sandbox (test mode). See Authentication.
Headers
Idempotency token. Retries that reuse the key within 24h replay the original response. Up to 255 characters; a UUID is typical. See Idempotency.
Pin the API version, e.g. 2026-10-07. Omit to get the latest. See Versioning.
Request
Optional file size in bytes, reported by the client. The upload itself is capped server-side.
SHA-256 hex digest of the file, computed client-side. Used for within-loan duplicate detection. Verified server-side during processing.
Customer-supplied idempotency / grouping key. Unique per tenant: repeat submissions for the same end-borrower pile onto the same auto-provisioned loan. Omit to always create a new submission.
Optional business name for the borrower. When supplied, the borrower is
created complete under that name and lists with your other borrowers at
once. When omitted, the provisioned borrower gets a placeholder name and
is flagged is_intake until someone completes triage, which renames
it in place.
Response headers
Set to true when the response is replayed from the idempotency cache for a request that re-presented an Idempotency-Key it had already used. Absent on the original (winner) response. A replay repeats the original status and body. When the original could not be stored (an unhandled server fault, or a body over the 1 MiB replay cap) the replay is an error envelope that says so; the operation is never re-run under the same key.
The API surface version the server resolved for this request. Always present, regardless of whether the client supplied the request-side SpreadSpace-Version header. Default: 2026-10-07.
Request budget of the endpoint’s rate-limit policy per 60-second sliding window. See Rate limits.
Requests left in the current window. Suppressed on 429 responses produced outside the rate limiter (for example a usage throttle), where a remaining budget would be misleading.
Seconds until a guaranteed-fresh window.
The active policy in limit;w=window-seconds form.