Integrations
Flexkit does not ask you to replace the systems you already run. Your store, payment provider, mailbox, documents and internal services stay where they are; Flexkit connects to their data in one of two ways:
- Use it in place. The agent reads and acts on the external system when a task needs it, through a plugin or a custom tool. Nothing is copied ahead of time.
- Bring it into your records. Data becomes Flexkit records that your schema models, Studio shows and every API serves, through the GraphQL API, a bulk import, an automation webhook or a request to the agent.
Choose a connection
Connect an account once; Chat and automations can then search, read and act on that service.
Run your own server code when the agent needs a system no plugin covers.
Read and write records from any application, generated from your schema.
Give your own AI client the same schema search, queries and mutations the Flexkit agent uses.
Use external data in place
Plugins connect a hosted service to the project’s agent. Connect an account in Studio → AI → Plugins, with a sign-in, a token or app credentials, and every chat can use it immediately; automations use the plugin tools you attach. Ask “which Shopify orders from last week are still unfulfilled?” or “summarize the Notion launch plan” and the agent calls the service directly. Credentials stay encrypted on the platform, and writes to the external service wait for approval unless an automation is set to Auto-approve or a reviewer chose to always allow that tool.
Custom tools cover everything else: a private warehouse API, a legacy ERP, a pricing engine. You write the tool in TypeScript next to flexkit.config.ts and serve it from your own application, so it can reach systems that are never exposed to the internet. Flexkit calls it through a signed request.
In Chat, the agent works within the signed-in member’s role and spaces and uses their accounts first. A triggered automation has no requesting member: it uses the account selected in its settings, so give project accounts only the access unattended runs should have. Plugin and tool results are not stored as records unless you ask.
Bring data into your records
Sync from your systems. A server process calls GraphQL mutations with an API token to create and update records as data changes in the source system. Use a stable unique attribute, such as a SKU or external ID, so repeated syncs update records instead of duplicating them. Combine it with outgoing webhooks for two-way sync.
Import in bulk. flexkit import loads entities, relationships and referenced files from an NDJSON file, a directory or an export archive. Use it for the initial load from a spreadsheet or another platform, then switch to API sync. See import and export to validate a round trip first.
Upload files. The Assets API accepts file bytes and returns an asset you link to records. flexkit assets transfers files in bulk.
Let the agent do it. An automation with a webhook trigger gives an external system a URL to post events to; the agent reads the payload and creates or updates records following your instructions. In Chat, you can also ask the agent to copy plugin data into records (“create a Supplier record for each vendor in the Notion Suppliers database”). Data changes made by the agent go through the mutation review.
Connect an AI client. The project’s MCP server lets Claude, Cursor and other clients search the schema, query and write records with the user’s own permissions.
Send data out
Outgoing webhooks notify your receiver when records are created, updated or deleted. Automations can deliver their results to Slack or Microsoft Teams channels, and plugin tools can write to a connected service, for example a Gmail draft or a Shopify fulfillment, after approval. Any application can read records through the GraphQL API.
Before you connect
Every connection is separate from Flexkit access. Connecting an external account does not grant anyone project data access, and a Flexkit role does not grant access in the external service. Give API tokens, plugin accounts and app credentials the narrowest permissions the work needs, test in a development project first, and keep tokens, secrets and customer data out of screenshots and support reports.