PlatoForms User Guide
Ctrl+K

  • Form Builder

    Creating an Online Form for an Existing PDF

  • Custom Domain

    With Builder you can build three types of forms: online web forms, online PDF forms, and master forms.

  • Master Form Builder

    you will arrive at the Form Builder. On the form Builder, there are three main sections:

What's new? API Docs

Integrations and API

On this page

Everything the tracker shows is also available to other systems: webhooks fire as runs move, the REST API reads runs and acts on tasks, and the MCP server exposes the same to AI assistants.

Webhooks

Add a webhook and set Sends when to A workflow run or task changes under API and webhooks. It receives every workflow of the team, or only the workflows that use a given form when you pick one. Each call carries the event name, the run and, where there is one, the task and its submission id:

Event When
workflow.run.started The start form was submitted.
workflow.run.restarted A rejected run was started again from the Start again button.
workflow.task.created A step was assigned to someone.
workflow.task.completed A form step was submitted.
workflow.task.decided An approval was decided; the payload has the outcome and comment.
workflow.run.completed Every path finished.
workflow.run.rejected A send-back ended the run.
workflow.run.cancelled Someone cancelled the run in the tracker or through the API.

Form-level webhooks on the individual forms keep firing for their submissions as before.

REST API

The API v4 has read and write access to runs and tasks. All routes sit under /api/v4/:

Method and route What it does
GET workflow/<workflow>/definition/ The steps and connections of a workflow, read-only.
GET workflow/<workflow>/runs/ The workflow’s runs, filterable by status, assignee and overdue, paged.
GET workflow/run/<run>/ One run with its tasks and its timeline.
GET workflow/run/<run>/final-pdf/ The completed PDF file itself: the copy with the approval record page when there is one, otherwise the last form’s own PDF.
POST workflow/run/<run>/cancel/ Cancel a run, with an optional reason.
GET workflow/tasks/ Tasks across workflows, filterable by assignee email and status, for inbox-style clients.
POST workflow/task/<task>/decide/ Decide an approval task: the outcome and a comment.
POST workflow/task/<task>/nudge/ Resend the task’s email.
POST workflow/task/<task>/reassign/ Hand the task to an email address or a team member.

The older routes for submitting a workflow step and listing a workflow’s submissions by step are unchanged.

Who can read and act

The REST routes and the MCP tools follow the same access rules as the tracker:

  • A workflow’s runs, tasks, submission IDs, trees and run details are listed or read only for an account that is Form Submission Viewer on every form of the workflow. Any other account gets a 403 answer that says so: “You need Form Submission Viewer permission on every form in this workflow.” A workflow or run that does not exist is still reported as not existing.
  • The definition also opens for whoever may design the workflow (Form Editor on every form). GET workflows/ lists only the workflows the account may design or see.
  • Nudging, reassigning and cancelling need the same access as the tracker’s buttons; reassigning an approval also needs Form Editor on every form.
  • Deciding an approval needs the account to be the approval’s assignee.
  • An open task’s link is included only for the task’s own assignee and, on form tasks, for those who may act on the run. The answer to a nudge carries no link.

MCP tools

The PlatoForms MCP server gives AI assistants the same view: list_workflow_runs (by workflow, status or overdue), get_workflow_run, list_my_workflow_tasks, decide_workflow_task and nudge_workflow_task. Deciding a task requires the connected user to be one of its assignees, so an assistant can approve on your behalf but not on someone else’s.

Is the content helpful?
Give feedback about this article