OIC Schedule REST API “startDate” Gotcha and What Works Instead
A practical troubleshooting note for Oracle Integration schedule automation
Executive summary
When automating Oracle Integration Cloud (OIC) scheduled integrations via REST, you would typically expect the start timestamp to accept ISO 8601. However, multiple practitioners have observed HTTP 500 errors during schedule creation or update when the date portion is provided in an ISO-like format. A reliable workaround is to send startDate using a pipe-separated, non-ISO format (M/D/YYYY|H:m:s), which OIC appears to parse successfully.
Context: the Schedule API call
OIC exposes REST endpoints for scheduled integrations, including Update a Schedule (PUT) and related schedule operations.
Example endpoint pattern:
PUT https://design.integration.<region>.ocp.oraclecloud.com/ic/api/integration/v1/integrations/<CODE>%7C<VERSION>/schedule?integrationInstance=<instance>
In your case (masked instance):
PUT /ic/api/integration/v1/integrations/XX_YY_MPS_SENDR_OIC_STRT%7C01.00.0000/schedule?integrationInstance=****-id-oic-dev-fralo9gbe9pf-fr
Working payload (key detail: startDate)
The following payload works, and the critical detail is the non-ISO startDate format:
{
“id”: “Schedule_****_YY_MPS_SENDR_OIC_STRT_01_00_0000”,
“name”: “Schedule ****_YY_MPS_SENDR_OIC_STRT_01_00_0000”,
“scheduleTZ”: “Asia/Hong_Kong”,
“scheduleType”: “ADVANCED”,
“icalExpression”: “FREQ=DAILY;INTERVAL=1;BYHOUR=01;BYMINUTE=00;BYSECOND=00;”,
“startDate”: “2/24/2026|3:0:0”
}
What breaks (and why it looks like a defect)
A common failure mode is an HTTP 500 Internal Server Error where the server-side parser throws an exception on the date token. In one reported case, the response includes a message like: “For input string: ‘2026-02-22’”. This indicates that the schedule endpoint is attempting to parse the date string using an unexpected or incorrect pattern.
While YYYY-MM-DD is a valid ISO 8601 date representation, the schedule API appears to reject or mis-parse it suggesting an implementation defect or a mismatch between expected input and internal parsing rules.
Recommended workaround (until fixed)
Use a pipe-separated startDate with a month/day/year format, and keep time unpadded if needed:
M/D/YYYY|H:m:s
Examples:
- 2/24/2026|3:0:0
- 2/24/2026|01:00:00
- 12/1/2026|0:30:0
Operational notes
- Always log the outbound payload (masking secrets) and the target integrationInstance to speed up troubleshooting.
- Be explicit about timezone behavior: scheduleTZ is part of the payload, but your conversion logic (UTC vs local) must match your intended schedule semantics.
- If you maintain a shared automation library, centralize this formatting rule so all schedule calls behave consistently.
References
- Oracle Integration REST API: Scheduled Integrations endpoints (includes Update a Schedule).
- Oracle Integration REST API: Update a Schedule (PUT /integrations/{id}/schedule).
- Oracle Community: Reported HTTP 500 “For input string” error when updating schedule with YYYY-MM-DD date token.
- ISO: ISO 8601 date and time format overview (why ISO is typically expected by APIs).
- OIC date/time formatting approach (example practitioner guidance on formatting dateTime values).