Base type definition of the request payload, which can carry any type of payload content plus optional versioning information and detail level requirements. All concrete request types (e.g., AddItemRequestType) are derived from the abstract request type. The naming convention we use for the concrete type names is the name of the service (the verb or call name) followed by "RequestType": VerbNameRequestType
Calls that use AbstractRequestType:
AddDispute, AddDisputeResponse, AddFixedPriceItem, AddItem, AddItems, AddMemberMessageAAQToPartner, AddMemberMessageRTQ, AddMemberMessagesAAQToBidder, AddOrder, AddSecondChanceItem, AddToItemDescription, AddToWatchList, AddTransactionConfirmationItem, CompleteSale, ConfirmIdentity, DeleteMyMessages, DisableUnpaidItemAssistance, EndFixedPriceItem, EndItem, EndItems, ExtendSiteHostedPictures, FetchToken, GetAccount, GetAdFormatLeads, GetAllBidders, GetApiAccessRules, GetBestOffers, GetBidderList, GetCategories, GetCategoryFeatures, GetCategoryMappings, GetChallengeToken, GetCharities, GetClientAlertsAuthToken, GetContextualKeywords, GetDescriptionTemplates, GetDispute, GeteBayDetails, GeteBayOfficialTime, GetFeedback, GetItem, GetItemsAwaitingFeedback, GetItemShipping, GetItemTransactions, GetMemberMessages, GetMessagePreferences, GetMyeBayBuying, GetMyeBayReminders, GetMyeBaySelling, GetMyMessages, GetNotificationPreferences, GetNotificationsUsage, GetOrders, GetOrderTransactions, GetSellerDashboard, GetSellerEvents, GetSellerList, GetSellerTransactions, GetSessionID, GetShippingDiscountProfiles, GetStore, GetStoreCategoryUpdateStatus, GetStoreCustomPage, GetStoreOptions, GetStorePreferences, GetSuggestedCategories, GetTaxTable, GetTokenStatus, GetUser, GetUserContactDetails, GetUserDisputes, GetUserPreferences, GetVeROReasonCodeDetails, GetVeROReportStatus, LeaveFeedback, PlaceOffer, RelistFixedPriceItem, RelistItem, RemoveFromWatchList, RespondToBestOffer, RespondToFeedback, ReviseFixedPriceItem, ReviseInventoryStatus, ReviseItem, ReviseMyMessages, ReviseMyMessagesFolders, RevokeToken, SellerReverseDispute, SendInvoice, SetMessagePreferences, SetNotificationPreferences, SetShippingDiscountProfiles, SetStore, SetStoreCategories, SetStoreCustomPage, SetStorePreferences, SetTaxTable, SetUserNotes, SetUserPreferences, UploadSiteHostedPictures, ValidateChallengeInput, ValidateTestUserRegistration, VerifyAddFixedPriceItem, VerifyAddItem, VerifyAddSecondChanceItem, VerifyRelistItem, VeROReportItems
Specifying a detail level is like using a predefined attribute list in the SELECT clause of an SQL query. Use the DetailLevel element to specify the required detail level that the client application needs pertaining to the data components that are applicable to the request.
The DetailLevelCodeType defines the global list of available detail levels for all request types. Most request types support certain detail levels or none at all. If you pass a detail level that exists in the schema but that isn't valid for a particular request, eBay ignores it and processes the request without it.
For each request type, see the detail level tables in the Input/Output Reference to determine which detail levels are applicable and which elements are returned for each applicable detail level.
Note that DetailLevel is required input for GetMyMessages.
With GetSellerList and other calls that retrieve large data sets, please avoid using ReturnAll when possible. For example, if you use GetSellerList, use GranularityLevel instead, or use GetSellerEvents. If you do use 'ReturnAll' with GetSellerList, use a small Pagination.EntriesPerPage value and a narrow EndTimeFrom/EndTimeTo date range for better performance.
This field is only applicable to AddItem and related calls, and only when the listing includes ProductListingDetails.
Note: GetCategories is designed to retrieve very large sets of metadata that change once a day or less often. To improve performance, these calls return cached responses when you request all available data (with no filters). When this occurs, the MessageID and CorrelationID fields aren't applicable. However, if you specify an input filter to reduce the amount of data returned, the calls retrieve the latest data (not cached). When this occurs, MessageID and CorrelationID are applicable.
For example, if you are using GetItem and you only want to retrieve the URL of the View Item page (emitted in ViewItemURL field) and the item's Buy It Now price (emitted in BuyItNowPrice field), you would include two separate OutputSelector fields and set the value for each one as ViewItemURL and BuyItNowPrice as in the following example:
If the following output selectors are used:
...the response might look like the following
- It indicates the version of the code lists and other data that eBay should use to process your request.
- It indicates the schema version you are using.
For the SOAP API: If you are using the SOAP API, this field is required. Specify the version of the WSDL your application is using.
For the XML API: If you are using the XML API, this field has no effect. Instead, specify the version in the X-EBAY-API-COMPATIBILITY-LEVEL HTTP header. (If you specify Version in the body of an XML API request and it is different from the value in the HTTP header, eBay returns an informational warning that the value in the HTTP header was used instead.)
An unrecognized element is one that is not defined in any supported version of the schema. Schema element names are case-sensitive, so using WarningLevel can also help you remove any potential hidden bugs within your application due to incorrect case or spelling in field names before you put your application into the Production environment.
WarningLevel only validates elements; it doesn't validate XML attributes. It also doesn't control warnings related to user-entered strings or numbers, or warnings for logical errors.
We recommend that you only use this during development and debugging. Do not use this in requests performed in the Production environment.