# E10 Internal Read-Only APIs

These APIs are E10 management UI backend APIs, not external OpenAPI endpoints. Use them only inside an authenticated browser session to read metadata needed for documentation. Do not expose these paths, request bodies, response fields, database table names, or internal IDs in the final external-facing documentation.

## Use cases

Use these APIs after login to avoid fragile UI navigation when discovering workflow fields:

1. Get workflow list and target `workflowId`.
2. Search form list and target `formId`.
3. Read form metadata and detect detail tables.
4. Read main-table and detail-table field definitions.

All examples use `fetch()` inside the browser session, so the authenticated session cookie is included automatically.

## 1. Get workflow list

Endpoint:

```text
POST /api/bs/workflow/pathdef/baseSet/getBaseInfoListTree
```

Request body:

```json
{
  "searchParams": {
    "otherSearchDatas": {
      "workflowType": "",
      "workflowId": "",
      "subCompanyId": ""
    }
  },
  "isTemplate": 0,
  "belongType": 1
}
```

Important response fields:

- `data.datas[].typeName`: workflow category.
- `data.datas[].children[].id`: workflowId/pathSetId.
- `data.datas[].children[].title`: workflow display name.

Browser snippet:

```python
import json
result = json.loads(js('''
(async () => {
  let resp = await fetch("/api/bs/workflow/pathdef/baseSet/getBaseInfoListTree", {
    method: "POST",
    headers: {"Content-Type": "application/json"},
    body: JSON.stringify({
      searchParams: { otherSearchDatas: { workflowType: "", workflowId: "", subCompanyId: "" } },
      isTemplate: 0,
      belongType: 1
    })
  });
  return JSON.stringify(await resp.json());
})();
'''))
```

## 2. Search forms

Endpoint:

```text
POST /api/workflow/core/form/formmanage/getFormList
```

Request body:

```json
{
  "module": "workflow",
  "pageNo": 1,
  "pageSize": 50,
  "name": "<CORE_WORKFLOW_KEYWORD>"
}
```

Important response fields:

- `data.pageDatas.result[].id`: formId.
- `data.pageDatas.result[].name`: form name.

Workflow names may include numbering or prefixes, while form names often do not. Search by core business keyword rather than exact full workflow title.

## 3. Get form metadata

Endpoint:

```text
POST /api/workflow/core/form/formmanage/getForm
```

Request body:

```json
{
  "module": "workflow",
  "form": {
    "id": "<FORM_ID>"
  }
}
```

Important response fields:

- `data.name`: form name.
- `data.tableType`: form table type.
- `data.detailTable`: detail table metadata when available.
- `data.tableName`: internal database table name. Use only for internal reasoning and never include it in final external documentation.

## 4. Get field definitions

Endpoint:

```text
POST /api/workflow/core/form/field/manage/getFormFieldPage
```

Request body:

```json
{
  "pageNo": 1,
  "pageSize": 100,
  "module": "workflow",
  "formFieldSearchEntity": {
    "isDelete": 0,
    "status": "enable",
    "formId": "<FORM_ID>"
  }
}
```

If needed, add `formTableId` to target a specific main or detail table. If passing `formTableId` returns zero records for the main table, retry without `formTableId`.

Important response fields:

- `title`: business field display name.
- `dataKey`: request payload field key.
- `fieldId`: internal field ID. Usually not exposed unless the OpenAPI payload explicitly requires it.
- `type`: E10 component/API field type.
- `showOrder`: display order.
- `groupName`: internal UI group. Use only to infer business grouping; do not copy it blindly.
- `columnName`: internal database column. Never include in external documentation.
- `formTableId`: table ID, useful for follow-up field queries.

## Type mapping for external documentation

| E10 type | External description | Common payload guidance |
|---|---|---|
| Employee | Personnel field | Use `dataOptions`, `type: "resource"`, and `userType` such as `JOB_NUM`, `EMAIL`, `MOBILE`, `idNos`, `loginID`, or `account`. |
| Department | Department field | Use `dataOptions`, `type: "department"`, and `deptType` such as `DEPT_CODE` or `DEPT_NAME`. |
| SubCompany | Sub-company field | Use `dataOptions`, `type: "subcompany"`; prefer an external organization code when supported. |
| Date | Date | Use ISO-like date string such as `2026-05-27`. |
| Text | Single-line text | Use `content` string. |
| TextArea | Multi-line text | Use `content` string. |
| File | Attachment | Upload file first, then reference upload result in `dataOptions`. |
| EBuilder | Related e-builder object | Use documented option/object mapping. Mark as needing confirmation if not clear. |
| Flow | Related workflow | Use documented option/object mapping. Mark as needing confirmation if not clear. |
| Document | Related document | Use documented option/object mapping. Mark as needing confirmation if not clear. |

## Alternative formId discovery

If `getFormList` cannot identify the form, use these fallback methods:

1. After visiting form management UI, inspect localStorage keys matching `Form_0_<formId>_checkNewForm`.
2. Intercept XHR requests to `getFormFieldPage` after switching field tabs and inspect the request body.
3. Do not treat `pathset/<id>` in the workflow detail URL as formId; that value is workflowId/pathSetId.