Project: Pet Feeder | page_id: 1729
Feeding Plan Authentication Interface Documentation
Overview
- Base path: /api
- Documentation scope: feeding plan interfaces in the authenticated routes
- Authentication method: request header X-Token
- Content-Type: application/json
Authentication Header
| Field |
Type |
Required |
Description |
| X-Token |
string |
Yes |
The JWT Token obtained after the user logs in |
Unified Response Format
{
"code": 200,
"msg": "Operation successful",
"data": {}
}
Response Field Description
| Field |
Type |
Description |
| code |
integer |
Business status code; 200 means success, other values mean failure |
| msg |
string |
Response message |
| data |
object/array/null |
Business data |
Common Authentication Failure Response
{
"code": 401,
"msg": "Not logged in or login expired",
"data": null
}
{
"code": 401,
"msg": "Login has expired, please log in again",
"data": null
}
Feeding Plan Object Field Description
| Field |
Type |
Description |
| id |
integer |
Plan ID |
| deviceId |
string |
Unique device identifier |
| time |
string |
Feeding time, in HH:mm format |
| amount |
integer |
Feeding portion |
| days |
string |
Execution weekdays, in a format such as 1,2,3,4,5,6,7 |
| enabled |
boolean |
Whether it is enabled |
| createdAt |
string |
Creation time |
| updatedAt |
string |
Update time |
1. Get the Feeding Plan List
- Path: /api/feeding/list
- Method: POST
- Authentication required: Yes
Request Body Parameters
| Field |
Type |
Required |
Description |
| deviceId |
string |
Yes |
Unique device identifier |
Request Example
{
"deviceId": "dev_001"
}
Success Response Example
{
"code": 200,
"msg": "Operation successful",
"data": [
{
"id": 1,
"deviceId": "dev_001",
"time": "08:30",
"amount": 20,
"days": "1,2,3,4,5,6,7",
"enabled": true,
"createdAt": "2026-05-09T08:00:00Z",
"updatedAt": "2026-05-09T08:00:00Z"
}
]
}
Response Parameter Description
| Field |
Type |
Description |
| code |
integer |
200 on success |
| msg |
string |
Operation successful on success |
| data |
array |
Feeding plan list |
| data[].* |
object |
Feeding plan object; see the feeding plan object field description above |
Failure Response Example
{
"code": 400,
"msg": "Parameter error",
"data": null
}
{
"code": 500,
"msg": "Failed to get the plan list",
"data": null
}
2. Add a Feeding Plan
- Path: /api/feeding/add
- Method: POST
- Authentication required: Yes
Request Body Parameters
| Field |
Type |
Required |
Description |
| deviceId |
string |
Yes |
Unique device identifier |
| time |
string |
Yes |
Feeding time, in HH:mm format |
| amount |
integer |
Yes |
Feeding portion |
| days |
string |
Yes |
Execution weekdays, in a format such as 1,2,3,4,5,6,7 |
| enabled |
boolean |
No |
Whether it is enabled; when not passed, the zero value false enters the handler |
Request Example
{
"deviceId": "dev_001",
"time": "08:30",
"amount": 20,
"days": "1,2,3,4,5,6,7",
"enabled": true
}
Success Response Example
{
"code": 200,
"msg": "Plan added successfully",
"data": {
"id": 1,
"deviceId": "dev_001",
"time": "08:30",
"amount": 20,
"days": "1,2,3,4,5,6,7",
"enabled": true,
"createdAt": "2026-05-09T08:00:00Z",
"updatedAt": "2026-05-09T08:00:00Z"
}
}
Response Parameter Description
| Field |
Type |
Description |
| code |
integer |
200 on success |
| msg |
string |
Plan added successfully on success |
| data |
object |
The newly created feeding plan |
| data.* |
mixed |
Feeding plan object fields, see the feeding plan object field description above |
Failure Response Example
{
"code": 400,
"msg": "Parameter error",
"data": null
}
{
"code": 400,
"msg": "Device does not exist",
"data": null
}
{
"code": 400,
"msg": "No permission; only administrators can operate feeding plans",
"data": null
}
3. Update a Feeding Plan
- Path: /api/feeding/update
- Method: POST
- Authentication required: Yes
Request Body Parameters
| Field |
Type |
Required |
Description |
| id |
integer |
Yes |
Plan ID |
| deviceId |
string |
Yes |
Unique device identifier. The current handler validates that it is required, but the service actually queries the plan by id and does not use this field for the update |
| time |
string |
No |
New feeding time, in HH:mm format |
| amount |
integer |
No |
New feeding portion. It is only updated when it is greater than 0 |
| days |
string |
No |
New execution weekdays |
| enabled |
boolean |
No |
New enabled state |
Request Example
{
"id": 1,
"deviceId": "dev_001",
"time": "09:00",
"amount": 25,
"days": "1,2,3,4,5",
"enabled": true
}
Success Response Example
{
"code": 200,
"msg": "Plan updated successfully",
"data": null
}
Response Parameter Description
| Field |
Type |
Description |
| code |
integer |
200 on success |
| msg |
string |
Plan updated successfully on success |
| data |
null |
No returned data |
Failure Response Example
{
"code": 400,
"msg": "Parameter error",
"data": null
}
{
"code": 400,
"msg": "Plan does not exist",
"data": null
}
{
"code": 400,
"msg": "No permission; only administrators can operate feeding plans",
"data": null
}
4. Delete a Feeding Plan
- Path: /api/feeding/delete
- Method: POST
- Authentication required: Yes
Request Body Parameters
| Field |
Type |
Required |
Description |
| id |
integer |
Yes |
Plan ID |
| deviceId |
string |
Yes |
Unique device identifier. The current handler validates that it is required, but the service actually queries the plan by id and does not use this field for the deletion |
Request Example
{
"id": 1,
"deviceId": "dev_001"
}
Success Response Example
{
"code": 200,
"msg": "Plan deleted",
"data": null
}
Response Parameter Description
| Field |
Type |
Description |
| code |
integer |
200 on success |
| msg |
string |
Plan deleted on success |
| data |
null |
No returned data |
Failure Response Example
{
"code": 400,
"msg": "Parameter error",
"data": null
}
{
"code": 400,
"msg": "Plan does not exist",
"data": null
}
{
"code": 400,
"msg": "No permission; only administrators can operate feeding plans",
"data": null
}
5. Manual Feeding
- Path: /api/feeding/manual
- Method: POST
- Authentication required: Yes
Request Body Parameters
| Field |
Type |
Required |
Description |
| deviceId |
string |
Yes |
Unique device identifier |
| amount |
integer |
Yes |
Portion for this manual feeding |
Request Example
{
"deviceId": "dev_001",
"amount": 20
}
Success Response Example
{
"code": 200,
"msg": "Feeding command sent",
"data": {
"deviceId": "dev_001",
"userId": 1,
"userName": "Xiaoming",
"planId": 0,
"amount": 20,
"feedTime": 1752297600,
"createdAt": "2026-05-09T10:00:00Z"
}
}
Response Parameter Description
| Field |
Type |
Description |
| code |
integer |
200 on success |
| msg |
string |
Feeding command sent on success |
| data |
object |
The record generated by this manual feeding |
| data.* |
mixed |
Feeding record object fields, see the feeding record object field description above |
Failure Response Example
{
"code": 400,
"msg": "Parameter error",
"data": null
}
{
"code": 400,
"msg": "Device does not exist",
"data": null
}
{
"code": 400,
"msg": "Device is offline and cannot perform feeding",
"data": null
}
{
"code": 400,
"msg": "Failed to send the feeding command",
"data": null
}
Appendix
Description
- Getting feeding plans returns an array; when there is no data, an empty array is returned instead of null.
- Although the request bodies of the update and delete interfaces require deviceId, the current service implementation actually looks up the plan by id and then performs the operation; deviceId is only validated as required at the handler layer.
- After a feeding plan change succeeds, the server attempts to re-sync the full plan set to the device; when the device is offline, the sync is deferred.