Forms, submissions, dispatches, customers, sites, projects, users and webhooks in GoCanvas.
GoCanvas ships in the w6w first-party pack. It declares 50 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.gocanvasGoCanvas is a mobile forms and field-data platform: teams design a Form once, field staff fill it in on a phone or tablet, and every completed Form becomes a Submission that can be reported on, routed through a Workflow or pushed to another system.
This app covers the GoCanvas REST API v3. A workflow can read the Forms a company has published and the Submissions captured against them, create or correct a Submission from another system, and Dispatch a pre-filled Form to a specific mobile user (immediately, on a schedule, or on a recurring schedule). Around that sit the records a Form hangs off: Customers, Sites and Projects, Departments, Users, Groups and Reference Data.
Webhooks are managed per Form, so a workflow can subscribe an endpoint to submission, dispatch and handoff events and send a test payload before relying on it. Authentication is the HTTP Basic login of a GoCanvas user, so use a dedicated API user whose role carries only the rights the workflow needs.
Three routes to the same 50 actions. The Workflow tab is generated from GoCanvas's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
customer-create Create a customer. customer_type is required: an individual needs a first and last name, a business needs a business name.
customer-delete Soft-delete a customer (hidden from the web views, data kept), or permanently delete it with Delete permanently.
customer-update Update a customer. Only the fields you set are sent. Pass siteIds to attach sites (the first is the primary site unless a default site is given).
department-user-add Add an existing user to a department with a role. If the user is already in it, the role is updated and the response says already_existed.
dispatch-create Send a pre-filled form to a mobile user: immediately, at a scheduled time, or on a recurring schedule. responses pre-populate the assignee's submission ({ entry_id | entry_guid, value }). Media fields cannot be dispatched. Scheduled times use "MM/DD/YYYY HH:mm:ss AM".
dispatch-delete Soft-delete a dispatch (removed from mobile task lists, data kept), or permanently delete it.
dispatch-list List dispatches. One of user id, department id or form id is required.
form-get Fetch a form definition. flat is what most clients want (one object with everything needed to render the form); minimal lists the entry ids a Submission or Dispatch needs; nested is the full builder shape; metadata names the published version.
form-list List the forms the user can access. Managers see every form they can manage; everyone else only their assigned forms.
form-user-unassign Remove a user's assignment to a form. They can still finish submissions they already hold.
me-get Profile of the authenticated user: id, name, login, company and default department. Use it to find the company id and default department id.
project-create Create a project. Only the name is required; without a department the user's default department is used.
project-delete Soft-delete a project, or permanently delete it with Delete permanently.
project-list List the projects of a department the user can access (Project Management View only).
reference-data-get Fetch one reference data set with its rows. rows_with_index adds a gc_row_index column, which is what an update needs to address rows.
reference-data-list List reference data sets (the spreadsheet-like lookups behind dropdowns). Returns headers and column indexes, not rows.
site-create Create a site (a physical location where work is done). Only the name is required.
submission-create Create a text-only submission against a form. responses is a list of { entry_id | entry_guid, value, multi_key? } objects (get entry ids from Get Form with format minimal). Photos, videos and attachments need multipart upload and are not supported here. The guid is the vendor's duplicate guard, defaulting to this invocation id so a retry is not created twice.
submission-delete Soft-delete a submission (kept, hidden from the web views) or permanently delete it. Accepts a numeric id or a GUID.
submission-get Fetch a submission with its responses, by numeric id or by GUID. Media responses read "Binary data is not displayed".
submission-list List submissions. One of form id, user id or user email is required; the form id matches every version of the form. Defaults to completed submissions.
submission-revision-list List the revision history of a submission, newest first. Empty for a submission that was never edited.
submission-update Change values on an existing submission (PATCH). responses is a list of { value_id | entry_id, value, delete?, updated?, multi_key? }; an empty value clears a response. edit_guid makes a retry safe: the same edit_guid is applied once. Assign, claim, unassign and workflow handoffs ride on the same call.
user-create Create a user. Needs an email, first and last name and a department role; when Departments are enabled a department id is required too. Without a password GoCanvas emails a set-your-password link.
user-update Update a user's name, phone or enabled flag. Enabling a user needs a free seat.
webhook-create Subscribe a URL to a form event. dispatch_create needs Dispatch enabled on the form, workflow_handoff_create needs Workflow, submission_custom_status_change needs Submission Status. xml is only valid for submission_create.
webhook-test Send a test payload to the webhook's URL and report the response code and body the endpoint gave back.
webhook-update Change a webhook's event, format, URL or tag. Only the fields you set are sent.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying GoCanvas's real ids.
{
"manifestVersion": "2",
"name": "gocanvas-example",
"steps": [
{
"id": "customer-create",
"uses": {
"app": "io.w6w.gocanvas",
"action": "customer-create",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"customerType": "<customerType>"
}
}
]
}customer-create customer-get customer-list customer-update department-create +45 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for GoCanvas, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to GoCanvas. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "customer-create",
payload: {
customerType: "<value>",
// businessName: "<value>",
// contactRole: "<value>",
// contactFirstName: "<value>",
// contactLastName: "<value>",
// contactEmail: "<value>",
// contactPhone: "<value>",
// contactPreference: "<value>",
// notes: "<value>",
// code: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action customer-create --payload '{"customerType":"<value>"}' Give an AI agent GoCanvas — without giving it GoCanvas's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.gocanvas#customer-create",
"input": {
"customerType": "<customerType>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's GoCanvas connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
GoCanvas's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. GoCanvas itself is MIT, and the runtime that executes it is source-available (FSL).
GoCanvas declares its own checks, so its health is a property of the app rather than something the host guesses at.
Open incidents on GoCanvas's status feed (status.gocanvas.com). Incidents for the EU and AU regions are ignored, because this app talks to the US platform. Unsigned; fetched and parsed by the host.