Product Launch: bem Integrations

Today, we are excited to launch bem Integrations, so that every folder becomes an unstructured data workflow.

Loss runs sit in a shared SharePoint. Bills of lading drop into a vendor's S3 bucket. Invoices land in a Google Drive folder a controller has been curating for years. The data has always been in motion. The problem has never been finding it. The problem has been the engineering tax between "the file exists" and "the structured record landed in the system that needed it."

Most teams pay that tax in one of three ways: a cron job that polls a folder every five minutes, a Lambda that fires on an S3 event and parses the file in-line, or a person who manually drags files into a tool. Each one is technically a working pipeline. Each one is also a small piece of infrastructure that has to be owned, monitored, and replaced when someone leaves.

Integrations remove that tax. They are native, no-code connectors that wire bem workflows directly to the file and blob storage providers your team already uses. New files in a folder automatically trigger a workflow. Structured output flows back to a folder, a bucket, or a webhook. No polling, no custom delivery layer, no glue code that gets stale the first time the source schema changes.

Five providers ship today: Google Drive, Dropbox, SharePoint, Box, and AWS S3.

Sources: any folder becomes a workflow trigger

Open any workflow. In the top right, click Connectors, then Add Connector. Name it, pick a provider, choose a folder. That's the entire setup.

From that moment forward, every new file that lands in that folder runs your workflow. bem subscribes to the provider's native event stream (Google Drive changes, S3 object-created events, Dropbox webhooks, SharePoint subscriptions, Box events) and ingests the file the instant it appears. There is no polling interval to tune, no Lambda to deploy, no retry loop to maintain.

A few things that fall out of this for free:

• Existing folder structure becomes your routing layer. Loss runs land in one Drive folder, ACORD 125s land in another, each pointed at its own workflow. The folder is the route.
• Existing access controls hold. The OAuth grant scopes bem's access to the folders you select. Nothing else moves.
• Existing file lifecycle holds. You keep the originals where they are. bem reads, it does not relocate.

If your team already has storage conventions for "where new documents go," Integrations turns those conventions into infrastructure.

Destinations: workflow output goes back where work happens

Sources are half of the equation. The other half is where the structured output lands.

Every workflow can terminate in a Send node. Send accepts a destination:

• A folder in Google Drive (the JSON output appears as a file, written via the same OAuth grant you set up as a source)
• An S3 bucket and key prefix (slot directly into a data warehouse staging area)
• A webhook (push to your application, an event bus, or an agent's tool runtime)

This means you can build pipelines where the operator never leaves their existing tooling. A vendor drops an invoice into a Drive folder. bem extracts the structured fields. The output JSON appears in a "processed" sibling folder, where a Sheet or a downstream app picks it up. The whole loop runs without anyone opening bem.

For warehouse-shaped workloads, point Send at an S3 prefix. Your Airflow, Snowpipe, or dbt source already watches that prefix. The structured output joins the same pipeline as every other dataset you ingest. bem becomes the "unstructured → structured" stage of an existing ELT graph instead of a parallel system that needs its own integration.

For agent-shaped workloads, point Send at a webhook. The agent receives verified, schema-enforced JSON the moment a workflow completes, with the same per-field confidence scores you get from a direct V3 API call. The agent does the open-ended reasoning. bem does the deterministic part.

How to set it up

The connector lives one menu away from where you already are.

1. Settings → Integrations → Connect. Pick a provider, complete the OAuth flow, done. The connection is reusable across every workflow on your account. 2. In your workflow, top right → Connectors → Add Connector. Choose the connected provider, select the source folder. New files in that folder trigger the workflow from now on. 3. On the workflow's terminal node → Send. Pick a destination type (Drive folder, S3 bucket, webhook), select the target. Every successful run writes structured output to that target.

That is the entire surface. Three clicks per side, one OAuth grant per provider, zero infrastructure to own.

Connectors are also a first-class property of a workflow on the V3 API, so you can define them in code alongside the rest of your pipeline. Same shape, same versioning, same Terraform-provider story as every other V3 resource.

Once a workflow is connector-attached, the same execution graph is also reachable on demand from the API:

1curl -X POST "https://api.bem.ai/v3/workflows/invoice-processing/call?wait=true" \
2  -H "x-api-key: $BEM_API_KEY" \
3  -F "callReferenceID=inv-001" \
4  -F "file=@invoice.pdf"

Connector-driven runs and direct calls execute the same workflow. Whatever you can do in the UI, you can do from the SDK, the V3 API, or the Terraform provider.

What this unlocks

A few patterns we are already seeing in early use:

Vendor document intake. A folder per vendor in Drive. Each folder is the source for a workflow tuned to that vendor's format. The Send node lands structured records in a Sheet the ops team already uses. Onboarding a new vendor is a folder, not a project.

Insurance loss runs. Carriers email loss runs into a shared SharePoint inbox. The inbox folder is the source. Send pushes the parsed runs to an S3 prefix that the underwriting warehouse already watches. The data engineering team gets one more clean Parquet source. The underwriting team gets faster decisions. Nobody had to integrate with anybody.

Agent toolchains. A research agent drops a long PDF into a designated Drive folder. bem extracts the structured facts. The output webhook fires back into the agent's context. The agent gets verified, schema-shaped data without writing parsing code or trusting the model to read the document itself.

The pattern repeats. Storage is where work already happens. Integrations makes that storage a first-class input and output of bem.

The bigger picture

V3 was about making the API smaller, sharper, and SDK-native. Integrations is about making bem invisible to the systems and people who feed it.

The most reliable production pipeline is the one that nobody has to babysit. If your operators drop files in folders, your pipeline drops files in folders. If your warehouse reads from S3, your pipeline writes to S3. If your agent talks to webhooks, your pipeline talks to webhooks. The job of the production layer is to disappear into the work, not to be the work.

That is what we keep building toward. Verified extraction, available everywhere your team already operates, governed by the same security model and the same per-field confidence guarantees that ship with every other bem function.

Get started

• Set up an integration in the dashboard at bem.ai, Settings → Integrations.
• Read the docs at docs.bem.ai/integrations.
• See it in action. The launch tutorial is up on our YouTube channel.
• Talk to the team. Book a call.

Integrations is GA for every account today. If you have a workflow already running on bem, the connector menu is in the top right.

Files in. Data out.