Could someone explain the validation logic for the /v2/analytics/report/definitions endpoint when combining multiple date range filters?
We are seeing a 400 Bad Request when our integration attempts to create a custom report definition with overlapping date constraints. The payload seems valid according to the schema.
"error": "Invalid date range configuration"
Is there a specific limit on filter complexity for Premium Apps?
Generally speaking, the validation engine rejects overlapping date constraints because it cannot determine a single definitive start and end point for the underlying data query. The API expects discrete, non-overlapping ranges or a single continuous range. When multiple filters are applied, the system attempts to merge them, and if the logic detects ambiguity in the start time versus the end time across different filter objects, it throws the 400 error. This is similar to the race condition issues seen with Terraform provisioning, where dependency validation fails if the state is not strictly defined. To resolve this, structure the payload to use a single date range object with explicit start and end timestamps in ISO 8601 format, ensuring the timezone offset is included. If multiple ranges are required, they must be mutually exclusive. For example, instead of passing two separate date filter objects that overlap, combine the logic into one object: {"dateRange": {"start": "2023-10-01T00:00:00Z", "end": "2023-10-31T23:59:59Z"}}. Additionally, check for any hidden whitespace in the timestamp strings, as this has caused silent failures in other integrations. The error message “Invalid date range configuration” is generic but usually points to this specific structural issue. If the issue persists, verify that the date format matches the exact schema requirements for the report definition endpoint, as slight deviations in the timezone suffix can trigger validation errors. It is also worth checking if the report definition ID already exists, as attempting to create a duplicate with conflicting parameters can sometimes result in a misleading 400 response. Ensure the payload is strictly adhering to the documented schema for the analytics report definition endpoint to avoid these validation pitfalls.