Connectors

A connector is reusable integration code that brings an external system into Lobu: collecting data into memory, hosting a chat adapter an agent converses through, or exposing operations the agent can invoke. One connector can do several of these.

Connectors with a full setup walkthrough have their own page (Slack, Telegram, …). Everything else is documented from its own definition — the feeds it can ingest, the actions it can run, and how it authenticates.

How connectors work

Pull. Most connectors sync on a schedule: each run pulls the next slice of data and stores a checkpoint (a timestamp or cursor), so the next run asks only for what’s new. Polling stays incremental even against large APIs.

Push. For live updates, Lobu accepts inbound webhooks — authenticated JSON deliveries that arrive as events the moment something happens in the source system.

Act. Connectors don’t just read: they expose governed write-backs (create an issue, send an email, update a record) that agents invoke through Lobu’s approval and audit path.

Sandboxed. Every run executes in an isolated V8 sandbox with no filesystem of its own. Network access goes through a domain allowlist, and your OAuth tokens never enter the sandbox — the host swaps them in only once the destination is admitted.

Run it where your data lives

Cloud workers are stateless and sandboxed — fine for SaaS APIs, but they can’t reach your local files, shell, or logged-in browser sessions. For that, pair one of your own machines as a device: your Mac, a home server, any box with the CLI. Devices claim queued syncs and actions, and they’re also where your local coding agents (Claude Code, Codex, OpenCode) meet Lobu.