INVALID_REPLICATION_DATE: Replication date invalid
What does this error mean?
The Salesforce SOAP and REST APIs provide getUpdated() and getDeleted() methods for replication use cases — retrieving lists of record IDs that changed or were deleted within a date range. These methods enforce strict constraints on the date range provided: it must be no longer than 30 days and the end date must be after the start date.
This error is returned when either constraint is violated. It's most commonly encountered in data replication, ETL, and change-tracking integrations that use these API methods.
Common Causes
1. Date range longer than 30 days
Passing a start date of 60 days ago and an end date of today — a 60-day window — exceeds the maximum allowed range of 30 days.
2. End date before start date
Date calculation errors (timezone conversions, off-by-one bugs) that produce an end date earlier than the start date.
3. First-time full sync with too large a window
An initial sync that attempts to capture all changes since the object was created — potentially spanning years — in a single call.
How to Fix It
Solution 1: Cap the range at 30 days and page through windows
DateTime endTime = DateTime.now();
DateTime startTime = endTime.addDays(-30); // max 30 days
// For longer periods, iterate in 30-day windows
DateTime windowEnd = DateTime.now();
DateTime windowStart = windowEnd.addDays(-30);
DateTime absoluteStart = windowEnd.addDays(-90); // 90-day sync
while (windowStart.getTime() > absoluteStart.getTime()) {{
// call getUpdated(windowStart, windowEnd)
windowEnd = windowStart;
windowStart = windowEnd.addDays(-30);
}}
Solution 2: Use Change Data Capture as a modern alternative
Change Data Capture (CDC) is the modern replacement for getUpdated()/getDeleted(). CDC delivers real-time change events via the Streaming API with no date-range constraints and supports a 72-hour replay window.
Pro Tip: Always validate that startDate < endDate and that the difference is under 30 days before calling getUpdated() or getDeleted(). Add an assertion in your integration layer to catch this before the API call, not after.