We get many errors when trying to update fields such as block, row, seat, restrictions, delivery type. Is there a reason the section are restricted ?
These fields are not 'restricted' by default, but they are validation-dependent.
In many cases, these errors occur because the metadata (Section/Row) does not match our internal map for that specific event/venue. It can also happen if there are already existing listings with the same configuration. We do not allow two listings with the same row/seat, or certain values like N/A depending on the event.
You can first use the Catalog endpoint to verify the allowed values for that venue before trying to update the listing. If you send a string that does not exist in our map, the API will reject it to prevent data inconsistency.
When will the access tokens expire?
The access tokens you generate using the generateToken API are valid for 6 months. When they expire, you can use the refreshToken API to get a new access token. The refreshToken API requires a "refresh token" that was given to you in the original generateToken API call. If you don't have that refresh token, you should use the generateToken API to get a new access token.
Note: We recommend you use the refreshToken API to get new access tokens when they expire. You DO NOT need to generate a new access token before 6 months.
The StubHub SDK contains visual components and a JavaScript library that rely on StubHub RESTful APIs. These APIS require a valid application key or token to access the StubHub event catalog.
Why should I use PATCH instead of making a full update with PUT?
When you need to make updates, using PATCH makes things easier because you can make a partial update instead of sending the entire payload. Let's say you need to update the price for your listing. You can just send the price update with PATCH in the payload instead of sending a PUT call with an entire payload.