This set of APIs manages the full lifecycle of a “To-do” resource. Each API plays a specific role, and together they provide a standard create–read–update pattern.

1. List To-Dos API

GET /api-public/1.0/todos

This endpoint retrieves a list of to-dos that the authenticated user is authorized to view.

Operation:

• The authenticated client sends a GET request with query parameters.
• The server returns an object containing records and count, where records contains the to-do records and count indicates how many records were returned.

Use query parameters to:

• Limit the number of records to return with limit
• List records before or after the given field value together with sort
• Control sort direction with order
• Limit the returned fields with fields
• Filter results by supported (string based) to-do fields, such as todoType, caseId, etc.

Typical Response (200 Todos retrieved successfully):

{
  "records": [
    {
      "id": "string",
      "createdDate": "UTC time"
      ...
    }
  ],
  ...
  "count": integer
}

Purpose:

• View existing to-do information.
• Find and query all to-dos meeting certain criteria.

2. Create To-do API

POST /todo

This endpoint is responsible for creating a new to-do in the system.

Operation:

• The authenticated client sends note details in the request body.
• The server validates and stores the new note.
• A unique to-do id is generated and returned in the response.

Typical Response (201 Created):

{
  "id": "uuid string",
  "createdDate": "UTC time"
  ...
}

Purpose:

• Initialize a fresh note record.
• Retrieve the ID required for further operations (retrieval, updates).

3. Retrieve To-do API

GET /todo/:id

This endpoint is used to fetch an existing to-do by its ID.

Operation:

• Client sends a GET request with the id returned from the create step.
• The server validates the ID and returns the note details.

Typical Response (200 OK):

{
  "id": "uuid string",
  "createdDate": "UTC time"
  ...
}

Purpose:

• View existing profile information.
• Confirm data that was created or previously updated.

4. Update To-do API

PUT /todo/:id or PATCH /todo/:id

These endpoints allow modifying an existing profile.

• PUT: replaces the entire to-do record with the new payload.
• PATCH: applies a partial update, only modifying provided fields.

Operation:

• Client sends updated fields with the correct id.
• Server applies the update and returns the updated record or status.

Typical Response (200 OK):

{
  "id": "12345",
  "createdDate": "UTC time",
  ...
}

Purpose:

• Modify or correct profile information.
• Progress the profile through its lifecycle.

How They Work Together

1. Create a to-do using POST /todo.
2. Server returns a id.
3. Use this ID to either:
   1. Retrieve the to-do (GET /todo/:id)
   2. Update the to-do (PUT/PATCH /todo/:id)

This flow ensures all to-do operations are securely tied to an authenticated session, and that each to-do is managed consistently using its unique identifier.