Training records API sync fails when integrating with external LMS due to date format mismatch

QMS ETQ Reliance
, , , , , , , ,
1

We’re integrating ETQ Reliance training-mgmt module with our external LMS using REST API. The sync job runs but fails to import training completion records. Looking at the API payload validation logs, I’m seeing date format mismatches between what our LMS sends and what ETQ expects.

Our LMS sends completion dates like this:

{"completionDate": "15-03-2025",
 "employeeId": "EMP001",
 "courseCode": "QMS-101"}

ETQ throws validation errors and rejects about 60% of records. The middleware transformation layer doesn’t seem to be handling the conversion properly. Has anyone dealt with similar date format issues in training record imports? We need these records to sync daily for compliance reporting.

2

Beyond date formats, watch for required field validation - ETQ training records need employeeId, courseId, and completionDate at minimum. Also check string length limits on course codes and employee IDs. In ETQ 2021, the training API is particularly strict about data types - make sure numeric fields aren’t being sent as strings. We’ve seen issues where employee IDs sent as “001” instead of 1 caused silent failures.

3

What middleware are you using? If it’s something like Dell Boomi or Jitterbit, they have date formatting functions built in. You basically need to parse the incoming DD-MM-YYYY format and transform it to YYYY-MM-DD before the payload hits ETQ’s endpoint. Also make sure timezone handling is consistent - we had issues where date conversions were shifting dates by a day due to timezone offsets.

4

Thanks for the responses. We’re using custom Python middleware for the integration. I can see the transformation logic needs work. Are there any specific ETQ API validation rules I should be aware of beyond the date format? Want to make sure I catch everything in one fix rather than discovering issues incrementally.

5

Here’s a comprehensive solution addressing all three focus areas:

Date Format Transformation: Implement a standardized date parser in your Python middleware that handles the conversion before API submission:

from datetime import datetime
date_obj = datetime.strptime(lms_date, '%d-%m-%Y')
etq_date = date_obj.strftime('%Y-%m-%d')

API Payload Validation: Add pre-validation in your middleware to catch issues before they reach ETQ. Validate that all required fields are present, dates are parseable, and data types match ETQ’s schema. Create a validation function that checks:

  • completionDate is valid and not in future
  • employeeId exists in ETQ system (consider a lookup cache)
  • courseCode matches ETQ training catalog
  • All required fields are non-null

Log validation failures separately from API errors so you can distinguish between transformation issues and actual API problems.

Middleware Transformation Layer: Structure your integration with three distinct stages:

  1. Input Normalization: Parse incoming LMS data and convert all dates to Python datetime objects. Handle multiple possible input formats if your LMS isn’t consistent.

  2. Validation & Enrichment: Validate against ETQ’s requirements and enrich data if needed (e.g., looking up internal employee IDs from external identifiers).

  3. Output Formatting: Convert to ETQ’s expected payload structure with ISO 8601 dates.

Implement error handling at each stage with specific logging. For failed records, write them to a separate error queue with the specific validation failure reason - this makes troubleshooting much easier than trying to parse ETQ API errors.

One more critical point: implement batch processing with proper transaction handling. If you’re sending 100 records and one fails validation, don’t let that block the other 99. Process them individually within the batch and collect all failures for a summary report.

For ETQ 2021 specifically, ensure your API authentication token doesn’t expire mid-batch. We’ve seen cases where long-running sync jobs fail partway through due to token expiration. Implement token refresh logic in your middleware.

Lastly, add monitoring for the date format conversion itself. Track how many records required conversion vs. how many were already in correct format. This helps identify if your LMS configuration can be adjusted to send correct formats natively, eliminating the transformation overhead entirely.

6

For your Python middleware, you’ll want to use datetime.strptime() to parse the incoming format and strftime() to output ISO format. But here’s the thing - you should also implement validation logging before sending to ETQ so you can catch format issues proactively rather than waiting for ETQ’s API to reject them.