Binions connects to the systems your business already runs — email and message queues, AI models, web APIs, object storage, file servers, HTTP services, and even industrial controllers — through a small set of components we call brokers. Instead of thousands of app-specific connectors, you learn one generic verb per capability and let a single configuration field choose which technology it talks to. This page is the map of everything Binions can plug into and how the pieces fit together.
The result is a platform that feels small but reaches far. A handful of daemons cover a surprisingly wide surface, because each one is a multi-provider broker: the same verb that registers an IMAP mailbox also registers an MQTT broker or an AMQP queue; the same verb that uploads to an S3 bucket also writes to an SFTP server or a local folder. You write your playbooks once, against a stable vocabulary, and swap the underlying technology with a one-word change.
Most integration tools grow a separate connector for every service, so the catalogue balloons into the thousands and each tile behaves a little differently. Binions takes the opposite approach. For each capability — receive a message, call an AI model, send an HTTP request, move a file, serve traffic at the edge, read a register from a device — there is exactly one generic verb. Which technology that verb uses is selected by a single field in your playbook:
mail.register_mailbox a source, data.register_bucket a store, or webhook.send a request — regardless of the technology behind it.protocol:, backend:, or provider: field on the same step routes the work to the right implementation. Leave it out and Binions uses a sensible default, so existing playbooks keep working unchanged.Why this matters. The playbook vocabulary never grows when a new provider is added — only the set of values a field accepts. Your automations stay readable and portable, and moving from, say, a test S3 bucket to a production SFTP drop is a one-line edit rather than a rewrite.
The integration surface is delivered by a small group of daemons. Each daemon owns one capability, exposes its generic verbs, and accepts the field that selects a provider. Here is the shape of it at a glance:
| Capability | Generic verb (example) | Selector field accepts |
|---|---|---|
| Email & messaging | mail.register_mailbox | protocol: — IMAP/SMTP, MQTT, AMQP |
| AI models | ai.classify | provider: — pluggable model providers |
| Webhooks & APIs | webhook.send | HTTP/HTTPS, with SOAP via content type |
| Storage & transfer | data.register_bucket | backend: — S3, MinIO, SFTP, FTP, local files |
| HTTP edge & realtime | traefik.register_route | protocol: — HTTP, HTTPS, WS, WSS, SSE, gRPC, gRPC-Web |
| Industrial devices | modbus.read / modbus.write | MODBUS TCP and RTU-over-TCP |
The pages below take each of these in turn — from the shared mental model, through every connector family, to a single compatibility catalogue you can scan when you are checking whether a given technology is supported.
Every integration follows the same two-layer path, which is worth holding in your head as you read the rest of this section:
Secrets stay on the host. Connection credentials — mailbox passwords, API keys, bucket secrets — are stored as protected password files on your own machine and referenced from playbooks, never written into them. Outbound HTTP calls are additionally constrained by an allow-list, so a misconfigured playbook cannot reach somewhere it should not.
Good to know. Each connector page indicates which providers are fully supported and which are planned. Check the Integration catalog for an at-a-glance compatibility picture before building against a specific provider.