Skip to main content
Slate organizes document management into two related concepts. Files are the raw documents you upload — affidavits, account statements, chain-of-title records, and any other supporting material. Requests are structured document bundles that attach files as exhibits, apply templates, and generate final PDFs suitable for court filings or creditor review. You typically upload files first, then reference them in one or more requests.

Files

Uploading a File

Slate uses presigned S3 URLs for file uploads. Your application never sends file bytes directly to the Slate API. Instead, you get a short-lived upload URL and form fields from Slate, then POST the file directly to S3 using multipart form data.
1

Create a file record and get a presigned upload URL

Call POST /v1/files with metadata about the file. Slate returns a presigned S3 URL, required form fields, and an id for the new record.
Response:
2

Upload the file bytes directly to S3

Use the uploadUrl and fields from the previous response to construct a multipart form POST. Include every key-value pair from fields as individual form fields, then append the actual file as the file field last. The order matters: S3 requires all policy fields to appear before the file bytes.
A successful upload returns HTTP 204 No Content from S3. Slate detects the upload asynchronously and transitions the file record’s uploadStatus to uploaded.
3

Confirm the file is available

Once the S3 upload completes, poll the file record to confirm it is ready to use in requests.

File Statuses

v1 vs v2 Files

Use v2 for new integrations. The v1 files API uses a single fileType field that blends the document’s tag and its canonical type. The v2 API (GET /v2/files) separates these into tag (the document tag) and fileType (the canonical Slate document type). This makes filtering and display significantly easier. Migrate existing integrations to v2 when convenient.

Redaction Summaries

When listing or retrieving files, append ?redactionSummary=true to include the current redaction state for each file that has at least one redaction. The redactionSummary object reflects the most recently created redaction job: latestId, latestStatus (pending, processing, completed, or failed), latestCreatedOn, latestErrorMessage (populated only when latestStatus is failed), and count of jobs for the file. Files with no redactions omit the object entirely.
You can also filter the list by redaction state with filter[redactionStatus] (in_progress, completed, failed, or none), which requires redactionSummary=true.

Archiving a File

To remove a file from active workflows, call DELETE /v1/files/{fileId}. This sets the file’s status to archived without deleting the underlying document. Archived files no longer appear in default GET /v2/files results unless you explicitly filter with filter[status]=archived.
A successful archive returns HTTP 204 No Content.

Concatenating Files

Merge multiple existing Slate PDF files into a single document using POST /v1/files/concat. Provide an ordered array of file IDs. Slate returns a presigned downloadUrl for the merged output. Non-PDF files are excluded from the merge and reported in the nonPdfFiles array.

Bulk Downloading Files

To retrieve many files at once, submit a bulk download job with POST /v1/bulkDownloads, passing a files array of file UUIDs (and an optional fileName). Slate responds with 202 Accepted and a job object containing id, status, and a pollUrl. Poll GET /files/bulkDownloads/{bulkDownloadId} until status is done; the response then includes a presigned downloadUrl for the zip. Job statuses are pending, processing, done, and failed.

Requests

A Request is a document bundle tied to a matterId. You define the structure of the bundle through a triggerContext that determines which templates and exhibits Slate attaches. Then you fill template fields, generate a preview PDF, and approve the request to create a permanent file record.

Request Workflow

1

Create a request

Call POST /v1/requests with the matterId and a triggerContext that specifies the templateType, lifecycleStep, and lineOfBusiness. Slate returns the created request with its id and sets the initial status to pending. You can also optionally provide notes, priority, or status.
2

Fill template fields

Use PATCH /v1/requests/{requestId} to submit values for the template fields listed in requestedFields. Each fill targets a specific templateId and provides an array of { key, value } pairs.
Field fills are merged, not replaced. Previously filled keys remain unless you overwrite them.
3

Generate a preview PDF

Before finalizing, call POST /v1/requests/{requestId}/generate to compile the filled templates and exhibits into a preview PDF. Slate returns a temporary downloadUrl you can present to reviewers. This does not create a permanent file record.
4

Approve to finalize

Once the preview has been reviewed, call POST /v1/requests/{requestId}/approve to generate the permanent file record. Slate compiles the output into a persistent PDF, creates a new file record, attaches it to the request’s generatedFile field, and sets the request status to completed. Approval is irreversible.

Request Statuses

Listing Requests

Retrieve document requests using GET /v1/requests. You must pass owner if using multi-owner credentials. Filter by status, matter (filter[matterId]), creditor reference (filter[crid]), service firm (filter[firmId]), template (filter[templateId]), priority (filter[hasPriority]), and completion date (filter[completedFrom] / filter[completedTo]). Order by id, crid, createdOn, matterId, or priority. Results are paginated: the response contains a fileRequests array and a pagination object with nextCursor, previousCursor, and totalCount.

Deleting a Request

Permanently remove a request that was created in error or is no longer needed using DELETE /v1/requests/{requestId}. This is irreversible and removes the request record, template fill state, and exhibit references. Any file generated from a prior approval of this request remains intact.
A successful deletion returns HTTP 204 No Content.