# Filtering Events The [Read Events](/developers/api/events/read-events/index.md) endpoint supports a series of parameters for filtering the output to suit your application's purpose. `from` and `to` - are **dates** used to filter events based on the time on the event. If the event overlaps with the period described by the from and to parameters. The tzid parameter affects the day boundaries for these filters, ie `2019-04-11` with `Australia/Sydney` will map to a boundary of `2019-04-10T14:00Z`. `last_modified` - is used to filter the events returned based on when they were last externally modified, ie not by the application. This is designed to be used in conjunction with the `changes_since` parameter received in the `change` [push notification](/developers/api/push-notifications/index.md). Using this parameter allows the application to retrieve all deltas since that time. Bear in mind that using this in conjunction with the `from` and `to` parameters will mean you only receive deltas for events that have times within the window specified. Generally an application won't combine these parameters. `include_managed` - requests "Managed" events, ie those created by the application are returned in the query. By default these aren't returned. The rationale being an application already has the definitive information on the events it manages. `only_managed` - only return "Managed" events. This is used for applications that are only concerned with events that it created. Using this in conjunction with the `last_modified` parameter allows and application to receive a list of "Managed" events that have been changed by the user. `include_deleted` - requests that any deleted events are included in query. Again this is most often used with the `last_modified` parameter to retrieve the events that have been deleted by the user. `include_moved` - ensures that any events that have ever existed in the window specified by `from` and `to` or the default window. --- [Read in HTML](/developers/calendars-events/event-filtering/)