I’d find it cleaner just to have one call to see if the api key is valid rather then have the actual requests error saying its not a valid api key. If you tried to do a messagingservice publish request, you’d need information on what universe the api key has access too anyways or it’ll also throw a unauthorized error if the api key is valid, or a invalid api key if the api key is invalid, two errors in one request.
Some APIs require the api key’s unique identifier;
checking what the specific api key access permissions are
(uuid needed, not sure if owner account access is needed)
adding permissions to the specific api key
(given access to owners account, you need the api uuid)
enable and disable specific api keys
One case I can think of right now is having access to this information allows pipelines; you can have interfaces for defining and setting up API keys for automation of external api systems.
A pipeline could be such as setting up a collection of api keys to read the datastores of multiple places at once and combining the data with some transformation callback.
Another could be mass-publishing messages to all your games for a announcement system saying a new game is out.
Another is having multiple accounts with api keys for different types of uploaded assets for organization / per-employee asset separation.
And recently you can have it automate the reading of your inventory as well on multiple accounts.
Got it. So to summarize, the request here is that it would be useful to have an endpoint that takes an API Key secret and returns whether it is valid or not? Or are you also asking to return the UUID somehow? Just trying to clarify what is desired
Nice update! I think for a start, this is great. Transitioning familiarity from one API to another always has a learning curve. With that aside, majority use-cases fall under group update roles (user & batch users). Not a ton that I can immediately support in my library overhaul until that functionality is eventually added.
That being said, super useful for quick-lookups that don’t cost a ton.
This is cool and just what I needed, thanks for making it!
I believe there is a bug with credentials owned by groups. I am experiencing authorization errors though on the group endpoints. If I go into the Postman docs and send a request with the same OpenCloud API key I use for other requests owned by a group, after granting it the Groups permission, I get a 401 with the error
I honestly expected the ability to set users’ group ranks via the API when it was announced earlier in the year.
Please add the ability for us to set group ranks of members in the group with the API. It would help a ton as my staff has to manually rank certain players that meet criteria and whatnot.
This new one does not fix anything. Users need the permission to change group roles without sharing cookies (automatic ranking). Until then, I doubt this will ever be used.
Hmm just looked through the documentation and it doesn’t seem like we specified it anywhere but Group API Keys are not supported for either of these APIs as of right now. Only User API Keys can be used. We’ll update the DevForum post and docs to specify this limitation.
This is the error returned when the API Key is just straight up invalid (which is the case here since you changed a character in it)
Great work, but the Group API is underwhelming, especially with the time it took to get it. It would be great if we had the ability to WRITE to the group.
Yes, we’re working on this for Data Stores! Moving cross-server messaging to cloud/ isn’t currently being worked on, but we would like to do it eventually.
I’m sorry if this is a silly question, but I noticed today on both Chrome, Firefox and mobile that I can’t access any more than 100 of my models in the My Inventory section. 25+ pages of models seem to be gone, as the ‘page next’ is disabled at page 4 (100 items). This affects my development considerably to apparently have lost access to a vast majority of the models in my inventory.
Apologies if it is a coincidence, but between seeing seeing ‘100 requests/min per API key’, your example matching so closely to the parameters of the bug report(s) - this certainly caught my eye.
Is it Open Cloud issues? I have been having issues lately like every instance of my search bar site-wide being turned into a live log-in field, and now as a site end-user am losing access to significant chunks of My Inventory to apparent rate-limiting to max 100 items.
The Open Cloud Inventory API is unrelated to how the information on the “My Inventory” page is populated. Not sure why this error is currently occurring but I know the website can sometimes be flaky at times (which is why it is preferred to use the Open Cloud APIs if possible ).
Not sure exactly what you mean by this. Could you could explain a bit more on what this issue is?
Sure, it started a few nights ago when I accepted a game invite from a friend and when the player launched and I joined the game - it was on my main account, which I wasn’t logged into at the time. This alarmed me (and my friend too to see someone show up that he didn’t know and hadn’t invited), and I found a thread here where others were having that issue and made a post there:
Hmm these are pretty strange issues. Both of these are definitely not related to Open Cloud but I would just make sure to follow up on the respective Bug Reports so that the appropriate engineers can work on fixing them as soon as possible!
Hello! I tried posting this in the Feature Requests part of the forum, but I cannot post there, so I had to redirect my feature request here.
Currently, the only way to see when a user has purchased or obtained an item is to use the Economy API, which is undocumented, unsupported, and requires the user’s cookies. Knowing when a user obtained an item could be helpful in certain cases. For instance, if you have a game pass that you sell seasonally, but you want to reward users who bought it earlier than other users. It would be nice if this data were made available in some way, even if it would require authorization from the user.
).