GetSellerEventsRequestType ( AbstractRequestType )
This call is used by a seller to retrieve changes to their own listings that have occurred within the last 48 hours, including price changes, available quantity, and other revisions to listing.
One of the available date range filters must be used with this call.
Call that uses GetSellerEventsRequestType:
Fields
EndTimeFrom ( dateTime )
ModTimeFrom ( dateTime )
NewItemFilter ( boolean )
StartTimeTo ( dateTime )
Describes the earliest (oldest) date to use in a time range filter based on item end time. Must be specified if EndTimeTo is specified.
Either the StartTimeFrom, EndTimeFrom, or ModTimeFrom filter must be specified. If you do not specify the corresponding To filter, it is set to the time you make the call.
For better results, the time range you use should be less than 48 hours. If 3000 or more items are found, use a smaller time range.
Include a 2-minute, overlapping buffer between requests. For example, if EndTimeTo was 6:58 in a prior request, the current request should use 6:56 in EndTimeFrom (e.g., use ranges like 5:56-6:58, 6:56-7:58, 7:56-8:58).
Either the StartTimeFrom, EndTimeFrom, or ModTimeFrom filter must be specified. If you do not specify the corresponding To filter, it is set to the time you make the call.
For better results, the time range you use should be less than 48 hours. If 3000 or more items are found, use a smaller time range.
Include a 2-minute, overlapping buffer between requests. For example, if EndTimeTo was 6:58 in a prior request, the current request should use 6:56 in EndTimeFrom (e.g., use ranges like 5:56-6:58, 6:56-7:58, 7:56-8:58).
See the Field Index to learn which calls use EndTimeFrom.
Describes the latest (most recent) date to use in a time range filter based on item end time.
If you specify the corresponding From filter, but you do not include EndTimeTo, then EndTimeTo is set to the time you make the call.
If you specify the corresponding From filter, but you do not include EndTimeTo, then EndTimeTo is set to the time you make the call.
See the Field Index to learn which calls use EndTimeTo.
Specifies whether to force the response to hide variation details for multiple-variation listings.
If false (or not specified), eBay returns variation details (if any). In this case, the amount of detail can be controlled by using IncludeVariationSpecifics.
If true, variation details are not returned (and IncludeVariationSpecifics has no effect). This may be useful for applications that use other calls, notifications, alerts, or reports to track price and quantity details.
If false (or not specified), eBay returns variation details (if any). In this case, the amount of detail can be controlled by using IncludeVariationSpecifics.
If true, variation details are not returned (and IncludeVariationSpecifics has no effect). This may be useful for applications that use other calls, notifications, alerts, or reports to track price and quantity details.
See the Field Index to learn which calls use HideVariations.
Specifies whether to force the response to include variation specifics for multiple-variation listings.
If false (or not specified), eBay keeps the response as small as possible by not returning Variation.VariationSpecifics. It only returns Variation.SKU as an identifier (along with the variation price and other selling details). If the variation has no SKU, then Variation.VariationSpecifics is returned as the variation's unique identifier.
If true, Variation.VariationSpecifics is returned. (Variation.SKU is also returned, if the variation has a SKU.) This may be useful for applications that don't track variations by SKU.
Ignored when HideVariations is set to true.
Note: If the seller includes a large number of variations in many listings, using this flag may degrade the call's performance. Therefore, when you use this flag, you may need to reduce the total number of items you're requesting at once. For example, you may need to use shorter time ranges in the StartTimeFrom, EndTimeFrom, or ModTimeFrom filters.
If false (or not specified), eBay keeps the response as small as possible by not returning Variation.VariationSpecifics. It only returns Variation.SKU as an identifier (along with the variation price and other selling details). If the variation has no SKU, then Variation.VariationSpecifics is returned as the variation's unique identifier.
If true, Variation.VariationSpecifics is returned. (Variation.SKU is also returned, if the variation has a SKU.) This may be useful for applications that don't track variations by SKU.
Ignored when HideVariations is set to true.
Note: If the seller includes a large number of variations in many listings, using this flag may degrade the call's performance. Therefore, when you use this flag, you may need to reduce the total number of items you're requesting at once. For example, you may need to use shorter time ranges in the StartTimeFrom, EndTimeFrom, or ModTimeFrom filters.
See the Field Index to learn which calls use IncludeVariationSpecifics.
The seller can include this field and set its value to
true if that seller wants to see how many prospective bidders/buyers currently have an item added to their Watch Lists. The Watch count is returned in the WatchCount field for each item in the response.
See the Field Index to learn which calls use IncludeWatchCount.
Describes the earliest (oldest) date to use in a time range filter based on item modification time. Must be specified if ModTimeTo is specified. Either the StartTimeFrom, EndTimeFrom, or ModTimeFrom filter must be specified. If you do not specify the corresponding To filter, it is set to the time you make the call.
Include a 2-minute, overlapping buffer between requests. For example, if ModTimeTo was 6:58 in a prior request, the current request should use 6:56 in ModTimeFrom (e.g., use ranges like 5:56-6:58, 6:56-7:58, 7:56-8:58).
For better results, the time range you use should be less than 48 hours. If 3000 or more items are found, use a smaller time range.
If an unexpected item is returned (including an old item or an unchanged active item), please ignore the item. Although a maintenance process may have triggered a change in the modification time, item characteristics are unchanged.
Include a 2-minute, overlapping buffer between requests. For example, if ModTimeTo was 6:58 in a prior request, the current request should use 6:56 in ModTimeFrom (e.g., use ranges like 5:56-6:58, 6:56-7:58, 7:56-8:58).
For better results, the time range you use should be less than 48 hours. If 3000 or more items are found, use a smaller time range.
If an unexpected item is returned (including an old item or an unchanged active item), please ignore the item. Although a maintenance process may have triggered a change in the modification time, item characteristics are unchanged.
See the Field Index to learn which calls use ModTimeFrom.
Describes the latest (most recent) date and time to use in a time range filter based on the time an item's record was modified. If you specify the corresponding From filter, but you do not include ModTimeTo , then ModTimeTo is set to the time you make the call. Include a 2-minute buffer between the current time and the ModTimeTo filter.
See the Field Index to learn which calls use ModTimeTo.
If true, response includes only items that have been modified within the ModTime range. If false, response includes all items.
See the Field Index to learn which calls use NewItemFilter.
Describes the earliest (oldest) time to use in a time range filter based on item start time. Must be specified if StartTimeTo is specified.
Either the StartTimeFrom, EndTimeFrom, or ModTimeFrom filter must be specified.
If you do not specify the corresponding To filter, it is set to the time you make the call.
For better results, the time period you use should be less than 48 hours. If 3000 or more items are found, use a smaller time range.
Include a 2-minute, overlapping buffer between requests. For example, if StartTimeTo was 6:58 in a prior request, the current request should use 6:56 in StartTimeFrom (e.g., use ranges like 5:56-6:58, 6:56-7:58, 7:56-8:58).
Either the StartTimeFrom, EndTimeFrom, or ModTimeFrom filter must be specified.
If you do not specify the corresponding To filter, it is set to the time you make the call.
For better results, the time period you use should be less than 48 hours. If 3000 or more items are found, use a smaller time range.
Include a 2-minute, overlapping buffer between requests. For example, if StartTimeTo was 6:58 in a prior request, the current request should use 6:56 in StartTimeFrom (e.g., use ranges like 5:56-6:58, 6:56-7:58, 7:56-8:58).
See the Field Index to learn which calls use StartTimeFrom.
Describes the latest (most recent) date to use in a time range filter based on item start time. If you specify the corresponding From filter, but you do not include StartTimeTo, the StartTimeTo is set to the time you make the call.
See the Field Index to learn which calls use StartTimeTo.