Here’s a quick look at Deck’s architecture. At the center of it all is the Link — your user-permissioned environment. A Link is built around three core components: Connection, Jobs, and Store, with an orchestration layer called Session.
  • Connection manages authentication to the data source using your user’s credentials.
  • Jobs read or write data on behalf of the user.
  • Store records data retrieved or written during Jobs.
  • Session coordinates the full Workflow process.

​
API Endpoint Model

Deck separates work initiation from result retrieval, reinforcing a clear distinction between execution and persistence.
  • Jobs endpoints initiate and execute actions within a session. These actions may include retrieving data, submitting a form, or updating an account. Each Job is atomic and returns its own status and output.
  • Store endpoints are used to fetch the outputs generated by those jobs — either from a specific execution or accumulated across time. Developers can access structured data, documents, or receipts tied to sessions, connections, or entities.
This model supports clean orchestration:
  • Run work via Jobs
  • Retrieve results via Store

​
Deck’s Core Design Principles

  • Atomic Jobs: Each Job does one thing — no hidden dependencies, no side effects.
  • Session continuity: Deck allows authentication to persist across multiple Jobs, enabling complex workflows without session recovery logic.

​
Session Management

Every session must begin with an EnsureConnection Job and end with a CloseConnection Job. All other Jobs in the workflow are executed in sequence between those two. For multi-Job workflows, developers must flag the session at the start of the Workflow Attempt to keep it active until all Jobs are completed.