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
Post
Replies
Boosts
Views
Activity
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.
1.1k watchers on this question and still no response from Apple other than the copypasta of my original question. Really disappointing to be honest, do better Apple!
I'm still looking for a way to do this if anyone has any new suggestions.
I will say that this thread right here is THE reason why Stack Overflow is a much better resource. Given how responsive Apple has been here (and on other threads) I can't imagine they do any better at reading the feedback forms that they always ask to be filled out. It's probably the equivalent of dev>null
Yeah, that's not quite the same. I wish it was though.
The request sent from the AppStoreConnect website to set store prices is a PATCH request and it sends the full schedule every time you add a single scheduled price change. (Instead of just sending the one change you create). That's why they've limited how far out you can schedule price changes, it takes too long for their servers to process the request if you go over a certain number of price changes in a single request.
It would be so much nicer if I could just schedule the changes on my end and send single requests saying "change the current price to X right now". It would be one change, it would be a single call and some date math on my end.
I really appreciate you sharing that link, I will take a look for sure.
I get that Stack Overflow is WAY better than here. (Obviously if you read this far) The point is that I can't find the solution on SO, and I can't find the solution in the docs even though there are hints of it.
To be honest it's just sad. And that's putting it nicely.
Thanks again for the link, I'll check it out. Like you said, that is IAP not store pricing but there might be a clue there.
Ok, how about this. Is there a way for me to report incomplete DocC in the online documentation or even ask questions? Sometimes the DocC content is vague and/or confusing and in other places (as noted above) it just doesn't exist.
I'm not going to file a 'Feedback Request' for a tool to report bad DocC to Apple, consider this my feedback and if this is a feature request please fill out the form for me and respond with the tracking number.
I'd also like to assist Apple's developers in improving their documentation by providing links to some helpful videos concerning DocC:
https://developer.apple.com/wwdc22/110369
https://developer.apple.com/wwdc23/10244
There is also a guy named Ethan that works at Apple that could help your developers to augment their documentation so I and the other 670+ developers looking for the answer to this question can find results without writing books of responses in hope of getting someone at Apple to respond.
Hope it's not too late, but your best bet is to email devprograms @ apple.com
The first few steps of this should get you what you need: https://developerinsider.co/how-to-create-a-verified-ios-mobile-device-management-mdm-profile/
Hope that helps!
(Sucks when they won't even give you a ****** answer. They should just shut this "forum" down and send us all over to stack overflow, the lack of replies to all the questions Google sends me to is just sad.)