--- title: "Noloco Integration" description: "Noloco is a no-code internal app builder, and every app gets its own GraphQL API. Workflows list, create, update, and delete records, describe tables, and run raw queries against the app's data." url: https://flowrunner.ai/integrations/noloco date_modified: 2026-09-04T14:59:52-07:00 --- # Noloco [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) Noloco is a no-code internal app builder, and every app gets its own GraphQL API. Workflows list, create, update, and delete records, describe tables, and run raw queries against the app's data. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 8 actions · API key · available [Noloco website](https://noloco.io/) · [Platform Documentation](https://noloco.io/) · Capability data verified 2026-08-25 1. An approved request arrives from an upstream system 2. Agent pulls the values the internal app's table is expecting 3. List Tables reports the app's real query names, which Noloco derives from your own table names 4. Describe Table returns the exact field names and types the write has to match 5. The agent compares the payload against the fields the app treats as required 6. Create Record writes the row when nothing is missing 7. An incomplete payload stops here, and the queue owner supplies what the API would have accepted in silence ## What This Integration Enables Noloco's usefulness is that it makes an internal tool that ops people actually use. Not a dashboard, not a report, an app with a queue, records, and a view somebody works out of all day. What makes it automatable is that every Noloco app gets its own GraphQL API, named after your tables rather than after Noloco's. There is no fixed operation set here, because there is no fixed schema. `projectsCollection` and `createUser` exist because you built a Projects table and a User table. That is why the two schema operations matter more than they look. List Tables reads the real names out of the app by introspection instead of guessing them from what the interface shows, and Describe Table gives the exact field names and types that decide which filters a field will accept. Run those first and the record operations become straightforward: agents pull work into the app, enrich rows as new facts arrive, and close them out when an upstream system says so. The agent and the team are then looking at the same rows, which is the whole reason to write into the internal app instead of alongside it. The one thing FlowRunner will not do unattended is a write that cannot fail, and the [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) section explains why that is the operation worth stopping on. ### Without FlowRunner **Two copies of the truth**: The automation writes to a spreadsheet, the team works in the app, and the two drift apart **Guessed field names**: Query names come from table names with inconsistent pluralization, so writes fail on a naming detail **Rows that look fine to the API**: A create missing a field the app requires still succeeds, and the gap shows up in front of a person ### With FlowRunner **One set of rows**: Agents read and write the same records the team is looking at in the app **Schema read, not assumed**: Introspection reports the real table and field names before anything is written **Completeness checked before the write**: The agent compares its payload against the app's own field list and stops when something is missing ## Use Case Scenarios ### The queue fills itself A new order lands in [Shopify](https://flowrunner.ai/integrations/shopify), a payment clears in [Stripe](https://flowrunner.ai/integrations/stripe), or a deal closes in [HubSpot](https://flowrunner.ai/integrations/hubspot). The agent calls Describe Table on the app's fulfillment table, maps the incoming fields to the ones the app actually defines, and calls Create Record. The ops team opens their Noloco app in the morning and the queue is already populated with the context they would otherwise have gathered by hand. The record carries the source system's identifier as a field, which is what makes the next scenario possible. ### Enrichment that never creates a second row As facts arrive later, a tracking number, a signed document, a support ticket reference, the agent calls Get Record against the external identifier rather than a Noloco id. That works because the lookup accepts any field the table marks unique, so a workflow holding an order number or an email can address the row directly instead of filtering a collection. Update Record then touches only the fields it sends and leaves the rest alone, which is exactly the behavior a sync workflow wants. The person working the queue sees the record fill in during the day without anyone opening a second tool. ### Reporting across relationships in one call Weekly, the agent uses Run GraphQL Query with a query written against this app's own schema, pulling records from several tables and following relationships several levels deep in a single request that no generic list operation could express. The result lands in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) for the operations review and a summary posts to [Slack](https://flowrunner.ai/integrations/slack). Because every Noloco app has a different schema, a query written against yours can do things no fixed operation set can, which makes this the right escape hatch rather than a last resort. ## Human-in-Loop Highlight Noloco's API treats every field as optional. Not the fields your app treats as optional, every field. Noloco only insists on the ones marked unique, so a Create Record call missing the customer name, the due date, and the assigned owner returns a successful response and puts a row in the table. The API is satisfied. The person who opens that record tomorrow is not, and there is no error anywhere that would have warned anybody. So the intake agent does not write blind. It calls Describe Table, compares its payload against the fields the app's own interface treats as required, and when something is absent it stops: "Creating a fulfillment record for order 88214. Ship-by date and account owner are empty. The API will accept this row as it stands. Fill them in, or write it as a draft for the queue owner to complete?" The operations lead answers in the channel and the agent proceeds. This is the unusual case where the gate exists not because the operation is irreversible, but because it cannot fail loudly enough to be noticed. 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 8 actions ### Records 5 - **List Records** Fetches records from one of the app's tables. The connector flattens Noloco's relay-style response into plain records while still returning the paging information, and converts filters and sort orders into the GraphQL literal form the endpoint requires. - **Get Record** Fetches a single record by a unique value. It does not have to be the id: any field the table marks unique works, so a workflow holding an email or an external reference can look a record up directly. - **Create Record** Creates a record in one of the app's tables. Every field is optional to the API, including ones your app treats as required, which is what this page's human gate is for. - **Update Record** Changes a record's fields. Only the fields you send are touched, which is what a sync workflow wants. Sending a field with an empty value clears it, which is not the same as omitting it. - **Delete Record** Deletes a record. Permanent, since Noloco has no trash for API deletes. The response can still return the deleted record's fields, which is the only chance to capture what went. ### Schema 3 - **List Tables** Returns the app's tables by GraphQL introspection. The operation that makes the rest usable, because query names are derived from table names and Noloco does not pluralize them consistently. - **Describe Table** Returns a table's fields with their GraphQL types. What to call before composing a field selection or a values object, and what decides which filter operators a field will accept. - **Run GraphQL Query** Sends any query or mutation to the app's endpoint. Because every Noloco app has a different schema, a query written against yours can fetch several tables at once or follow relationships several levels deep in one request. ## Frequently Asked Questions ### What can FlowRunner do with Noloco? FlowRunner agents can run List Records, Get Record, and Create Record in Noloco, plus 5 more actions. ### Does connecting Noloco to FlowRunner require OAuth? No. Noloco connects to FlowRunner with an API key, no OAuth flow required. ### Can Noloco trigger a FlowRunner workflow automatically? Noloco doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Noloco?** This integration exposes Noloco to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/noloco. Site index: https://flowrunner.ai/llms.txt