LOS integration architecture

Snapdocs has built integrations to many LOS platforms and is opinionated about the architecture that lets customers use every workflow. Every LOS is different, so treat this as the recommended shape and adapt where your platform requires it.

The recommendation has three kinds of parts: UI for lender users inside the LOS, a listener for events arriving from Snapdocs, and adaptor code (a "connector") that manages everything in between.

The connector

  1. Authentication and token management — fetch, cache, and reuse bearer tokens (the shared pattern).
  2. Request/response handling with persistence to the LOS backend, plus retries or replays for outages and networking blips.
  3. Data mapping from loan fields to Snapdocs request fields, including customer-specific field overrides (scope guide covers the discovery work).
  4. Workers for webhook events: jobs that download documents on document events and act on the other event types.
  5. Event logging in a lightweight database or other structured storage. Where required, closing events can also feed LOS logs or disclosure tracking.

Persist Closings Create requests and listener events when they're received, and enqueue senders and handlers to act on them. Queues, database persistence, and in-memory stores such as Redis all work in practice.

LOS screens

To fit lender workflows, expect to build several screens or forms:

  • Configuration — opt in to Snapdocs, toggle features, store API keys and secrets (with rotation), and manage field overrides or data maps per lender.
  • Action UI — however the loan gets sent: a Send To Snapdocs button, a dropdown option, fields on an existing screen, or a fully implicit flow with no new UI.
  • Closing values — editable Snapdocs fields where lender users work: closing type (defaulting to hybrid is a good start), redraw selection (original, full, partial), and unmapped extras such as additional contact emails or external identifiers.
  • Closing display — a form showing the mapped values that will be, or were, sent to Snapdocs, often re-displaying existing loan values in one screen.
  • Status, per loan and per list — status updates broadcast multiple states back to each loan; display them at full granularity on the loan, and add Snapdocs status columns to loan lists and pipeline views so users can see closing state without opening each loan.

Triggers

Snapdocs expects the LOS to create the closing once a defined event has taken place — generally after final closing-package documents are drawn or redrawn and disclosure tracking entries are made. The trigger can be explicit (each loan has a Send To Snapdocs action, or Snapdocs appears as a document-destination selection) or implicit (a loan reaching a milestone, such as drawn documents returning, auto-triggers Closings Create or Redraw). Snapdocs supports any trigger mechanism, and it can differ per lender customer, so this decision lies with lender preference more than Snapdocs preference.