# Data & tools

> Connectors that bring external content into shared memory, and the actions agents can run against sources.

A **data connector** brings an external system into Lobu on two axes: it **collects** content into [shared memory](/getting-started/memory/) as events, and it can expose **actions** agents invoke against the source under policy and approval.

Lobu ships built-in connectors for GitHub, Gmail, Linear, Jira, Stripe, YouTube, RSS, and more. But you're not limited to what we ship — your agent can write connectors in TypeScript, or you can write them yourself. Any REST API, GraphQL endpoint, webhook, OAuth service, or browser session becomes a connector through the [Connector SDK](/guides/author-a-connector/). See the [examples folder](https://github.com/lobu-ai/lobu/tree/main/examples) for real connectors pulling from Shopify, Salesforce, QuickBooks, Discourse, DocuSign, Google Takeout, and others.


## How a connector works

Every connector is a small **TypeScript** program that runs in an isolated V8 sandbox — it gets a filesystem workspace, a restricted network path through the gateway proxy, and no direct access to Lobu's central database except through the same event and memory APIs an agent uses.

- **It writes to shared memory, not your database.** A connector's sync produces typed events that land in the central Postgres-backed store, where [entities](/getting-started/memory/#entity-types) and [automations](/getting-started/automations/) read them. The connector never holds a database connection.
- **Secrets never reach the worker.** The gateway stores credentials — OAuth tokens, API keys — behind its [secret proxy](/guides/security/#the-placeholder-model). The worker only ever sees a placeholder (`lobu_secret_<uuid>`); the real value is swapped in on the gateway just before an allowed outbound request leaves the host.
- **Auth is declared, not hard-coded.** A connector's definition lists the auth models it supports, and the gateway handles the hard parts:

| Auth model | What Lobu does |
|---|---|
| `oauth` | Runs the OAuth dance, refreshes tokens, and isolates per-user credentials |
| `env_keys` | Stores the API key or PAT encrypted; injects it only at egress |
| `app_installation` | Manages org-scoped app installs and their webhooks |
| `browser` | Uses cookies from a logged-in Chrome session via the paired Owletto extension |
| `none` | Public endpoints, no credentials |

- **Agents can author and deploy connectors at runtime.** A coding agent with the Lobu skill can scaffold a connector, declare feeds and actions, and ship it with `lobu apply` — no human in the loop. The connector runs in the same isolated sandbox as the agent, pulling data from browsers, OAuth APIs, or any HTTP endpoint on demand.

## Device connectors

Some data lives behind your login, on your machine, or in a browser session that no cloud worker can reach. Owletto — the Mac app and Chrome extension — solves this by pairing your device with Lobu as a **device worker**. Owletto is one of three ways to register a device; `lobu daemon` turns any machine with a terminal into one. See [Devices](/connectors/devices/) for the full picture, including how pinned Automations run on your local Claude Code, Codex, or OpenCode install.

```text
  Cloud worker                      Device worker (Owletto)
  ─────────────────────             ─────────────────────
  Runs on Lobu server               Runs on your Mac
  Gateway proxy for egress          Uses your machine's network
  OAuth / API key credentials       Your real logged-in sessions
  GitHub, Stripe, RSS, …            Browser tabs, local files, …

         │                                   │
         └──────────┬────────────────────────┘
                    ▼
            Shared memory
            (same entity graph)
```

**Owletto Mac app** pairs as a device worker and advertises capabilities like `os.files` (local filesystem), `screentime` (screen time data), and `os.shell` (command execution). Connectors declare which capability they need — if a connector requires `screentime`, it only runs on a Mac that has Owletto installed and has granted that permission.

**Owletto Chrome extension** enables browser-based data collection. It drives your real logged-in Chrome — the tabs, sessions, and cookies you already have. Connectors like X (Twitter) use it for feeds that have no public API (home timeline, DMs). The extension pairs through the Mac app's native messaging; no separate auth flow.

A connection can be **pinned to a device** so its syncs and actions run on that machine instead of cloud workers. Useful when:

- The connector needs your browser session (X timeline, site scraping)
- The connector reads local files or system data (Apple Screen Time, filesystem takeout)
- You want egress to use your machine's network, not the gateway proxy

Pinning is optional for cloud-capable connectors ("run the GitHub connector on my Mac") and required for device-only ones. The gateway delivers credentials to the device over a user-scoped token — the trust boundary is the user who owns both the device and the data.

For chat surfaces, see [Connect a chat platform](/connectors/chat/). For MCP clients, see [Agents & clients](/connectors/clients/).