ReviseInventoryStatus
This call enables a seller to change the price and/or quantity of up to four active, fixed-price listings. The fixed-price listing(s) to modify are identified with the ItemID of the listing or the SKU value of the item (if a seller-defined SKU value exists for the listing).
This call can be used to update both single-variation and multiple-variation listings. For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation.
Note: The ReviseFixedPriceItem call can also be used to update the price and/or quantity of a variation within a multiple-variation listing, passing in the updated price or quantity information through the corresponding Variations.Variation node for that product variation.
This call also has the following restrictions/limitations. Make sure you read these before proceeding to make ReviseInventoryStatus calls.
Short-duration call rate limit: To protect eBay's infrastructure and servers from being overloaded and/or destabilized, the ReviseInventoryStatus call has a short-duration call rate limit to restrict bursts of very high traffic.
Per (seller) user ID, no more than 6000 ReviseInventoryStatus calls can be executed within any 15-second interval. If this call rate limit is exceeded at any time, the application making the called is blocked. Each time an application is blocked, the user/application must wait until the block is reset after 15 seconds. This short-duration call rate limit applies to all seller accounts, and sellers/developers cannot appeal or request for a higher limit.
Incompatibility with Inventory model listings: An active listing that was created with the new Inventory model (using the Inventory API or Merchant Integration Platform) cannot be revised using the ReviseFixedPriceItem, ReviseItem, or ReviseInventoryStatus calls. Instead, the seller will need to use the Inventory API or MIP.
Note to Sell Feed API users: When you use this call with the Sell Feed API, you must wrap the file to be uploaded within BulkDataExchangeRequest tags, which will also be returned in the response. This container is not shown in the standard Input/Output sections for this call. See XML data files overview in the LMS Feed API Guide for additional information.
See Revise a listing.
See also the reference documentation for this call:
- ReviseItem - Enables a seller to revise a listing on a specified eBay site.
Input
See also Samples.
The box below lists all fields that could be included in the call request. To learn more about an individual field or its type, click its name in the box (or scroll down to find it in the table below the box).
See also the Deprecated Objects link above. Fields presented in this color are deprecated, and fields presented in this color are (or soon will be) non-operational.
The XML prototype does not include requester credentials. This is a documentation limitation only (see Standard Requester Credentials for Making Calls).
<?xml version="1.0" encoding="utf-8"?> <ReviseInventoryStatusRequest xmlns="urn:ebay:apis:eBLBaseComponents"> <!-- Call-specific Input Fields --> <InventoryStatus> InventoryStatusType <ItemID> ItemIDType (string) </ItemID> <Quantity> int </Quantity> <SKU> SKUType (string) </SKU> <StartPrice> AmountType (double) </StartPrice> </InventoryStatus> <!-- ... more InventoryStatus nodes allowed here ... --> <!-- Standard Input Fields --> <ErrorLanguage> string </ErrorLanguage> <MessageID> string </MessageID> <Version> string </Version> <WarningLevel> WarningLevelCodeType </WarningLevel> </ReviseInventoryStatusRequest>
| Argument | Type | Occurrence | Meaning |
|---|
Call-specific Input Fields
[Jump to standard fields]
InventoryStatus
InventoryStatusType
Required,
repeatable: [1..4] One InventoryStatus container is required for each item or item variation that is being revised. Whether updating the price and/or quantity of a single-variation listing or a specific variation within a multiple-variation listing, the limit of items or item variations that can be modified with one call is four.
repeatable: [1..4] One InventoryStatus container is required for each item or item variation that is being revised. Whether updating the price and/or quantity of a single-variation listing or a specific variation within a multiple-variation listing, the limit of items or item variations that can be modified with one call is four.
InventoryStatus.ItemID
ItemIDType (string)
Conditional
The unique identifier of the listing being revised.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
Note: When using an LMS_REVISE_INVENTORY_STATUS upload feed in Sell Feed API to revise the price and/or quantity for multiple SKUs for a multiple-SKU listing, you must include both the ItemID and SKU values for each variation. See the Upload flow and Inventory upload feed types for more information. Please note that the same ItemID value can be used multiple times in the same call if you revise several item variations from the same multiple-variation listing.
The ItemID field is always returned in the response, even if an ItemID value was not included in the request.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
ItemID, the ItemID field should be used. If the value of InventoryTrackingMethod is SKU, the SKU field should be used. ItemID is the default value of InventoryTrackingMethod, and its value can only be set/changed to SKU through either an AddFixedPriceItem or RelistFixedPriceItem call. For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
ItemID. However, if the InventoryTrackingMethod value is set to SKU, only the SKU value of the item variation is needed to identify a specific item variation. Note that a seller-defined SKU value is required when a seller creates a multiple-variation listing, regardless of whether they decide to track inventory by Item ID or SKU. Note: When using an LMS_REVISE_INVENTORY_STATUS upload feed in Sell Feed API to revise the price and/or quantity for multiple SKUs for a multiple-SKU listing, you must include both the ItemID and SKU values for each variation. See the Upload flow and Inventory upload feed types for more information. Please note that the same ItemID value can be used multiple times in the same call if you revise several item variations from the same multiple-variation listing.
The ItemID field is always returned in the response, even if an ItemID value was not included in the request.
InventoryStatus.Quantity
int
Conditional
This field is used to update the quantity of a fixed-price listing, or to update the quantity of a variation within a multiple-variation listing. To update a variation, both the ItemID and SKU fields are required to identify the listing and the specific variation within that listing, respectively.
In each InventoryStatus container, either StartPrice or Quantity (or both) are required.
Note: The Quantity field should no longer appear in the response payload. If it does appear, it can be ignored. Sellers can leverage the GetItem call to verify that the requested quantity updates were successful.
In each InventoryStatus container, either StartPrice or Quantity (or both) are required.
Note: The Quantity field should no longer appear in the response payload. If it does appear, it can be ignored. Sellers can leverage the GetItem call to verify that the requested quantity updates were successful.
InventoryStatus.SKU
SKUType (string)
Conditional
This value is the seller-defined SKU value of the item being revised.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
Note: When using an LMS_REVISE_INVENTORY_STATUS upload feed in Sell Feed API to revise the price and/or quantity for multiple SKUs for a multiple-SKU listing, you must include both the ItemID and SKU values for each variation. See the Upload flow and Inventory upload feed types for more information. The SKU field is always returned in the response, and if a SKU value doesn't exist for a single-variation listing, it is returned as an empty tag.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
ItemID, the ItemID field should be used. If the value of InventoryTrackingMethod is SKU, the SKU field should be used. ItemID is the default value of InventoryTrackingMethod, and its value can only be set/changed to SKU through either an AddFixedPriceItem or RelistFixedPriceItem call. For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
ItemID. However, if the InventoryTrackingMethod value is set to SKU, only the SKU value of the item variation is needed to identify a specific item variation. Note that a seller-defined SKU value is required when a seller creates a multiple-variation listing, regardless of whether they decide to track inventory by Item ID or SKU. Note: When using an LMS_REVISE_INVENTORY_STATUS upload feed in Sell Feed API to revise the price and/or quantity for multiple SKUs for a multiple-SKU listing, you must include both the ItemID and SKU values for each variation. See the Upload flow and Inventory upload feed types for more information. The SKU field is always returned in the response, and if a SKU value doesn't exist for a single-variation listing, it is returned as an empty tag.
InventoryStatus.StartPrice
AmountType (double)
Conditional
This field is used to update the price of a fixed-price item, or to update the price of an item variation within a multiple-variation listing. To update the price of an item variation, both the ItemID and SKU fields are required to identify the listing and the specific variation within that listing, respectively.
In each InventoryStatus container, either StartPrice or Quantity (or both) are required.
Note: The StartPrice field should no longer appear in the response payload. If it does appear, it can be ignored. Sellers can leverage the GetItem call to verify that the requested price updates were successful.
In each InventoryStatus container, either StartPrice or Quantity (or both) are required.
Note: The StartPrice field should no longer appear in the response payload. If it does appear, it can be ignored. Sellers can leverage the GetItem call to verify that the requested price updates were successful.
Standard Input Fields
| ErrorLanguage | string | Optional |
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. Below are some examples from different countries.
|
||||||||||||||||||||||||||||||||||||||||
| MessageID | string | Optional |
Most Trading API calls support a MessageID element in the request and a CorrelationID element in the response. If you pass in a MessageID in a request, the same value will be returned in the CorrelationID field in the response. Pairing these values can help you track and confirm that a response is returned for every request and to match specific responses to specific requests. If you do not pass a MessageID value in the request, CorrelationID is not returned. 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. |
||||||||||||||||||||||||||||||||||||||||
| Version | string | Conditional |
The version number of the API code that you are programming against (e.g., 1149). The version you specify for a call has these basic effects:
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.) See:
|
||||||||||||||||||||||||||||||||||||||||
| WarningLevel | WarningLevelCodeType | Optional |
Controls whether or not to return warnings when the application passes unrecognized or deprecated elements in a request. 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. Applicable values: High if the user wishes to receive warnings when the application passes unrecognized or deprecated elements in an API call request. Setting the WarningLevel value to High is not recommended in a production environment. Instead, it should only be used during the development/debugging stage.Low if the user does not wish to receive warnings when the application passes unrecognized or deprecated elements in an API call request. This is the default value if WarningLevel is not specified in the call request.See Warning Level. |
Output
See also Samples.
The box below lists all fields that might be returned in the response. To learn more about an individual field or its type, click its name in the box (or scroll down to find it in the table below the box).
See also the Deprecated Objects link above. Fields presented in this color are deprecated, and fields presented in this color are not returned (or soon will not be returned) or are not operational (or soon will be non-operational).
<?xml version="1.0" encoding="utf-8"?> <ReviseInventoryStatusResponse xmlns="urn:ebay:apis:eBLBaseComponents"> <!-- Call-specific Output Fields --> <Fees> InventoryFeesType <Fee> FeeType <Fee currencyID="CurrencyCodeType"> AmountType (double) </Fee> <Name> string </Name> <PromotionalDiscount currencyID="CurrencyCodeType"> AmountType (double) </PromotionalDiscount> </Fee> <!-- ... more Fee nodes allowed here ... --> <ItemID> ItemIDType (string) </ItemID> </Fees> <!-- ... more Fees nodes allowed here ... --> <InventoryStatus> InventoryStatusType <ItemID> ItemIDType (string) </ItemID> <SKU> SKUType (string) </SKU> </InventoryStatus> <!-- ... more InventoryStatus nodes allowed here ... --> <!-- Standard Output Fields --> <Ack> AckCodeType </Ack> <Build> string </Build> <CorrelationID> string </CorrelationID> <Errors> ErrorType <ErrorClassification> ErrorClassificationCodeType </ErrorClassification> <ErrorCode> token </ErrorCode> <ErrorParameters ParamID="string"> ErrorParameterType <Value> string </Value> </ErrorParameters> <!-- ... more ErrorParameters nodes allowed here ... --> <LongMessage> string </LongMessage> <SeverityCode> SeverityCodeType </SeverityCode> <ShortMessage> string </ShortMessage> </Errors> <!-- ... more Errors nodes allowed here ... --> <HardExpirationWarning> string </HardExpirationWarning> <Timestamp> dateTime </Timestamp> <Version> string </Version> </ReviseInventoryStatusResponse>
| Return Value | Type | Occurrence | Meaning |
|---|
Call-specific Output Fields
[Jump to standard fields]
Fees
InventoryFeesType
Always,
repeatable: [1..4] A Fees container is returned for each fixed-price listing that was modified with the ReviseInventoryStatus call. This container consists of the estimated listing fees for the revised listing, and the listing is identified in the ItemID field. Each type of fee is returned even if it is not applicable (has a value of
Please note that since fees are returned at the listing level, it is possible that the response will include one Fees container and four InventoryStatus containers if you made revisions to four different item variations within the same multiple-variation listing.
repeatable: [1..4] A Fees container is returned for each fixed-price listing that was modified with the ReviseInventoryStatus call. This container consists of the estimated listing fees for the revised listing, and the listing is identified in the ItemID field. Each type of fee is returned even if it is not applicable (has a value of
0.0. The transaction fees are not in this container, as these values cannot be determined until a sale is made. Note that these fees are at the listing level, so if multiple variations within a multiple-variation listing were modified, the fees in this container would be cumulative totals, and would not single out the fees associated with each modified item variation. Please note that since fees are returned at the listing level, it is possible that the response will include one Fees container and four InventoryStatus containers if you made revisions to four different item variations within the same multiple-variation listing.
See:
eBay.com Fees
Fees by marketplace
Fees and credits
Final Value Fees
Fees.Fee
FeeType
Always,
repeatable: [1..*] Contains the data for one fee (such as name and amount).
repeatable: [1..*] Contains the data for one fee (such as name and amount).
Fees.Fee.Fee
AmountType (double)
Always
Amount of the fee that eBay will charge the member for the associated listing feature.
See eBay.com Fees for a current list of listing features and their associated fees..
Fees.Fee.Fee
[ attribute currencyID ] CurrencyCodeType Always Amount of the fee that eBay will charge the member for the associated listing feature.
For a list of possible enumeration values, see CurrencyCodeType.
[ attribute currencyID ] CurrencyCodeType Always Amount of the fee that eBay will charge the member for the associated listing feature.
For a list of possible enumeration values, see CurrencyCodeType.
Fees.Fee.Name
string
Always
This is the name of the listing feature, such as
ListingFee, SubtitleFee, or BoldFee.
See Fees.
Fees.Fee.PromotionalDiscount
AmountType (double)
Always
This field exists in the response when the user has selected a feature that participates in a promotional discount.
Note: Verify calls might not return the PromotionalDiscount fee in the response.
Note: Verify calls might not return the PromotionalDiscount fee in the response.
See Standard selling fees for A current schedule of listing features and their associated fees..
Fees.Fee.PromotionalDiscount
[ attribute currencyID ] CurrencyCodeType Always This field exists in the response when the user has selected a feature that participates in a promotional discount.
Note: Verify calls might not return the PromotionalDiscount fee in the response.
For a list of possible enumeration values, see CurrencyCodeType.
[ attribute currencyID ] CurrencyCodeType Always This field exists in the response when the user has selected a feature that participates in a promotional discount.
Note: Verify calls might not return the PromotionalDiscount fee in the response.
For a list of possible enumeration values, see CurrencyCodeType.
Fees.ItemID
ItemIDType (string)
Always
The unique identifier of the listing being changed.
The ReviseInventoryStatus response includes a separate set of fees for each item that was successfully revised.
Use the ItemID to correlate the Fees data with the Inventory Status data in the response.
The ReviseInventoryStatus response includes a separate set of fees for each item that was successfully revised.
Use the ItemID to correlate the Fees data with the Inventory Status data in the response.
InventoryStatus
InventoryStatusType
Always,
repeatable: [1..4] One InventoryStatus container is returned for each item or item variation that was revised. Whether updating the price and/or quantity of a single-variation listing or a specific variation within a multiple-variation listing, the limit of items or item variations that can be modified with one call is four.
Note that the SKU field is returned as an empty tag if it is not defined for a single-variation listing.
repeatable: [1..4] One InventoryStatus container is returned for each item or item variation that was revised. Whether updating the price and/or quantity of a single-variation listing or a specific variation within a multiple-variation listing, the limit of items or item variations that can be modified with one call is four.
Note that the SKU field is returned as an empty tag if it is not defined for a single-variation listing.
InventoryStatus.ItemID
ItemIDType (string)
Always
The unique identifier of the listing being revised.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
Note: When using an LMS_REVISE_INVENTORY_STATUS upload feed in Sell Feed API to revise the price and/or quantity for multiple SKUs for a multiple-SKU listing, you must include both the ItemID and SKU values for each variation. See the Upload flow and Inventory upload feed types for more information. Please note that the same ItemID value can be used multiple times in the same call if you revise several item variations from the same multiple-variation listing.
The ItemID field is always returned in the response, even if an ItemID value was not included in the request.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
ItemID, the ItemID field should be used. If the value of InventoryTrackingMethod is SKU, the SKU field should be used. ItemID is the default value of InventoryTrackingMethod, and its value can only be set/changed to SKU through either an AddFixedPriceItem or RelistFixedPriceItem call. For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
ItemID. However, if the InventoryTrackingMethod value is set to SKU, only the SKU value of the item variation is needed to identify a specific item variation. Note that a seller-defined SKU value is required when a seller creates a multiple-variation listing, regardless of whether they decide to track inventory by Item ID or SKU. Note: When using an LMS_REVISE_INVENTORY_STATUS upload feed in Sell Feed API to revise the price and/or quantity for multiple SKUs for a multiple-SKU listing, you must include both the ItemID and SKU values for each variation. See the Upload flow and Inventory upload feed types for more information. Please note that the same ItemID value can be used multiple times in the same call if you revise several item variations from the same multiple-variation listing.
The ItemID field is always returned in the response, even if an ItemID value was not included in the request.
InventoryStatus.SKU
SKUType (string)
Always
This value is the seller-defined SKU value of the item being revised.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
Note: When using an LMS_REVISE_INVENTORY_STATUS upload feed in Sell Feed API to revise the price and/or quantity for multiple SKUs for a multiple-SKU listing, you must include both the ItemID and SKU values for each variation. See the Upload flow and Inventory upload feed types for more information. The SKU field is always returned in the response, and if a SKU value doesn't exist for a single-variation listing, it is returned as an empty tag.
For a single-variation listing, either the ItemID of the listing or the SKU value of the item (if it exists) is required, and which one to use will depend on the value of the InventoryTrackingMethod setting. If the value of InventoryTrackingMethod is
ItemID, the ItemID field should be used. If the value of InventoryTrackingMethod is SKU, the SKU field should be used. ItemID is the default value of InventoryTrackingMethod, and its value can only be set/changed to SKU through either an AddFixedPriceItem or RelistFixedPriceItem call. For a multiple-variation listing, the SKU value of the item variation is required in order to identify a specific item variation. An ItemID field is also required if the InventoryTrackingMethod value is set to
ItemID. However, if the InventoryTrackingMethod value is set to SKU, only the SKU value of the item variation is needed to identify a specific item variation. Note that a seller-defined SKU value is required when a seller creates a multiple-variation listing, regardless of whether they decide to track inventory by Item ID or SKU. Note: When using an LMS_REVISE_INVENTORY_STATUS upload feed in Sell Feed API to revise the price and/or quantity for multiple SKUs for a multiple-SKU listing, you must include both the ItemID and SKU values for each variation. See the Upload flow and Inventory upload feed types for more information. The SKU field is always returned in the response, and if a SKU value doesn't exist for a single-variation listing, it is returned as an empty tag.
Standard Output Fields
Ack
AckCodeType
Always
A token representing the application-level acknowledgement code that indicates the response status (e.g., success). The AckCodeType list specifies the possible values for the Ack field.
Applicable values:
CustomCode
(out) Reserved for internal or future use.
Failure
(out) This value indicates that the call request processing failed.
Success
(out) This value indicates that the call request was processed successfully without any issues.
Warning
(out) This value indicates that the call request was successful, but processing was not without any issues. These issues can be checked in the Errors container, that will also be returned when one or more known issues occur with the call request.
(Not all values in AckCodeType apply to this field.)
Code so that your app gracefully handles any future changes to this list.
Applicable values:
(Not all values in AckCodeType apply to this field.)
Code so that your app gracefully handles any future changes to this list.
Build
string
Always
This refers to the specific software build that eBay used when processing the request and generating the response. This includes the version number plus additional information. eBay Developer Support may request the build information when helping you resolve technical issues.
CorrelationID
string
Conditionally
Most Trading API calls support a MessageID element in the request and a CorrelationID element in the response. If you pass in a MessageID in a request, the same value will be returned in the CorrelationID field in the response. Pairing these values can help you track and confirm that a response is returned for every request and to match specific responses to specific requests. If you do not pass a MessageID value in the request, CorrelationID is not returned.
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.
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.
Errors
ErrorType
Conditionally,
repeatable: [0..*] A list of application-level errors (if any) that occurred when eBay processed the request.
repeatable: [0..*] A list of application-level errors (if any) that occurred when eBay processed the request.
Errors.ErrorClassification
ErrorClassificationCodeType
Conditionally
API errors are divided between two classes: system errors and request errors.
Applicable values:
CustomCode
(out) Reserved for internal or future use.
RequestError
(out) An error has occurred either as a result of a problem in the sending application or because the application's end-user has attempted to submit invalid data (or missing data). In these cases, do not retry the request. The problem must be corrected before the request can be made again. If the problem is due to something in the application (such as a missing required field), the application must be changed. If the problem is a result of end-user data, the application must alert the end-user to the problem and provide the means for the end-user to correct the data. Once the problem in the application or data is resolved, resend the request to eBay with the corrected data.
SystemError
(out) Indicates that an error has occurred on the eBay system side, such as a database or server down. An application can retry the request as-is a reasonable number of times (eBay recommends twice). If the error persists, contact Developer Technical Support. Once the problem has been resolved, the request may be resent in its original form.
Code so that your app gracefully handles any future changes to this list.
Applicable values:
Code so that your app gracefully handles any future changes to this list.
Errors.ErrorCode
token
Conditionally
A unique code that identifies the particular error condition that occurred. Your application can use error codes as identifiers in your customized error-handling algorithms.
See Errors By Number.
Errors.ErrorParameters
ErrorParameterType
Conditionally,
repeatable: [0..*] This optional element carries a list of context-specific error variables that indicate details about the error condition. These are useful when multiple instances of ErrorType are returned.
repeatable: [0..*] This optional element carries a list of context-specific error variables that indicate details about the error condition. These are useful when multiple instances of ErrorType are returned.
Errors.ErrorParameters
[ attribute ParamID ] string Conditionally This optional element carries a list of context-specific error variables that indicate details about the error condition. These are useful when multiple instances of ErrorType are returned.
[ attribute ParamID ] string Conditionally This optional element carries a list of context-specific error variables that indicate details about the error condition. These are useful when multiple instances of ErrorType are returned.
Errors.ErrorParameters.Value
string
Conditionally
This is the value of the request parameter noted in the ParamID attribute. So, if the ParamID value was ItemID, the value in this field would be the actual value of that ItemID.
Errors.LongMessage
string
Conditionally
A more detailed description of the condition that raised the error.
Errors.SeverityCode
SeverityCodeType
Conditionally
Indicates whether the error is a severe error (causing the request to fail) or an informational error (a warning) that should be communicated to the user.
Applicable values:
CustomCode
(out) Reserved for internal or future use.
Error
(out) The request that triggered the error was not processed successfully. When a serious application-level error occurs, the error is returned instead of the business data.
If the source of the problem is within the application (such as a missing required element), change the application before you retry the request.
See the Error handling section of the Making a Trading API call guide for more information.
Warning
(out) The request was processed successfully, but something occurred that may affect your application or the user. For example, eBay may have changed a value the user sent in. In this case, eBay returns a normal, successful response and also returns the warning.
When a warning occurs, the error is returned in addition to the business data. In this case, you do not need to retry the request (as the original request was successful). However, depending on the cause or nature of the warning, you might need to contact either the end user or eBay to effect a long term solution to the problem to prevent it from reoccurring in the future.
Code so that your app gracefully handles any future changes to this list.
Applicable values:
If the source of the problem is within the application (such as a missing required element), change the application before you retry the request.
- If the problem is due to end-user input data, please alert the end-user to the problem and provide the means for them to correct the data. Once the problem in the application or data is resolved, you can attempt to re-send the request to eBay.
- If the source of the problem is on eBay's side, An application can retry the request as-is a reasonable number of times (eBay recommends twice). If the error persists, contact Developer Technical Support. Once the problem has been resolved, the request may be resent in its original form.
See the Error handling section of the Making a Trading API call guide for more information.
When a warning occurs, the error is returned in addition to the business data. In this case, you do not need to retry the request (as the original request was successful). However, depending on the cause or nature of the warning, you might need to contact either the end user or eBay to effect a long term solution to the problem to prevent it from reoccurring in the future.
Code so that your app gracefully handles any future changes to this list.
Errors.ShortMessage
string
Conditionally
A brief description of the condition that raised the error.
HardExpirationWarning
string
Conditionally
Expiration date of the user's authentication token. Only returned within the 7-day period prior to a token's expiration. To ensure that user authentication tokens are secure and to help avoid a user's token being compromised, tokens have a limited life span. A token is only valid for a period of time (set by eBay). After this amount of time has passed, the token expires and must be replaced with a new token.
Timestamp
dateTime
Always
This value represents the date and time when eBay processed the request. The time zone of this value is GMT and the format is the ISO 8601 date and time format (YYYY-MM-DDTHH:MM:SS.SSSZ). See the Time Values section in the eBay Features Guide for information about this time format and converting to and from the GMT time zone.
Note: GetCategories and other Trading API calls are 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, this time value reflects the time the cached response was created. Thus, this value is not necessarily when the request was processed. 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, this time value does reflect when the request was processed.
Note: GetCategories and other Trading API calls are 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, this time value reflects the time the cached response was created. Thus, this value is not necessarily when the request was processed. 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, this time value does reflect when the request was processed.
Version
string
Always
The version of the response payload schema. Indicates the version of the schema that eBay used to process the request. See the Standard Data for All Calls section in the eBay Features Guide for information on using the response version when troubleshooting CustomCode values that appear in the response.
Input
Output
Detail Controls
Samples
Change History
Detail Controls
DetailLevel
This call does not support varying Detail Levels. You do not need to pass DetailLevel in the request.
Input
Output
Detail Controls
Samples
Change History
Samples
New to making API calls? Please see Making a Call.
Note: Some item IDs, user IDs, or other data in these samples might no longer be active on eBay. If necessary, you can substitute current eBay data in your requests.
Sample: Basic Call
Revises price and quantity for multiple active listings
Description
The user named m***************r has a listing for MacBook Pro's which shows a quantity of 6. She just received another six of them, and wants to change the quantity listed to 12.
Input
To revise the quantity, the user must specify the ItemID and the new Quantity.
XML format.
<?xml version="1.0" encoding="utf-8"?>
<ReviseInventoryStatusRequest xmlns="urn:ebay:apis:eBLBaseComponents">
<RequesterCredentials>
<eBayAuthToken>ABC...123 OF SELLER</eBayAuthToken>
</RequesterCredentials>
<ErrorLanguage>en_US</ErrorLanguage>
<WarningLevel>High</WarningLevel>
<InventoryStatus>
<ItemID>1**********7</ItemID>
<Quantity>20</Quantity>
</InventoryStatus>
<InventoryStatus>
<SKU>c******2</SKU>
<ItemID>1**********4</ItemID>
<Quantity>20</Quantity>
</InventoryStatus>
<InventoryStatus>
<ItemID>1**********5</ItemID>
<StartPrice>9.95</StartPrice>
</InventoryStatus>
<InventoryStatus>
<SKU>c******2</SKU>
<ItemID>1**********6</ItemID>
<StartPrice>19.95</StartPrice>
<Quantity>80</Quantity>
</InventoryStatus>
</ReviseInventoryStatusRequest>
Output
Success in making the call is indicated by the "Success" value of the Ack field. The response indicates the revised values of the fields that ReviseInventoryStatus can change, Quantity among them, and shows any fees charged due to the revision.
XML format.
<?xml version="1.0" encoding="utf-8"?>
<ReviseInventoryStatusResponse xmlns="urn:ebay:apis:eBLBaseComponents">
<Timestamp>2019年11月06日T20:34:31.906Z</Timestamp>
<Ack>Success</Ack>
<Version>1131</Version>
<Build>E1131_UNI_API5_19098188_R1</Build>
<InventoryStatus>
<SKU/>
<ItemID>1**********7</ItemID>
<StartPrice>8.95</StartPrice>
<Quantity>20</Quantity>
</InventoryStatus>
<InventoryStatus>
<SKU>1***********A</SKU>
<ItemID>1**********4</ItemID>
<StartPrice>11.95</StartPrice>
<Quantity>20</Quantity>
</InventoryStatus>
<InventoryStatus>
<SKU>1***********B</SKU>
<ItemID>1**********5</ItemID>
<StartPrice>9.95</StartPrice>
<Quantity>37</Quantity>
</InventoryStatus>
<InventoryStatus>
<SKU>1***********C</SKU>
<ItemID>1**********6</ItemID>
<StartPrice>19.95</StartPrice>
<Quantity>80</Quantity>
</InventoryStatus>
</ReviseInventoryStatusResponse>
</BulkDataExchangeResponse>
Input
Output
Detail Controls
Samples
Change History
Change History
| Change Date | Description |
|---|---|
| 1257 2022年05月06日 |
|
| 0747 2011年11月09日 |
|
| 0695 2010年11月10日 |
|
| 0629 2009年08月05日 |
|
| 0625 2009年07月08日 |
|
| 0623 2009年06月24日 |
|
| 0589 2008年10月30日 |
|