Yes, you’re correct. The low-code CDK allows you to define different datetime formats for the request and response. This is particularly useful when APIs require a different format for the request parameters and the records in the responses. Here’s an example of how you can define a second optional format in your configuration: yaml incremental_sync: cursor_field: "startDate" datetime_format: "%Y-%m-%d" cursor_granularity: "P1D" cursor_datetime_format: "%s" In this example, datetime_format is used for the response records, and cursor_datetime_format is used for the request parameters. If you’re still having issues, it might be due to the way the DatetimeBasedCursor compares dates. It was noted in a Github issue that the DatetimeBasedCursor was initially comparing dates as strings, which could lead to incorrect comparisons. However, this issue has been addressed and now the cursor’s date is parsed into a datetime object for comparisons. If you’re dealing with UNIX timestamps, you can use the %s format as shown in this forum post: yaml incremental_sync: type: DatetimeBasedCursor cursor_field: "created" datetime_format: "%s" cursor_granularity: "PT1S" start_datetime: datetime: "{{ config['start_date'] }}" datetime_format: "%Y-%m-%d %H:%M:%S" end_datetime: datetime: "{{ today_utc() }}" datetime_format: "%Y-%m-%d" step: "P1W" start_time_option: field_name: "created_after" inject_into: "request_parameter" end_time_option: field_name: "created_before" inject_into: "request_parameter" If you’re still facing issues, please provide more details about the problem you’re experiencing.