very exciting! however i still haven't gotten the existing endpoints to do anything other than return http 500, has anyone had any luck with them yet? i posted about this a few months ago

Hi @Jonathan MacKenzie, in your previous post, you mentioned that you weren't able to get the

POST /services/rest/suiteappcontrolcenter/v1/suiteapp/<applicationId>/version

endpoint to work. Have you also tried the

GET /services/rest/suiteappcontrolcenter/v1/suiteapp/<applicationId>/installation

endpoint? If so, did you get the same result? In both cases, the application ID is the one you can find in the URL of your SuiteApp in the SuiteApp Marketplace, for example:

com.netsuite.bankfeeds

. Have you tried calling these endpoints recently? If so, I can check the error logs. Also, what application or tool are you using to call the endpoints? And have you created the integration record as described in the Help Center? nlcorp.app.netsuite.com/app/help/helpcenter.nl?fid=article_0105013037.h…

hi @Milan Kostelnik thanks for the reply! i just retried and the

POST

endpoint is still returning 500, the

GET

endpoint is working as expected though. if i change the application id to something incorrect for the

GET

endpoint i get 400 but if i do the same for the

POST

i still get 500. i am seeing one thing that disagrees with my previous post though: if i tamper with the auth header in the

POST

i still get 500 rather than the 401 i get doing the same for the

GET

. most likely this was the behaviour before and i just reported it inaccurately, confusing the behaviour of the

GET

with the

POST

i'm making the calls from node using form-data to build the multipart form and axios to send the requests. i tried removing the

file

from the form or replacing it with a short hardcoded string, this still returns 500. between that and still getting 500 when i tamper with the authorization header it seems whatever's breaking is breaking early before it has the chance to validate anything. the integration record was created according to those docs and seems to be working properly for the

GET

endpoint. the logs on the record are blank, no leads on why i'm getting 500 from the

POST

. if you are able to access error logs with more information that'd be very helpful!

Hi @Jonathan MacKenzie, I identified the root cause and created an issue for it. I'll let you know once it's deployed to production.

Great, thanks!

Hi @Jonathan MacKenzie, the issue should be fixed now. Could you please try it once again? Thank you.

@Milan Kostelnik i can confirm it is working for me now, thank you!

I'm happy to hear that it helped. As mentioned in the release notes you referred to, version 26.2 includes a couple of enhancements and two new endpoints. I believe these additions cover the basic CI/CD pipeline needed to automate the delivery of new SuiteApp versions to customers. Could you please share your feedback on whether you find these enhancements useful and sufficient? Also, if there's anything missing that you would like to see in future releases, I'd really appreciate hearing your thoughts.

my team and i are very excited about the new endpoints, the ability to programmatically push to customers is something we've wanted for a long time and having the ability to create and publish versions through the api is going to be very handy. as far as the release cycle goes i think with the new endpoints we should be covered! if there is any concern it might be that the upgrade endpoint's param is "version" rather than phase, so we'd need to know the current leading/lagging version of the app we want to push. the ability to get the current live version numbers for a suiteapp would remove the possibility of supplying the wrong one, or the ability to just specify which phase to release one thing we'd really like to see in a future release would be the ability to provision and deprovision suiteapps through this API (ie add/remove access for accounts)

Really appreciate your feedback, thank you!