Batch timecard upload via REST API fails with invalid date format error in time and attendance integration

ERP Oracle Fusion Cloud
, , , , , , , ,
1

We’re implementing automated timecard uploads using the Time and Labor REST API in OFC 23C. Our batch process uploads weekly timecards for 500+ employees every Monday morning. The API consistently returns HTTP 400 with “Invalid date format” error for the TimeCardDate field.

We’ve tried multiple date formats based on the documentation, but none seem to work:

{
  "WorkerNumber": "EMP12345",
  "TimeCardDate": "2025-03-10",
  "Hours": 8
}

The error message doesn’t specify what format is expected. We’ve reviewed the REST API guide but the date format requirements seem unclear. Has anyone successfully implemented batch timecard uploads? What’s the correct date format and are there any payload validation tips we should know about?

2

I’ve seen this exact issue before. The TimeCardDate field requires ISO 8601 format with time component, not just the date. Try “2025-03-10T00:00:00” or “2025-03-10T00:00:00+00:00” with timezone offset. Also check if your API documentation version matches your OFC instance version - 23C had some changes to date handling.

3

Based on your symptoms, I suspect you’re missing required contextual date fields. Check your complete payload structure against the sample in the API catalog. For 23C specifically, here’s what worked for us - we had to review the API documentation more carefully and discovered additional validation requirements.

Regarding date format requirements, the TimeCardDate must be in yyyy-MM-dd format (just the date, no time component contrary to what was suggested earlier). However, you also need to include TimeEntryDate which requires full ISO 8601 with timezone.

For sample payload validation, test with this minimal structure first:

{
  "WorkerNumber": "EMP12345",
  "TimeCardDate": "2025-03-10",
  "TimeEntryDate": "2025-03-10T08:00:00+00:00",
  "Hours": "8.00"
}

Note Hours should be string format with decimal. Also verify your authentication token has the required roles (ORA_HWM_TIME_ENTRY_DUTY).

4

I need to correct my earlier response after reviewing the 23C documentation more thoroughly. The solution provided by integration_solutions_pro is spot on. Let me add comprehensive guidance on all three focus areas.

Date Format Requirements: The API actually expects TWO different date fields with different formats:

  • TimeCardDate: Simple date format yyyy-MM-dd (e.g., “2025-03-10”)
  • TimeEntryDate: Full ISO 8601 with timezone yyyy-MM-ddTHH:mm:ss+HH:mm

The error occurs when TimeEntryDate is missing or incorrectly formatted. This is a common pitfall because the error message only mentions “date format” without specifying which field.

API Documentation Review: For 23C, reference the HCM REST API catalog at /hcmRestApi/resources/latest/timecards. The key changes from 22D:

  • Stricter validation on numeric fields (Hours must be string with 2 decimals)
  • TimeEntryDate became mandatory (was optional in 22D)
  • Timezone offset is now validated against worker’s home timezone

Sample Payload Validation: Best practice for batch uploads:

{
  "WorkerNumber": "EMP12345",
  "TimeCardDate": "2025-03-10",
  "TimeEntryDate": "2025-03-10T08:00:00-05:00",
  "Hours": "8.00",
  "ProjectNumber": "PRJ-001",
  "TaskNumber": "TASK-100"
}

For batch processing, implement:

  1. Pre-validation against XSD schema before API submission
  2. Single-record test runs with verbose logging enabled
  3. Timezone conversion to worker’s home timezone (not UTC)
  4. Retry logic with exponential backoff for rate limiting

Common validation failures:

  • Missing TimeEntryDate field (your issue)
  • Hours format without decimal places
  • Timezone offset doesn’t match worker profile
  • Missing required project/task when time entry rules enforce them

Test your payload against the REST API catalog’s “Try It” feature first. This validates the structure before running your batch. Also check if your integration user has HWM_INTEGRATION_SPECIALIST role for bulk operations.

5

I’d recommend enabling detailed logging on your REST client to capture the full request/response cycle. The “Invalid date format” error can also be triggered by other date fields in the payload like ProjectStartDate or TimeEntryDate if you’re using project time tracking. Run a single-record test with minimal fields first to isolate which field is causing the problem. Also verify your Content-Type header is set to application/json.

6

Timezone mismatch could definitely cause issues. In our implementation, we always convert to UTC before sending to the API. Also, make sure you’re using the correct endpoint - there’s a difference between /hcmRestApi/resources/11.13.18.05/timecards and the newer /fscmRestApi endpoints. The newer endpoints have stricter validation. Have you checked the response headers for any additional error details?

7

Thanks for the quick response. We tried the ISO format with time component but still getting the same error. Could this be related to timezone settings in our integration user profile? We’re uploading from EST but our Fusion instance is configured for PST.

8

Another thing to check - are you sending the date as a string or as a date object? Some REST clients automatically convert date strings to date objects which can cause serialization issues. Explicitly cast to string in your code before building the JSON payload. We had a similar issue where our integration framework was converting strings to JavaScript Date objects.