Integration architecture

Snapdocs has built this connector shape into dozens of LOS integrations, and it's what we recommend for a new one, based on what's worked across that history. Treat it as a starting point: every LOS is different, and you should adapt the pieces to fit yours rather than match this diagram exactly.

The recommendation has three kinds of parts: a sender that pushes data out, a listener that catches whatever Snapdocs sends back, and handlers that act on what the listener catches.

The connector, built for eClose

This is the shape as built for eClose: a Closing Sender that creates and redraws closings and attaches documents, a Listener that catches every webhook event, and a Status Handler and Doc(s) Handler that each act on the events meant for them.

The same shape, reused

The sender/listener/handler split doesn't care which Snapdocs product it's talking to, so the same connector extends to other products without new plumbing:

One sender that knows how to push a request to Closing, Post Close QC, or eVault. One listener catching events from all of them. Handlers specific to what each event needs done.

Keep the sender, listener, and handlers separate

The sender only knows how to push a closing, a redraw, or a document out. It doesn't need to know anything about what comes back, so build it without a dependency on the listener or handlers.

The sender also owns authentication and token caching (the shared pattern): fetch a token, cache it, reuse it across every outbound call. Handlers that call out too, such as the Doc(s) Handler pulling executed documents or the Status Handler pulling status, reuse that same cached token rather than managing their own.

The listener's only job is recognizing that a webhook arrived and routing it to the right handler. It shouldn't fetch documents, update a pipeline view, or decide what a status change means. That's the handler's job, one handler per concern. A slow or failing handler, a stuck document download, say, then can't block the sender's next request or the listener's next incoming event.

What changes in your source system

Sending Snapdocs the data it needs, and putting the status and documents it returns to good use, both take a few additions to your source system: a place to configure credentials and per-customer toggles, a trigger point where a record becomes a Send to Snapdocs action (an explicit button or an existing milestone), and status displayed back both per record and across a list, so your team can see what's in flight without opening each one.

Build these once for your first product and the pattern carries into the next: the configuration screen, the status display, and the trigger logic all reuse with a new set of fields and events swapped in.

For eClose specifically, LOS integration architecture covers the LOS screens, workflow phasing, and field-mapping detail this page skips.