Detail levels are instructions that define standard subsets of data to return for particular data components (e.g., each Item, Transaction, or User) within the response payload. »

Use ErrorLanguage to return error strings for the call in a different language from the language commonly associated with the site that the requesting user is registered with. »

Most Trading API calls support a MessageID element in the request and a CorrelationID element in the response. »

The version number of the API code that you are programming against (e.g., 1149). »

The public IP address of the machine from which the request is sent. »

Error tolerance level for the call. »

A unique identifier for a particular call. »

You can use the OutputSelector field to restrict the data returned by a call. »

Controls whether or not to return warnings when the application passes unrecognized or deprecated elements in a request. »

This container is only used by the PlaceOffer call request if the previous PlaceOffer call resulted in a BotBlock container in the response. »

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).

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.

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).

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.

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.

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.

If true, response includes only items that have been modified within the ModTime range. If false, response includes all items.

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.

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.

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.