Skip to main content
YiDA provides remote API capabilities that let you call HTTP-based asynchronous interfaces (for details, see the remote API documentation). YiDA also ships several built-in remote APIs for operating on YiDA data.
YiDA Open APIs require authentication, so they cannot be called directly from a silent-login page. Route these calls through a FaaS function or your own backend service instead.

API Usage Notes

Request Path

YiDA provides APIs at the app level. Within an app, call remote APIs (cross-app calls are supported) using the following URL format:
When writing API request code on the YiDA platform, use a relative path as shown below so that you don’t need to update your code when the organization’s subdomain changes.

Response Structure

YiDA remote APIs return the following response structure:

Form APIs

The YiDA platform offers form-type pages for collecting form data. Form APIs let you create, read, update, and delete form data. A “form instance” here refers to a single record in the form’s data set.

Create a Form Instance

  • Interface path: /v1/form/saveFormData.json
  • Request method: POST
  • Parameters (formDataJson must be serialized with JSON.stringify()):
  • Sample response:

Update Component Values in a Form

  • Interface: /v1/form/updateFormData.json
  • Request method: POST
  • Parameters:
  • Sample response:

Delete a Form Instance

  • Interface: /v1/form/deleteFormData.json
  • Request method: POST
  • Parameters:
  • Sample response:

Get Form Instance Details by Instance ID

  • Interface: /v1/form/getFormDataById.json
  • Request method: GET
  • Parameters:
  • Sample response:
For result, see Appendix 5: Form Instance Detail Object Format.

Search Form Instance IDs by Condition

  • Interface: /v1/form/searchFormDataIds.json
  • Request method: GET
  • Parameters:
  • Sample response:

Search Form Instance Details by Condition

  • Interface: /v1/form/searchFormDatas.json
  • Request method: GET
  • Permission control: This interface honors page-level permission settings (except for admins).
  • Parameters:
  • Sample response:

Get the Form Definition

This interface will be upgraded on December 1, 2024. After the upgrade, it will be available only to admins and no longer to regular users.
  • Interface: /v1/form/getFormComponentDefinationList.json
  • Request method: GET
  • Parameters:
  • Sample response:

Get Subform Data

  • Interface: v1/form/listTableDataByFormInstIdAndTableId.json
  • Request method: GET
  • Parameters:
  • Sample response:

Workflow APIs

Workflow forms are another core capability of the YiDA platform. Workflow APIs let you operate on workflow instances.

Start a Workflow

  • Interface path: /v1/process/startInstance.json
  • Request method: POST
  • Parameters:
  • Sample response:

Search Workflow Instance IDs by Condition

  • Interface path: /v1/process/getInstanceIds.json
  • Request method: GET
  • Permissions: The workflow must have the “instance viewable” permission configured (except for admins).
  • Parameters:
  • Sample response:

Get Workflow Instance Details by Condition

  • Interface path: /v1/process/getInstances.json
  • Request method: GET
  • Permissions: The workflow must have the “instance viewable” permission configured (except for admins).
  • Parameters:
  • Sample response:

Get Workflow Instance Details by Instance ID

  • Interface path: /v1/process/getInstanceById.json
  • Request method: GET
  • Parameters:
  • Sample response:

Delete a Workflow Instance

  • Interface path: /v1/process/deleteInstance.json
  • Request method: POST
  • Parameters:
  • Sample response:

Terminate a Workflow Instance

  • Interface path: /v1/process/terminateInstance.json
  • Request method: POST
  • Parameters:
  • Sample response:

Execute a Single Task

  • Interface path: /v1/task/executeTask.json
  • Request method: POST
  • Parameters:
  • Sample response:

Get Approval Records

  • Interface path: /v1/process/getOperationRecords.json
  • Request method: GET
  • Parameters:
  • Sample response:

Update a Workflow Instance

  • Interface path: /v1/process/updateInstance.json
  • Request method: POST
  • Parameters:
  • Sample response:

Task Center APIs

The YiDA platform provides a task center where you can view the task list and status of all apps in the current organization. Task Center APIs let you query the task list.

Submitted Tasks

  • Interface path: /v1/process/getMySubmitInApp.json
  • Request method: GET
  • Parameters:
  • Sample responses:
    • Success
  • Failure

To-Do Tasks

  • Interface path: /v1/task/getTodoTasksInApp.json
  • Request method: GET
  • Parameters:
  • Sample responses:
    • Success
  • Failure

Completed Tasks

  • Interface path: /v1/task/getDoneTasksInApp.json
  • Request method: GET
  • Parameters:
  • Sample responses:
    • Success
  • Failure

Tasks CC’d to Me (App Scope)

  • Interface path: /v1/task/getNotifyMeTasksInApp.json
  • Request method: GET
  • Parameters:
  • Sample responses:
    • Success
  • Failure

Appendix

Form Data Format for Save/Update

  • Every component in a form has a unique ID (visible on the “Advanced” panel to the right of the component in the page designer), and every component uses a fixed data format. The following form components are supported: single-line input, multi-line input, number, radio, dropdown select, multiselect, dropdown multiselect, date, date range, user picker, region picker, department picker, cascade select, and subform.
  • When saving or updating form data, pass the form values as a JSON string in the Map<String, Object> format. The key is the component ID, and the value is the component’s value. The value format for each component is as follows:
  • A complete form data example:
  • Every component in a form has a unique ID (visible on the “Advanced” panel to the right of the component in the page designer), and each component has its own search format. The following form components support search: single-line input, multi-line input, number, radio, dropdown select, multiselect, dropdown multiselect, date, date range, user picker, region picker, department picker, cascade select, and subform.
  • When searching, use the Map<String, Object> format to express the search condition for each component. The key is the component ID, and the value is the search value for that component. The search type and value format for each component are as follows:
  • A complete example:

Workflow Instance Detail Object Format

  • Every component in a form has a unique ID (visible on the “Advanced” panel to the right of the component in the page designer), and each component has its own search format. The following form components support search: single-line input, multi-line input, number, radio, dropdown select, multiselect, dropdown multiselect, date, date range, user picker, region picker, department picker, cascade select, and subform.
  • When searching, use the Map<String, Object> format to express the search condition for each component. The key is the component ID, and the value is the search value for that component. The search type and value format for each component are as follows:
  • A complete data format demo:

Form Data Format as a Response Value

The form data format for response values is essentially the same as Appendix 1: Form Data Format for Save/Update, with the following differences:
  • On input, the region component value is [“Province ID”, “City ID”, “District ID”]. In responses, it is [“Province name”, “City name”, “District name”].
  • Radio, dropdown select, multiselect, and dropdown multiselect components support internationalization. Responses return the data value that matches the language parameter you pass.

Form Instance Detail Object Format

  • A complete data format demo: