Problem Statement

14 REST API v1 endpoint files still lack validateParams validation and use either the legacy check() function or no validation at all. These files use the old API.v1.addRoute() pattern instead of the new chained .get()/.post() pattern with typed response schemas.

Migration Status

Expected Behavior

All API v1 endpoints should follow the new chained API pattern (as seen in permissions.ts and call-history.ts):

const endpoints = API.v1
  .get("endpoint.name", {
    authRequired: true,
    query: compiledAjvValidator,
    response: {
      200: ajv.compile<ResponseType>({ ... }),
      400: validateBadRequestErrorResponse,
      401: validateUnauthorizedErrorResponse,
    },
  }, async function action() { ... });

Instead of the legacy:

API.v1.addRoute("endpoint.name", { authRequired: true }, {
  async get() { ... }
});

Benefits of Migration

1. Type-safe response schemas — enables OpenAPI spec generation
2. Standardized error responses (400, 401, 403)
3. AJV validation instead of Meteor check() or no validation
4. Chained route definitions with proper TypeScript inference
5. Better developer experience with auto-generated API documentation

Suggested Approach

Migrate files incrementally, starting with smaller endpoints:

1. instances.ts (1 route, 45 lines) — easiest start
2. presence.ts (3 routes) — small scope
3. stats.ts (3 routes) — small scope
4. ldap.ts (2 routes) — small scope
5. push.ts (4 routes, replace check())
6. email-inbox.ts (5 routes, replace check(), address TODOs)
7. roles.ts (6 routes) — medium scope
8. Remaining larger files

Related

• Reference implementation: apps/meteor/app/api/server/v1/permissions.ts
• Type definitions: packages/rest-typings/src/v1/
• API framework: apps/meteor/app/api/server/ApiClass.ts

Additional Context

This is part of the broader effort to standardize Rocket.Chat's REST API definitions to enable automatic OpenAPI documentation generation.