[{"data":1,"prerenderedAt":7},["ShallowReactive",2],{"docs-entities\u002Ftasks\u002Ftime\u002Ffields":3,"docs-tabs-entities\u002Ftasks\u002Ftime\u002Ffields":6},{"content":4,"lastmod":5},"\n## Time-tracking entry fields\n\n`GET \u002Fv1\u002Ftask-time\u002Ffields`\n\nReturns the field schema of a time-tracking entry. One schema covers every task, so the path is flat and carries no task identifier.\n\n## Examples\n\n### curl — personal key\n\n```bash\ncurl \"https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Ftask-time\u002Ffields\" \\\n  -H \"X-Api-Key: YOUR_API_KEY\"\n```\n\n### curl — OAuth application\n\n```bash\ncurl \"https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Ftask-time\u002Ffields\" \\\n  -H \"X-Api-Key: YOUR_APP_KEY\" \\\n  -H \"Authorization: Bearer USER_SESSION_TOKEN\"\n```\n\n### JavaScript — personal key\n\n```javascript\nconst res = await fetch('https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Ftask-time\u002Ffields', {\n  headers: {\n    'X-Api-Key': 'YOUR_API_KEY',\n  },\n})\n\nconst { success, data } = await res.json()\nconsole.log('Fields:', Object.keys(data.fields).length)\n```\n\n### JavaScript — OAuth application\n\n```javascript\nconst res = await fetch('https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Ftask-time\u002Ffields', {\n  headers: {\n    'X-Api-Key': 'YOUR_APP_KEY',\n    'Authorization': 'Bearer USER_SESSION_TOKEN',\n  },\n})\n\nconst { success, data } = await res.json()\n```\n\n## Response fields\n\n| Field | Type | Description |\n|------|-----|---------|\n| `success` | boolean | Always `true` on success |\n| `data.fields` | object | Entry field schema. The key is the field name in camelCase, the value is its descriptor |\n| `data.fields.\u003Cname>.type` | string | Value type of the field: `number`, `string` or `datetime` |\n| `data.fields.\u003Cname>.readonly` | boolean | `true` — the field is filled by the system and is not accepted on write |\n| `data.fields.\u003Cname>.createOnly` | boolean | Present on fields accepted only when an entry is created. In an update request such a field is rejected with `400 READONLY_FIELD` |\n| `data.fields.\u003Cname>.label` | string | Short name of the field |\n| `data.fields.\u003Cname>.description` | string | Explanation of the field, including the key name in the request body when it differs from the name in the response |\n\nThe schema describes ten fields:\n\n| Field | Type | RO | Description |\n|------|-----|:--:|---------|\n| `id` | number | yes | Entry identifier |\n| `taskId` | number | yes | Identifier of the parent task. On the nested paths it is taken from the request path and is not set in the body |\n| `userId` | number | | The employee the time is logged for. List: `GET \u002Fv1\u002Fusers`. Accepted on creation only, and defaults to the key owner |\n| `seconds` | number | | Logged duration in seconds. Required on creation, optional on update |\n| `minutes` | number | yes | Duration in minutes, derived from `seconds` |\n| `commentText` | string | | Comment for the entry. In the request body it is passed under the name `comment`. An empty comment arrives as an empty string |\n| `source` | string | yes | Origin of the entry. The value `2` means the entry was created through the REST API |\n| `createdDate` | datetime | | Creation date in ISO 8601 with the account's UTC offset. Accepted on creation and on update, which lets you backdate an entry |\n| `dateStart` | datetime | yes | Start of the tracked interval in ISO 8601 with the account's UTC offset |\n| `dateStop` | datetime | yes | End of the tracked interval in ISO 8601 with the account's UTC offset |\n\n## Response example\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"fields\": {\n      \"id\": {\n        \"type\": \"number\",\n        \"readonly\": true,\n        \"label\": \"ID\",\n        \"description\": \"Time-entry identifier. Serialized as a number.\"\n      },\n      \"taskId\": {\n        \"type\": \"number\",\n        \"readonly\": true,\n        \"label\": \"Task ID\",\n        \"description\": \"Numeric id of the parent task. Comes from the URL path on the nested routes — not settable in the body.\"\n      },\n      \"userId\": {\n        \"type\": \"number\",\n        \"readonly\": false,\n        \"label\": \"Author ID\",\n        \"description\": \"Numeric id of the user the time is logged for — an id from GET \u002Fv1\u002Fusers. Optional on create (defaults to the key owner); PATCH rejects it with 400 READONLY_FIELD, because Bitrix24 cannot reassign the author.\",\n        \"createOnly\": true\n      },\n      \"seconds\": {\n        \"type\": \"number\",\n        \"readonly\": false,\n        \"label\": \"Seconds\",\n        \"description\": \"Logged duration in seconds. Required on create, optional on update. Body key: seconds.\"\n      },\n      \"minutes\": {\n        \"type\": \"number\",\n        \"readonly\": true,\n        \"label\": \"Minutes\",\n        \"description\": \"Duration in minutes, derived from seconds by Bitrix24. Read-only through this API — the Vibe route never forwards it.\"\n      },\n      \"commentText\": {\n        \"type\": \"string\",\n        \"readonly\": false,\n        \"label\": \"Comment\",\n        \"description\": \"Comment for the entry. On write pass it as comment in the body — commentText is the response name. An empty comment is returned as \\\"\\\", not null.\"\n      },\n      \"source\": {\n        \"type\": \"string\",\n        \"readonly\": true,\n        \"label\": \"Source\",\n        \"description\": \"Origin of the entry, set by Bitrix24: \\\"2\\\" — created through the REST API.\"\n      },\n      \"createdDate\": {\n        \"type\": \"datetime\",\n        \"readonly\": false,\n        \"label\": \"Created at\",\n        \"description\": \"Creation date, ISO 8601 with the account's UTC offset (for example 2026-05-13T16:15:41+00:00). Writable on create and update — pass createdDate to backdate an entry.\"\n      },\n      \"dateStart\": {\n        \"type\": \"datetime\",\n        \"readonly\": true,\n        \"label\": \"Interval start\",\n        \"description\": \"Start of the tracked interval, ISO 8601 with the account's UTC offset. Filled by Bitrix24 automatically and not editable through this API.\"\n      },\n      \"dateStop\": {\n        \"type\": \"datetime\",\n        \"readonly\": true,\n        \"label\": \"Interval end\",\n        \"description\": \"End of the tracked interval, ISO 8601 with the account's UTC offset. Filled by Bitrix24 automatically and not editable through this API.\"\n      }\n    }\n  }\n}\n```\n\n## Error response example\n\n403 — scope missing:\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"SCOPE_DENIED\",\n    \"message\": \"This endpoint requires 'task' scope\"\n  }\n}\n```\n\n## Errors\n\n| HTTP | Code | Description |\n|------|-----|---------|\n| 400 | `WRONG_PATH` | The request went to the nested path `GET \u002Fv1\u002Ftasks\u002F:taskId\u002Ftime\u002Ffields`. The correct flat path is named in the error text |\n| 403 | `SCOPE_DENIED` | The key lacks the `task` scope |\n| 401 | `MISSING_API_KEY` | The `X-Api-Key` header was not sent |\n\nFull list of common API errors — [Errors](\u002Fdocs\u002Ferrors).\n\n## Known specifics\n\n**The schema does not depend on the Bitrix24 account.** The response is assembled on the Vibecode platform side and makes no Bitrix24 call along the way. That is why the request only needs the `task` scope — the account's configured tokens are not required for it.\n\n## See also\n\n- [Task time tracking](\u002Fdocs\u002Fentities\u002Ftasks\u002Ftime)\n- [Add an entry](\u002Fdocs\u002Fentities\u002Ftasks\u002Ftime\u002Fcreate)\n- [Update a time-tracking entry](\u002Fdocs\u002Fentities\u002Ftasks\u002Ftime\u002Fupdate)\n- [List entries across the whole Bitrix24 account](\u002Fdocs\u002Fentities\u002Ftasks\u002Ftime\u002Fglobal-list)\n","2026-10-09",{},1794739438902]