Ok, FINALLY! I have a solution. I had to write an email to TC's email then send in a playground for testing to get this resolved. The issue was my JWT auth token. For every previous endpoint that I used I set the scope to the full URL and it worked fine. I did the same for this endpoint but that's what causes the 405. I have an issue with the 405 status code because it's not a bad method error, it's a bad token error. Apple says it works as intended. But it should really be a 401 Unauthorized, which would correctly indicate that the token is the issue. For anyone having this issue the scope for this endpoint should be the path only for the endpoint, or excluded. I was only able to get it to work by excluding the scope. Apple claims that it worked for them using the url.path I suspect there are other endpoints with the same response issue so if all else fails, remove the scope from your token and try again. Thanks to everyone who tried to help, I tried everything you suggested but in the end the issue was that a bad http status response sent me chasing an error in my code that did not exist. I'm not going to mark any answers as accepted because even though I am now unblocked, I don't think the solution actually solves the problem. Creating an auth token shouldn't require special exceptions to get random endpoints to accept authorization, and a returned status code should correctly indicate the problem.

Thank you for helping me resolve that issue. I just tested and was able to have success as well! 🍻

Sent, FB16492145 I included a Swift Playground, instructions for adding your API credentials are included in the comments. Thanks for getting back to me

I'm going to be honest, I asked this question in January of 2023 and never received an answer from Apple, at least not one that was worth a damn. I'm always told by App Review or Apple Employees to "ask on the forums", but I won't do that anymore. I also won't "file a feedback" because it's been 2 years since I notified Apple that when using Xcode Cloud to auto increment your build numbers, sending in a manual build breaks the auto increment. 2 years. It's still an issue. Apple doesn't care. Thanks to all that replied. Hopefully the Grok solution is a winner.

Thanks to Grok v2 I have a possible solution. This is what it tells me to try: According to the information available on Apple's App Store Connect API documentation, you can indeed set pricing for an app, but this is done through scheduled price changes rather than a direct pricing endpoint for immediate application. Here's how you can manage app pricing using the App Store Connect API: Endpoint: Scheduled Price Change for an App: Endpoint: POST /v1/apps/{id}/priceSchedules Request Format: To schedule a price change for an app, you would use the following structure: json { "data": { "attributes": { "startDate": "2024-12-31T00:00:00Z", "manualPrices": [ { "territory": "USA", "priceTier": "TIER_1" } ] }, "type": "appPriceSchedules" } } Explanation: startDate: The date when the price change should take effect. This needs to be in ISO 8601 format. manualPrices: An array of price changes for different territories. You specify the territory (country/region code) and the price tier. territory: ISO 3166-1 alpha-3 country code. For example, "USA" for the United States. priceTier: This is a string representing the price tier. Tiers range from TIER_1 to TIER_800 with possible additional higher tiers upon request. The exact mapping of these tiers to actual prices can be found in the App Store Connect web interface or through the GET /v1/pricePoints endpoint. Additional Points: Price Tiers: The actual monetary value associated with each tier can vary by country due to currency and tax differences. You can fetch current price points and tiers for different territories using GET /v1/pricePoints or get price information for an app with GET /v1/apps/{id}/pricePoints. Automatic Pricing: If you don't specify manual prices for all territories, Apple will automatically generate prices for other territories based on your base territory's price, considering local taxes and currency conversions. However, if you specify a manual price for a territory, that price will be fixed and not automatically adjusted by Apple. Permissions: You'll need the appropriate role (like Account Holder, Admin, or App Manager) to use these endpoints. Testing: Before pushing changes live, it's advisable to test your API calls in a controlled environment or with a test app to ensure everything works as expected. References: This information is based on Apple's App Store Connect API documentation, particularly related to managing app pricing and availability: For detailed API usage, including endpoints for price management, refer to the official documentation for App Store Connect API. Remember, the exact behavior and available endpoints might evolve, so always check the latest documentation or Apple's developer forums for the most current practices.

Still at it here, trying to use some of the new tools that have been introduced since I started this unidirectional question answer session. I thought it might be a good idea to try the new OpenAPI generator with the OpenAPI spec for the appstoreconnect api. But I'm encountering an issue there without even being able to get started. Leaving the issue number here for reference: https://github.com/apple/swift-openapi-generator/issues/580

Ten months in on this thread and 24k people watching. Anyone have a solution to this yet? It's really hard to debug when our tools are broken and Apple doesn't visit the developer forums anymore.

Well I've been posting questions on this thread for over a year now with no input from Apple. @Apple, you do know that the ability to change pricing on our apps is part of our developer agreement right? And you do realize that with each iteration on your web portal you reduce that ability? I can show that by not allowing me to set my pricing in the same way I did two years ago my monthly income on my apps has been reduced by $250. We are only 4 months into the year and I suspect that by the end of the year the financial impact will be greater. The reason I am trying to resolve the issue with the API is so I don't have to use the web interface which has degraded over the past year Now that all the cards are on the table here, how about we discuss this API issue as I have described in the above 2 pages of posts.

Ok, I'm now noticing 404's coming back from an API call that has worked for years now. Specifically this is the error: "errors" : [ { "id" : "90b84655-8c76-4647-b59c-e3bf357793ef", "status" : "404", "code" : "PATH_ERROR", "title" : "The URL path is not valid", "detail" : "The resource 'v1/appPriceSchedules' does not exist" } ] Now I know this error has to be false because in the documentation here if you view the sample response and look at "manualPrices" it has the exact URL that I am calling (with a different appID of course) "manualPrices" : { "links" : { "self" : "https://api.appstoreconnect.apple.com/v1/appPriceSchedules/6447402192/relationships/manualPrices", "related" : "https://api.appstoreconnect.apple.com/v1/appPriceSchedules/6447402192/manualPrices" } }, So can you explain why I'm now getting a 404 for this? Did something break on your end? Also, why are all of the deprecated endpoints in the API (that are specifically "v1") being replaced with endpoints that also contain "v1" in the URL? Best practice would be to make a "v2" for the new endpoint, then deprecate, then remove the "v1". I really hope you guys aren't just actively "upgrading" the v1 API in place because that's beginner level server development and it's a HUGE pain for your API users.

I realize it's a tough series of questions so while you're thinking about it (@Apple) can you also let me know why I am encountering so many 500 errors on calls that have worked fine for years? The errors seem to clear up after a while, but I'm not sure what the suggested delay should be for retrying a call that receives a 500. Currently I'm using 30m, does that sound reasonable to you guys?

In an email thread with Apple about pricing I was told that a "paid download" is determined by "the price of the app at the time the payment goes through". I dismissed it as oddly worded because obviously when I purchase the app in order to download it the payment should go through at that point in time. But now I'm curious, if I download an app when it is NOT free, but my payment doesn't go through until a time when the app IS free, does that count as a paid or free download and what is the user charged for the app? When someone checks again on this thread could they please clarify this along with the above questions?

As a follow up to the post above linking to the documentation for the appPriceSchedules API, a request that follows the documentation as written results in the following response: { "errors": [{ "status": "405", "code": "METHOD_NOT_ALLOWED", "title": "The request method is not valid for the resource path.", "detail": "The request method used for this request is not valid for the resource path. Please consult the documentation." }] }

I also noticed that the response from the API that returns a list of apps for an account changed yesterday afternoon. It was a breaking change in the JSON response for codables and I'm surprised this was done within the same version (API v1) and not for a newer version and a different endpoint. Is there a separate URL set for versions of the API or can we expect that current endpoints will randomly return responses from newer versions of the API as those roll out?

@Claude31 Maybe you can clarify this for me. Looking at this documentation https://developer.apple.com/documentation/appstoreconnectapi/add_a_scheduled_price_change_to_an_app It clearly specifies that this call is a POST yet sending a POST results in a 405 Method Not Allowed. It also specifies in the url that this is an API v1 request, but it is flagged as API 2.3+ The documentation on this page has been updated since I last referenced it but now it is very unclear, can you clarify which method should be used on this call and if the URL is correct? Also, are there any auth changes between v1 and v2.3 of the API?

Ok, now it's getting ridiculous. If we check the existing AppStoreConnect Documentation that I've referenced many times already (here) the entire thing has been deprecated. BUT following the link to (Set a price) takes you to new information on setting a price that includes a link titled "Learn how to set a price for your app with the App Store Connect API" and that link takes you back to ... The first link that has everything deprecated and nothing about setting a price. 🤯 The UI for setting prices manually in the web interface has been updated and it is probably the worst it's ever been. It will show you scheduled prices changes but won't tell you what the price is for that change unless you click on it. The calendar is still "stupid", meaning it doesn't default to the next available day after the last scheduled change so you can easily goof up your schedule if you have to set a bunch of changes. You can only schedule one change at a time. So if I want all of my Saturdays to be free I have to do that 52 times for a year then go back and do another 52 changes to set the price back to paid. (Then you start getting 500 errors from the server because it can't handle that "large" of a request) The web interface now uses a POST to send the pricing updates, but every time you send a scheduled price change it sends the entire list of scheduled price changes to the server, not just the one you are setting. So every time you add a price change the request gets bigger. (The JSON format is pretty bad, you could cut the payload by half by simply cleaning up the payload) Here's the thing, all I'm asking for is an API call where I can set the current price of my app effective immediately and with a simple "price=tierX" payload. I don't want to deal with the horrible web interface and I don't think it's too much to ask because the API call is already in place for the web UI, it just needs to be made available through the ASC API.