Fibery

Work with your Fibery workspace at the schema level. Agents discover databases, query entities with filters, create, update, and delete records, and run raw Fibery commands for anything the dedicated operations do not cover.

7 actions API key available

Fibery website ↗ Platform Documentation ↗ Capability data verified 2026-07-28

New customer feedback arrives through a form or support channel overnight

List Databases confirms the exact type name and fields of the Feedback database at runtime

Create Entity files each response into the Feedback database with source and customer relations set

Query Entities pulls open features touched by the new feedback for cross-referencing

The agent flags feedback that matches no existing feature as a candidate for a new entry

The product manager reviews the candidates and decides which become features and which get merged

Update Entity links the approved feedback to its feature, and the workspace graph stays connected

What This Integration Enables

Fibery is a relational workspace: product work, CRM records, projects, and knowledge all live as typed entities with real relations between them. That structure is exactly what makes it a strong substrate for agents, and exactly what makes naive automation against it brittle, because every type and field name is namespaced and every workspace's schema is its own. This connector handles both halves. FlowRunner agents discover the schema at runtime with Get Schema or List Databases, read entities through the Fibery query DSL, write with Create Entity and Update Entity, and drop to Run Commands for filtered queries, batch operations, and anything else the full command API covers. The position: a connected workspace is only as good as its freshness, and freshness is agent work. Humans design the schema and make the calls that shape it; agents keep the entities flowing. - File form responses, emails, and support feedback as entities in the right database - Mirror issues and work items from engineering tools into product databases - Pipe entity queries into digests, reports, and downstream automations - Run advanced filtered and batch operations through the raw command escape hatch - Survive schema evolution, because type and field names are discovered, not hardcoded This is a gated, genuinely complex integration: Fibery's API is command-based rather than REST, and using the entity operations well means understanding its command model and query DSL.

Without FlowRunner

The workspace and reality drift Features, bugs, and feedback live in Fibery, but new information reaches it days late, by hand

Cross-tool mirroring is a chore Engineering work in one tool and product records in another get reconciled in someone's head

Schema knowledge is tribal Only the workspace admin knows the exact type and field names automations would need

With FlowRunner

Records file themselves on arrival Forms, emails, and external systems write straight into the right database with relations intact

Mirrors update both directions Issues and features sync across tools on a schedule, keyed by id, without a human courier

Agents discover the schema at runtime Workflows read type and field names from the workspace itself, so schema changes do not break them

Use Case Scenarios

Feedback lands filed, related, and findable

A response arrives in [Typeform](/integrations/typeform). The agent resolves the Feedback database's exact namespaced type with List Databases, then calls Create Entity with the response text, submitter, and a relation to the matching customer record. Because relations are set at creation, the feedback is immediately visible from the customer's entity and from any feature it references. Nobody copies survey responses into the workspace on Friday afternoons anymore.

Engineering reality mirrored into product truth

On a schedule, the agent pulls issues from [Linear](/integrations/linear) and reconciles them against the connected Fibery database: Query Entities fetches the existing mirrors, new issues become Create Entity calls, changed ones become partial Update Entity calls keyed by fibery/id. Product managers see engineering status inside the workspace where roadmap decisions happen, and the mirror never depends on anyone remembering to update two tools.

The weekly digest straight from the query DSL

Every Friday, the agent runs a filtered read through Run Commands with a q/where clause: features whose state changed this week. The result posts to [Slack](/integrations/slack) as a shipped-and-moved digest with links back to each entity. The same query pattern feeds a metrics row into a reporting sheet. The team gets the workspace's answer to "what happened this week" without anyone building a report view or exporting anything.

Human-in-Loop Highlight

Delete Entity does not archive. It permanently removes the entity from the workspace, and in a relational tool that entity is rarely alone: a deleted feature takes its position in the dependency graph with it, and the feedback, comments, and relations that pointed at it now point at nothing. The obvious automation, "when the source record disappears, delete the mirror," is exactly where this goes wrong, because source systems produce false deletions all the time. So FlowRunner agents queue deletions instead of executing them: the agent gathers the target's fields and relation counts with Query Entities, presents what would be lost, and the workspace owner confirms before Delete Entity runs. Run Commands gets the same gate whenever a batch contains a delete or a schema-touching admin command, since a one-line command array can modify hundreds of entities in a single call. Everything reversible runs free. The unrecoverable waits for a person.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

7 actions

Schema

Get Schema Retrieves the full workspace schema: every database with its fields, data types, relations, and metadata. The authoritative source for the exact namespaced identifiers that reads and writes require.
List Databases Returns a simplified list of user-facing databases with exact type names and field names, system types excluded. The lighter discovery step for most workflows.

Entities

Query Entities Reads entities from a database using the Fibery query DSL: type name, namespaced fields to return, order, limit, and offset. For filtered reads with q/where, use Run Commands.
Create Entity Creates an entity in a database from a fields object keyed by namespaced field names. The fibery/id is generated automatically, and relation and enum fields take related entity ids in the shape the schema defines.
Update Entity Updates an entity by fibery/id, changing only the fields included in the call. The partial-update primitive behind every sync and enrichment flow.
Delete Entity Permanently deletes an entity by fibery/id. Removal, not archival, and it cannot be undone. The action this page's human gate exists for.

Advanced

Run Commands Sends a raw batch of Fibery API commands to the commands endpoint and returns the per-command result array. The escape hatch for filtered queries, batch create, update, and delete, and admin operations, sent verbatim as documented in the Fibery API.

Frequently Asked Questions

What can FlowRunner do with Fibery?

FlowRunner agents can run Get Schema, List Databases, and Query Entities in Fibery, plus 4 more actions.

Does connecting Fibery to FlowRunner require OAuth?

No. Fibery connects to FlowRunner with an API key, no OAuth flow required.

Can Fibery trigger a FlowRunner workflow automatically?

Fibery doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Fibery

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us