System Overview

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 the authentication to the data source with your user’s credentials.
• Jobs read or write data on behalf of your user.
• Store records the data retrieved or written during Jobs.
• Session covers the entire Workflow process.

API Endpoint Model

Deck separates how developers initiate work from how they retrieve results — a distinction that reinforces clarity between execution and persistence.

• Jobs endpoints are used to initiate and run specific actions inside a session. These endpoints trigger a new job, such as retrieving data, submitting a form, or updating an account. Each job is atomic and returns its own completion status and output.
• Store endpoints are used to fetch the outputs generated by those jobs — whether tied to a specific execution or accumulated over time. Developers can retrieve structured data, documents, or write receipts across sessions, connections, and entities.

This separation allows for clean orchestration:
You run work through Jobs. You retrieve results through Store.

Deck's Core Design Principles

• Atomic Jobs: Each Job is self-contained — one task, no hidden dependencies, no coupling.
• Session continuity: Deck enables preserving authentication across Jobs, so developers can build multi-step workflows without managing Session recovery.

Session Management

Whether you are attempting to do a single Job or multiple Jobs, the session must start with an EnsureConnection Job and end with a CloseConnection Job. Every other Job done during the session is sandwiched between those two.

If multi-Job Workflow: Developers must flag it when starting the Workflow Attempt so the Session is ‘kept running’ until all Jobs are done.