PECI Event-Driven Integration Fails With HTTP 415 Unsupported Media Type
What it means
When PECI runs in event-driven mode and pushes a change immediately after a hire or other trigger, the receiving vendor endpoint can reject the delivery with an HTTP 415 if the Content-Type header Workday sends doesn't match what the vendor's API expects for that payload. Because the event-driven push failed, the change is not marked delivered, and the worker is then missing from the next scheduled PECI run's output until reprocessed.
Troubleshooting
- Check the vendor's integration documentation for the exact Content-Type, including character encoding, their endpoint requires for EDI or PECI payloads.
- Compare that against the Content-Type Workday's Cloud Connect delivery step is actually sending, visible in the integration's connector configuration.
- Confirm the affected worker is genuinely missing from the next scheduled run's Diagnostic Audit output, not just delayed, before treating it as a delivery failure rather than a timing issue.
- Ask the vendor whether their endpoint recently changed its accepted Content-Type, since a 415 on a previously working integration is often a vendor-side contract change rather than a Workday configuration change.
Manually trigger the standard scheduled PECI run, not the event-driven push, so the missed worker's change is picked up and delivered on the next cycle.
Work with the vendor to confirm and lock in the exact Content-Type their endpoint accepts, and if Workday's default doesn't match, raise a support case referencing the specific HTTP 415 response so Workday or the vendor can adjust the delivery step's header configuration.