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 AUTHORIZED_USER or NON_BORROWING_DEFENDANT) with additional calls, but the BORROWER is what drives state-based template scoping.

Create the file request

Open a file request for the document you need produced. Pass the account’s matter identifier and a triggerContext describing the document type, lifecycle step, and line of business. 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>",
    "triggerContext": {
      "templateType": "affidavit_of_debt",
      "lifecycleStep": "pre_suit",
      "lineOfBusiness": "collections"
    }
  }'

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 triggerContext 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

Webhook notifications for signature completion are on the roadmap but are not yet available. Until webhooks ship, poll for newly created files on the account to close the loop:

curl --request GET \
  --url "https://api.slate.inc/files/v2/files?owner=<owner-id>&filter[matterId]=<matter-id>" \
  --header "Authorization: Bearer <access-token>"

A completed signature ceremony produces a new file on the account containing the signed (and, if applicable, notarized) document. See List Files for filter and pagination options.

Webhook support for signature completion is planned. When it ships, you can subscribe to the event instead of polling. Contact your Slate account manager to be notified when webhooks are available.

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 (poll List Files today, webhook later)

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