Ycode
CMS & ContentConnect AI agents to Ycode, a no-code website builder with a built-in CMS. Agents create, update, and delete CMS collection items and read or create form submissions so site content and lead capture stay synced with the rest of the stack.
What This Integration Enables
Ycode's API is unusually honest about what a no-code site actually is: two tables. One holds what you publish, the CMS collections behind your pages. The other holds what visitors send you, the form submissions. Most site builders let an agent write only the first. Ycode lets it write both, and that changes what the connector is for. This is not just a content integration, it is the seam between a marketing site and everything behind it.
Two behaviors deserve to be understood before an agent touches a live project. Create Collection Item publishes automatically; there is no draft state to stage into, so the create is the publish. And Replace Collection Item is a full replacement that sets any field you omit to null, which is why Update Collection Item exists for partial changes and should be the default in any sync. Both facts push the human-in-the-loop moment earlier in the flow than teams expect. The agent assembles, checks, and shows its work before the call, because after the call there is nothing to unpublish, only something to delete.
Without FlowRunner
With FlowRunner
Use Case Scenarios
An upstream catalog publishing itself onto the site
Product records live in Airtable and the public listing pages live in a Ycode collection. When a record is marked launch ready, the agent calls Get Collection to read the collection's field slugs, maps the record onto them, and calls List Collection Items with an exact match filter to check that the slug is not already taken. Then it posts the assembled field values into the marketing channel and waits, because Create Collection Item goes live on the spot. Once confirmed, the item is created and the page exists. Later edits go through Update Collection Item so a change to a price never clears the hand written description sitting next to it.
Form submissions routed into the systems that act on them
A visitor submits the contact form. On a schedule, the agent calls List Form Submissions for that form, reads the new entries with Get Form Submission, and creates or updates the matching contact in HubSpot with the field values keyed by slug. High intent submissions go to the sales channel in Slack with the message body attached; the rest are queued. The site stops being a place leads go to sit and starts being an input to the pipeline.
Backfilling leads from a retired form provider
A team moves off an old form tool and wants the historical submissions to live where the new ones do. Create Form Submission makes this possible, and that is exactly why it needs supervision. The agent maps the export onto the Ycode form's slugs with Get Form, counts how many records the backfill would write, and stops before writing any of them. What happens next is below.
Human-in-Loop Highlight
Create Form Submission writes into the same store where real visitors land, and nothing in the record distinguishes an agent written submission from a human one. There is no operation in this connector to delete a submission, so once a synthetic record is in the form store it stays there, counted in every export, every report, and every follow up sequence that reads from it. A backfill that looks tidy on Monday is a lead list nobody trusts by Friday.
So before the agent writes any submission it did not receive from a live visitor, it stops and asks the person who owns the lead record: "This backfill would write 340 submissions into the [form name] form. These records cannot be deleted through the API and will be indistinguishable from live submissions. Write them, write them with a source field set to the old provider, or leave the history where it is?" The answer decides whether the lead store stays a record of what actually happened. On the collection side the agent applies the same instinct to Delete Collection Item, which permanently removes the item and the page at its URL. Agents can fill a site with content. What goes into the record of who contacted you is a person's decision.
Agent Capabilities
13 actionsCollections
2- List Collections Retrieves all CMS collections in the project with their identifier, name, and slug. Used to discover what a project holds before reading or writing items.
- Get Collection Retrieves a single collection by ID including its field definitions, the field slugs and types. Used to build the mapping between an upstream record and the collection before any write, since every write is keyed by field slug.
Collection Items
6- List Collection Items Lists items with pagination, sorting, and exact match filtering, up to 1000 per page, returning a pagination object with page, per page, and total. Used to check whether a slug is already taken and to walk a collection during a sync.
- Get Collection Item Retrieves a single item by ID, returning its field values as a flat object keyed by field slug. Used to read the current state of an item before changing it.
- Create Collection Item Creates a new item in a collection and publishes it automatically. Field values are supplied as a flat object keyed by field slug. Because there is no draft state, an agent should confirm the assembled values before this call rather than after it.
- Replace Collection Item Fully replaces an existing item with the supplied field values. Any field not included is cleared and set to null, so the request must carry the complete set of values. Used for authoritative overwrites where the upstream system genuinely owns every field.
- Update Collection Item Partially updates an existing item, changing only the fields supplied and leaving the rest untouched. The safer default for any recurring sync, because it cannot silently clear a field an agent does not know about.
- Delete Collection Item Permanently deletes an item by ID, removing the page at its URL. There is no undo, so an agent should confirm the item ID and the consequences of the missing URL before calling it.
Forms
5- List Forms Retrieves all forms in the project with their identifier, name, and slug. Used to resolve a form by name before reading or writing submissions.
- Get Form Retrieves a single form by ID including its field definitions. Used to inspect the schema before mapping submissions in either direction.
- List Form Submissions Lists submissions for a form with pagination, returning a pagination object with page, per page, and total. Used to pull new leads on a schedule and hand them to the CRM.
- Get Form Submission Retrieves a single submission by ID with its field values keyed by field slug. Used to read the full message body and any custom fields before routing.
- Create Form Submission Creates a new submission for a form from supplied field values. Used for migrations and recovered leads, and gated, because the record it writes is permanent and indistinguishable from a live visitor submission.
Frequently Asked Questions
What can FlowRunner do with Ycode?
FlowRunner agents can run List Collections, Get Collection, and List Collection Items in Ycode, plus 10 more actions.
Does connecting Ycode to FlowRunner require OAuth?
No. Ycode connects to FlowRunner with an API key, no OAuth flow required.
Can Ycode trigger a FlowRunner workflow automatically?
Ycode doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Ycode
$100 in credits. No card required. Connect in minutes.