End-to-End Walkthrough: Account to Signed Document

This walkthrough covers the minimum integration surface most partners need. You place an account, add the borrower, open a file request against it, and hand off to Slate for document completion, quality control, and signature. Slate can orchestrate the signature and QC request creation for you through rules configured during onboarding, so your integration only has to worry about accounts, entities, and file requests.

Prerequisites

Client credentials and your owner identifier from your Slate account manager. See Authentication.
Confirm with your account manager which document types (template types) are enabled for your owner and which will be handled by Slate-managed signature and QC rules.

Workflow Overview

Create or upsert the account

Place the account into Slate with POST /v1/accounts. This is an upsert keyed on crid (your account number) within your owner, so calling it again with the same crid updates the existing record instead of creating a duplicate. The owner is derived from your bearer token. creditorId references a creditor you registered via POST /v1/creditors, and currentBalance is a decimal string. See Upsert Account for the full schema.

curl --request POST \
  --url "https://api.slate.inc/accounts/v1/accounts" \
  --header "Authorization: Bearer <access-token>" \
  --header "Content-Type: application/json" \
  --data '{
    "crid": "ACCT-00492",
    "creditorId": "9c1f2e5a-7b3d-4c8e-9a10-2f6b4d8e1c07",
    "status": "ACTIVE",
    "currentBalance": "4820.55"
  }'

Store the returned Slate accountId. Its matterId is what you attach files to, and its accountId is what you add the borrower to in the next step.

Add the borrower entity

Add the borrower to the account with POST /v1/accounts/{accountId}/entities, setting type to BORROWER. This step is required before you request a document: Slate scopes the document templates (and firm placement) to the borrower’s state, which it reads from the entity’s physicalAddress. Include an address with a stateProvCode so Slate knows which state’s templates to use. If you omit physicalAddress, Slate falls back to the officialAddress; if neither carries a state, template selection cannot resolve.

curl --request POST \
  --url "https://api.slate.inc/accounts/v1/accounts/<account-id>/entities" \
  --header "Authorization: Bearer <access-token>" \
  --header "Content-Type: application/json" \
  --data '{
    "type": "BORROWER",
    "name": "JANE Q DOE",
    "physicalAddress": {
      "addressLine1": "123 Main St",
      "city": "Austin",
      "stateProvCode": "TX",
      "postalCode": "78701",
      "country": "US"
    }
  }'

Give the entity’s name in natural "FIRST MIDDLE LAST SUFFIX" form for a person; Slate derives the internal first/middle/last/suffix name fields from it. You can add other parties (for example COBORROWER, AUTHORIZED_USER or NON_BORROWING_DEFENDANT) with additional calls, but the BORROWER is what drives state-based template scoping. Add a COBORROWER when a second person is obligated on the account. Templates render a single coborrower slot, filled by the first COBORROWER or NON_BORROWING_DEFENDANT on the account, and a template that generates per debtor is rendered a second time for them.

Create the file request

Open a file request for the document you need produced. Pass the account’s matter identifier and one or more trigger contexts, each naming a templateType. Slate derives the lifecycle step and line of business from the matter’s state, so you supply only the template type. Slate uses that context to select the correct template and to apply any signature and QC rules configured for your owner during onboarding.

curl --request POST \
  --url "https://api.slate.inc/files/v1/requests" \
  --header "Authorization: Bearer <access-token>" \
  --header "Content-Type: application/json" \
  --data '{
    "owner": "<owner-id>",
    "matterId": "<matter-id>",
    "triggerContexts": [
      { "templateType": "affidavit_of_debt" }
    ]
  }'

See Create Request for the full parameter list.

If you need to bundle a new document type into an existing request (for example, adding a fresh exhibit to a package), upsert the request with the additional triggerContexts entries rather than creating a parallel request. Confirm the specific upsert behavior for your onboarding profile with your Slate account manager.

Slate users complete, QC, and sign the document

Once the file request exists, everything else happens inside Slate:

The assigned user completes the file request in the Slate UI, filling any required fields and attaching supporting evidence.
Slate automatically creates the QC request against your configured checklist and routes it to the correct reviewer role. Reviewers approve or reject items in the Slate UI. See Quality Control for how checklists and processes are structured.
After QC approval, Slate automatically creates the signature request and transaction, assigns the signer (and notary, if the template requires one), and runs the ceremony. See Signatures for the underlying objects.

Your integration does not need to call the QC or signature APIs directly for this path. The rules configured during onboarding wire those steps together.

If you want to manage QC or signatures yourself instead of letting Slate orchestrate them, ask your account manager to disable the automatic rules for the relevant template types. You can then drive the flows manually via the Quality Control and Signatures APIs.

Detect completion

Subscribe to the DOCUMENT_READY webhook to be notified when a signed or processed document becomes available on a matter. See Webhooks for more details on how to subscribe to this event.

{
  "crid": "644333222",
  "downloadUrl": "https://slate.inc/download_url.pdf",
  "fileRequestUUID": "e845435f-13a6-4c46-889a-ea6b27414494",
  "fileUUID": "d1ea8f8d-b07a-47f9-b02e-bbba960cf1e0",
  "matterUUID": "d2a64dba-a8bf-45be-ab91-424b4a99bd29",
  "wetInk": false
}

You can also track progress on the file request itself. GET /v1/requests/{requestId} reports a workflowStatus that follows the document through QC and signing and reads completed only once it has been both signed and reviewed, alongside the qualityCheckRequestId and signatureRequestId Slate raised for it. Polling GET /v1/requests?workflowStatus=awaiting_qc is the same view across every request at once. See Workflow status.

What Slate Handles for You

Step	Owner
Create or upsert account	Your integration
Add borrower entity (with state)	Your integration
Create file request	Your integration
Complete file request in Slate UI	Slate user
Create and run QC request	Slate (rules configured at onboarding)
Create signature request and transaction	Slate (rules configured at onboarding)
Signer and notary ceremony	Slate user via signing URL
Detect signed document	Your integration (the file request’s `workflowStatus`, the `DOCUMENT_READY` webhook, or polling List Files)

Get Started

Core Concepts

Guides

End-to-End Walkthrough: Account to Signed Document

Prerequisites

Workflow Overview

What Slate Handles for You

Next Steps

Sync Accounts

Files & Requests

​Prerequisites

​Workflow Overview

​What Slate Handles for You

​Next Steps

Sync Accounts

Files & Requests

Prerequisites

Workflow Overview

What Slate Handles for You

Next Steps