What causes "The "${name}" parameter must be a valid date." in RocketChat/Rocket.Chat?

Send ISO-8601 strings produced by date.toISOString(), e.g. 2024-06-01T00:00:00.000Z.

The " " parameter must be a valid date.

Error message

The "${name}" parameter must be a valid date.

What it means

Error thrown by parseDateOrFail in the EE audit REST API when the startDate/endDate parameter fails Date.parse (NaN). Used by audit.auditions (query params) and the audit endpoints (body params); the message names the offending parameter, e.g. `The "startDate" parameter must be a valid date.` The request fails with a 400 instead of running the audit query.

Solutions

Send ISO-8601 strings produced by date.toISOString(), e.g. 2024-06-01T00:00:00.000Z.
Validate with Date.parse on the client before sending and fix the construction of the string.
Check for accidental URL-encoding damage (colons/plus signs mangled) when dates travel in query strings.

Example fix

// before
GET /v1/audit.auditions?startDate=01/06/2024&endDate=30/06/2024 // 400

// after
GET /v1/audit.auditions?startDate=2024-06-01T00:00:00.000Z&endDate=2024-06-30T23:59:59.999Z

Defensive patterns

Strategy: validation

Validate before calling

const isValidDateParam = (value: string): boolean => !Number.isNaN(Date.parse(value));

const toIsoParam = (d: Date): string => d.toISOString(); // always valid

Type guard

const isInvalidDateParamError = (error: unknown): boolean =>
	Boolean(error instanceof Error && /parameter must be a valid date/.test(error.message));

Try / catch

try {
	const result = await GET('audit.auditions')({ startDate, endDate });
} catch (error) {
	if (isInvalidDateParamError(error)) {
		// fix param construction: re-encode via toISOString() and resend once
		throw new BadRequestError(error.message);
	}
	throw error;
}

Prevention

Always serialize date params with date.toISOString(), never template strings or locale formats.
Run Date.parse over each date param in a request wrapper before sending.
Encode query strings properly so timezone colons/offsets survive transport.

When it happens

Trigger: GET /v1/audit.auditions?startDate=2024-13-01&endDate=... (invalid month), empty or non-ISO strings like 'yesterday', '2024/06/01' on strict parsers, or a date already serialized with NaN on the client.

Common situations: Clients building date strings by hand instead of toISOString(); locale-formatted dates (dd/MM/yyyy); timezone suffixes missing or malformed; passing epoch numbers as strings.

Related errors

AI-assisted analysis of RocketChat/Rocket.Chat@e4b8178b20 (2026-08-18). Data as JSON: /api/errors/1be8aa17721f3e4a. Report an issue: GitHub.

Appendix: source

Thrown at apps/meteor/ee/server/api/audit.ts:408

	},
	required: ['messages', 'success'],
	additionalProperties: false,
});

const auditErrorResponseSchema = ajv.compile({
	type: 'object',
	properties: {
		success: { type: 'boolean', enum: [false] },
		error: { type: 'string' },
		errorType: { type: 'string' },
	},
	required: ['success', 'error'],
});

const parseDateOrFail = (value: string, name: string): Date => {
	const ts = Date.parse(value);
	if (Number.isNaN(ts)) {
		throw new Error(`The "${name}" parameter must be a valid date.`);
	}
	return new Date(ts);
};

API.v1.get(
	'audit.auditions',
	{
		authRequired: true,
		permissionsRequired: ['can-audit-log'],
		query: isAuditAuditionsProps,
		license: ['auditing'],
		rateLimiterOptions: { numRequestsAllowed: 10, intervalTimeInMS: 60000 },
		response: {
			200: auditAuditionsResponseSchema,
			400: auditErrorResponseSchema,
			401: validateUnauthorizedErrorResponse,
			403: validateForbiddenErrorResponse,
		},

View on GitHub (pinned to e4b8178b20)