Compliance API report export fails due to date format mismatch in request payload

QMS Sparta Systems TrackWise
, , , , , , , ,
1

We’re building an automated compliance reporting system that exports monthly reports via the Trackwise 9.1 API. The report export endpoint (POST /api/compliance/reports/export) fails with date format validation errors even though we’re sending ISO 8601 formatted dates.

The date format validation error message says “Invalid date format” but doesn’t specify what format is expected. We’ve tried ISO 8601 (2025-04-01T00:00:00Z), Unix timestamps, and MM/DD/YYYY formats - all fail. The API request payload standards documentation doesn’t clearly specify the required date format for report parameters.

POST /api/compliance/reports/export
{
  "reportType": "AUDIT_SUMMARY",
  "startDate": "2025-03-01T00:00:00Z",
  "endDate": "2025-03-31T23:59:59Z"
}

This is causing reporting delays because we can’t automate the monthly export. Our automated report scheduling job fails every time. Has anyone successfully used the compliance report export API with date parameters?

2

The date format issues you’re experiencing are due to inconsistent date handling across Trackwise API endpoints and the lack of clear documentation on API request payload standards. Let me provide a comprehensive solution for your automated report scheduling.

Date Format Validation in TW 9.1:

The compliance report export API specifically requires dates in “yyyy-MM-dd HH:mm:ss” format without timezone information. The API interprets all dates in the Trackwise server’s configured timezone, which can cause confusion if your automation runs in a different timezone.

Correct Request Format:

{
  "reportType": "AUDIT_SUMMARY",
  "startDate": "2025-03-01 00:00:00",
  "endDate": "2025-03-31 23:59:59",
  "format": "PDF",
  "includeAttachments": false
}

Key Requirements:

  • Use 24-hour time format (HH not hh)
  • Include seconds (ss) even if zero
  • No timezone indicators (Z, +00:00, etc.)
  • No milliseconds
  • Space between date and time (not T)

API Request Payload Standards:

Here’s the complete specification for compliance report exports:

Required Fields:

  • reportType: String enum (AUDIT_SUMMARY, DEVIATION_REPORT, CAPA_STATUS, etc.)
  • startDate: String in yyyy-MM-dd HH:mm:ss format
  • endDate: String in yyyy-MM-dd HH:mm:ss format

Optional Fields:

  • format: String enum (PDF, EXCEL, CSV) - defaults to PDF
  • filters: Object with report-specific filter criteria
  • includeAttachments: Boolean - defaults to false
  • emailRecipients: Array of email addresses for automatic delivery

Automated Report Scheduling Implementation:

Here’s a robust implementation for your automation:

public class ComplianceReportScheduler {

    private static final DateTimeFormatter TW_DATE_FORMAT =
        DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");

    public void exportMonthlyReport(YearMonth reportMonth) {
        // Calculate date range in server timezone
        ZoneId serverZone = ZoneId.of("America/New_York"); // Your TW server timezone

        LocalDateTime startOfMonth = reportMonth.atDay(1).atStartOfDay();
        LocalDateTime endOfMonth = reportMonth.atEndOfMonth().atTime(23, 59, 59);

        String startDate = startOfMonth.format(TW_DATE_FORMAT);
        String endDate = endOfMonth.format(TW_DATE_FORMAT);

        // Build request
        JsonObject payload = new JsonObject();
        payload.addProperty("reportType", "AUDIT_SUMMARY");
        payload.addProperty("startDate", startDate);
        payload.addProperty("endDate", endDate);
        payload.addProperty("format", "PDF");

        try {
            HttpResponse response = apiClient.post(
                "/api/compliance/reports/export",
                payload.toString()
            );

            if (response.getStatusCode() == 200) {
                processReport(response.getBody());
            } else {
                handleError(response);
            }
        } catch (Exception e) {
            logger.error("Report export failed", e);
            throw new ReportingException("Failed to export compliance report", e);
        }
    }
}

Timezone Handling:

This is critical for automated scheduling. If your automation runs in UTC but your Trackwise server is in EST:

// Convert your automation's timezone to server timezone
ZonedDateTime automationTime = ZonedDateTime.now(ZoneId.of("UTC"));
ZonedDateTime serverTime = automationTime.withZoneSameInstant(
    ZoneId.of("America/New_York")
);
String formattedDate = serverTime.format(TW_DATE_FORMAT);

Error Handling for Date Validation:

private void handleError(HttpResponse response) {
    if (response.getBody().contains("Invalid date format")) {
        logger.error("Date format validation failed. Sent: {} Expected: yyyy-MM-dd HH:mm:ss",
            payload.get("startDate"));

        // Log the exact payload for debugging
        logger.debug("Full request payload: {}", payload.toString());
    }
}

Testing Different Report Types:

Some report types have restrictions on date ranges:

public void validateReportType(String reportType, LocalDate startDate, LocalDate endDate) {
    long daysBetween = ChronoUnit.DAYS.between(startDate, endDate);

    switch (reportType) {
        case "AUDIT_SUMMARY":
            // Supports up to 12 months
            if (daysBetween > 365) {
                throw new ValidationException("Date range exceeds 12 months");
            }
            break;
        case "DEVIATION_REPORT":
            // Supports up to 3 months
            if (daysBetween > 90) {
                throw new ValidationException("Date range exceeds 3 months");
            }
            break;
    }
}

Automated Report Scheduling Configuration:

For scheduled jobs, use a configuration file to manage report parameters:

{
  "schedules": [
    {
      "reportType": "AUDIT_SUMMARY",
      "frequency": "MONTHLY",
      "dayOfMonth": 1,
      "time": "08:00:00",
      "timezone": "America/New_York",
      "lookbackPeriod": "PREVIOUS_MONTH",
      "format": "PDF",
      "recipients": ["compliance@company.com"]
    }
  ]
}

This configuration-driven approach eliminates hardcoded dates and makes your automation more maintainable.

Final Recommendations:

  1. Always format dates in the server’s timezone using yyyy-MM-dd HH:mm:ss
  2. Validate date ranges before sending to API to avoid unnecessary failures
  3. Log the exact payload when date validation fails for troubleshooting
  4. Implement retry logic with exponential backoff for transient failures
  5. Store successful report exports with their parameters for audit trail

This complete implementation should resolve your reporting delays and enable reliable automated report scheduling.

3

Also check if your report type supports date range parameters. Some report types in the compliance module have fixed date ranges (like “current month” or “last quarter”) and will reject custom date parameters. The AUDIT_SUMMARY report should support custom ranges, but verify in the report definition.

4

I remember fighting with this. TW 9.1 expects dates in a specific format that’s not ISO 8601. Try using “yyyy-MM-dd HH:mm:ss” format without the timezone indicator. So “2025-03-01 00:00:00” instead of the ISO format. The API assumes server timezone for all date inputs.

5

Our server is set to US locale, but MM/DD/YYYY format still fails. I’ll try the yyyy-MM-dd format suggested. Is there any way to query the API to discover what format it expects, or do we just have to guess and test?

6

There’s no discovery endpoint for date formats unfortunately. We built a test harness that tries different formats and logs which ones succeed for each endpoint. For compliance reports, the format is yyyy-MM-dd HH:mm:ss in the server’s timezone. Make sure you’re not including milliseconds or timezone offsets - those will cause validation failures.