This page is the at-a-glance map of everything Binions can connect to — with an honest status for each. Binions reaches the outside world through six integration families: email & messaging, AI models, webhooks & APIs, object storage & file transfer, the HTTP edge, and industrial hardware. Each family is owned by one daemon, driven by a handful of playbook verbs, and speaks several providers or protocols behind a single alias. The tables below show exactly what is live today, what is partial, and what is coming — nothing is dressed up.
How to read this page. “Live” means implemented, shipping, and usable in a playbook today. “Partial” means the family works, but one or more providers are still placeholders. Anything still on the roadmap is flagged inline so you can plan around it.
Before the tables, the shape they all share. Every Binions integration follows the same multi-provider broker pattern: you register a connection once with its provisioning details and secrets, then your business playbooks refer to it by a short alias and never touch credentials or hostnames again. Swapping S3 for SFTP, or the stub AI provider for a real one, is a configuration change — the playbook that uses the alias stays the same.
mail.send, data.upload, ai.extract — and name the alias. No connection details leak into business logic.Action event and comes back as a Fact, both carrying the same correlation id so you can trace a whole run end to end.This is why Binions needs only a small set of generic verbs instead of thousands of app-specific connectors. The full pattern, including the split between provisioning and business playbooks, is described in The integration model; the verbs themselves are catalogued in the Playbook verb vocabulary.
One row per integration family. The Daemon column links to that service’s reference page; the Verbs are the playbook actions you actually write; Providers / protocols are what each family can speak today.
| Integration | Daemon | Playbook verbs | Providers / protocols / backends | Status |
|---|---|---|---|---|
| Email & messaging | mailbox | mail.register_mailboxmail.sendmail.unregister_mailbox |
Inbound IMAP (default), MQTT, AMQP, Redis pub/sub, WebSocket, SSE, Kafka (feature build); outbound SMTP | Live |
| AI models | aiinjector | ai.classifyai.extractai.inject |
stub (default) and Anthropic live; OpenAI and Ollama planned* |
Partial |
| Webhooks & APIs | webhookcaller | webhook.register_endpointwebhook.send |
REST (JSON) and SOAP (via headers + XML body) over HTTP/HTTPS; HMAC signing; OAuth2 authorization-code + PKCE with automatic refresh | Live |
| Object storage & file transfer | datatransporter | data.uploaddata.downloaddata.list_objectsdata.delete_objectdata.transform |
S3 / MinIO (default), local filesystem (default), SFTP, FTP | Live |
| HTTP edge & realtime | traefiklinker | traefik.register_routetraefik.unregister_routetraefik.list_routes |
http, https, ws, wss, sse, grpc, grpc-web — plus the showman /in gateway & live pages |
Live |
| Industrial | modbus | modbus.register_plcmodbus.readmodbus.writemodbus.list (+ extended) |
Modbus TCP, RTU-over-TCP; optional Modbus slave server | Live |
| Databases | database | database.register_tabledatabase.writedatabase.query (+6 more) |
PostgreSQL (default), SQLite, MySQL/MariaDB, MongoDB, MS SQL Server — per-action backend: selector |
Live |
| gRPC services | webhookcaller | webhook.send (protocol: grpc) |
Any reflection-enabled unary gRPC service — JSON↔protobuf transcoded automatically; grpc:// / grpcs:// |
Live |
| AI agents (MCP) | showman | config [[mcp.tools]] → playbooks |
Binions as a Model Context Protocol server — selected playbooks exposed as tools over the HTTP edge | Live |
| Remote SSH commands | webhookcaller | webhook.send (protocol: ssh) |
An allow-list of named commands run over SSH — password or key auth; not a remote shell | Live |
Each integration family has a dedicated guide that walks through registration, the available options, and worked playbook snippets — linked from the cards at the bottom of this page.
A one-line orientation for each row, so the verbs above have context.
| Email & messaging | Watch a mailbox or message queue for incoming work, and send mail out. The same daemon treats an IMAP inbox, an MQTT topic, or an AMQP queue as interchangeable inbound sources — you pick the protocol when you register the mailbox, and outbound always goes via SMTP. |
| AI models | Hand text to a language model to classify it, extract structured fields, or rewrite it — then act on the result in the same playbook. Providers are pluggable behind one interface, so a playbook written against the built-in stub runs unchanged once you wire in a real provider. |
| Webhooks & APIs | Call any HTTP endpoint — a CRM, a SaaS API, an internal service — or send outbound webhooks. Because the request body is sent as you supply it and you control the headers, both JSON REST APIs and XML SOAP services work with the same two verbs. |
| Object storage & file transfer | Move files in and out of object stores and file servers, list and delete objects, and convert tabular data between formats. One alias can point at an S3 bucket today and an SFTP server tomorrow without changing the playbooks that read from it. |
| HTTP edge & realtime | Register and remove routes on the built-in HTTP edge so a playbook can expose (or retract) a public endpoint on demand — plain HTTP/HTTPS, WebSockets, server-sent events, or gRPC, including gRPC-web for browsers. |
| Industrial | Read and write registers and coils on PLCs and other industrial equipment over Modbus, bringing factory-floor hardware into the same playbooks as your email and APIs. Binions can also expose its own Modbus slave server when a controller needs to poll it. |
The storage family carries one extra capability worth calling out on its own. The data.transform verb converts a payload between JSON, CSV, and XLSX in a single step — for example, turning an uploaded spreadsheet into JSON for an AI step, or rendering query results as a CSV before mailing them out. It is part of the datatransporter daemon, so a typical pipeline downloads an object, transforms it, and uploads or forwards the result, all by alias.
steps:
- run: data.download
with:
bucket: incoming # alias registered earlier
key: orders/latest.xlsx
- run: data.transform
with:
from: xlsx
to: json
- run: ai.extract
with:
provider: anthropic # falls back to the stub if not configured
schema: order_summaryConcurrent by default. Playbooks process work concurrently — a slow step never blocks other runs in flight. To fan out several of these steps at once and join only the results you need, switch to
mode: asyncand add await_for:join step. See Playbook patterns for the full fan-out example.
Everything marked Live in the matrix above is implemented and usable today. The following items are the exceptions — placeholders, deferred verbs, or staged behaviour — and they are the only gaps.
Not yet enabled. Read these before you design around a feature.
stub provider and a live Anthropic provider. The pluggable provider interface is designed for OpenAI and Ollama too, but those backends are not yet enabled — selecting them today will not reach a real model.mail.extract_data is deferred. There is no dedicated mail-side extraction verb in the current release. To pull structured fields out of an email, fetch the message with the mailbox daemon and run ai.extract on its contents — the same pattern the example above uses.data.register_bucket is a setup action, not a business verb. Buckets and file-transfer targets are declared during provisioning so day-to-day playbooks can use them by alias. Treat bucket registration as an administrative step, not something you call from ordinary workflows.The short version. Email & streaming feeds, webhooks/APIs (including OAuth2), databases across five engines, storage & file transfer, the HTTP edge with live pages, and Modbus are all live. AI is live with Anthropic and the stub; OpenAI and Ollama are coming. Use
ai.extractfor email parsing, register buckets at setup time, and trigger file work explicitly until folder-watching ships.
Two operational notes apply to every row in the matrix. First, secrets never live inside a playbook: IMAP/SMTP passwords, API keys, AI provider keys, and S3 or SFTP credentials are kept in dedicated secret files and referenced by path when you register a connection. Second, because every call is an event with a correlation id, you can follow a single workflow — mailbox in, AI step, storage out, webhook notification — as one traced run across all the daemons involved.
| Where credentials live | Dedicated secret files, referenced by path at registration — never inline in playbooks |
| How connections are declared | Provisioning playbooks or first-boot config register each mailbox, bucket, provider, route, or PLC by alias |
| How a run is traced | Every Action/Fact event carries a correlation id shared across daemons and logs |
| What is on the roadmap | OpenAI & Ollama AI providers; watched-folder auto-discovery for file transfer |
* OpenAI, Ollama, and watched-folder auto-discovery are planned and not yet enabled. Raspberry Pi and other 64-bit ARM hardware are supported from the public 1.0 release; the current packages are for 64-bit x86 (amd64) only.