ROBLOX API: How can I get access to my products?

Basically, I am trying to edit a DevProduct with the ROBLOX API.
I tried on my webserver, and it says “Error: Unauthorized.”

To everyone that says that its a bad idea: Yes, I kinda agree, it is. Well, it’s for a friend, told him it’s a bad idea, he told me “just do it” so I said ok. I sent this post to my friend so he can look at all your replies warning him to not do that. Thanks to everyone for warning me, I’ve found a way to make a better system without having to use API, if he chooses that system, I’ll and he’ll be safe.

How can I fix that?
Thanks in advance.

You need to be logged in via the login API, and have permissions to edit the product.

I feel like this is an XY Problem though- why do you need to automatically edit the product?

Here. How to use the the login API, tried it, didn’t understand it.
How to use the captcha fields?

Terrible idea,

You are changing the devproduct for not 1 user, but for everyone. I am sure this game has a different way of doing it, besides, why would you want to do this?

Dynamic product prices for a given transaction.

The idea is to automatically change the price of a developer product right before asking a player to buy it. One use case is allowing a player to donate an exact amount of Robux of their choice.

I’m sure a large pool of developer products can be managed so that no player gets asked to pay an amount someone else requested.

What he’s saying is its a terrible idea to even try to do this. Since you’d be changing the price of a DevProduct for EVERYONE when someone inputs the amount they want. What happens when multiple people try to donate at the same time? Unless you have access to create new DevProducts (not really a scalable idea anyways), I wouldn’t recommend doing this

4 Likes

You need to pass a ROBLOSECURITY cookie along with your web request to the Roblox website, otherwise it will deny your request to change dev product prices.

I don’t recommend using a cookie from your main account, however.


Sure, it’s not the most scalable of ideas, but if you keep a database of ongoing transactions and in-use developer products, you can prevent collisions by never using developer products for multiple transactions at the same time.

Thanks. Will try this as soon as possible.

Since I was told that several times, look at the post in itself, edited it to answer to your concern.

Thanks for trying to warn me. Since I was told that several times, look at the post in itself, edited it to answer to your concern.

I apologise I’m advance but my response is more about advising against this.

I don’t advise directly modifying products to create custom donation products, especially if multiple people are buying, because such a task can quickly get muddled especially if products are modified mid-purchase. Users can quickly lose money or end up paying a different amount than what they expected and this will result in more than just unhappy users. You can return NotProcessedYet for unexpected amounts or prompts not made by the server, but there is still an inherent risk in doing this.

You need to tread carefully when making systems involving Robux that are not natively supported. Any mishap, unexpected processing of a purchase or otherwise a situation where a user pays a different amount than what they expected can result in serious action, including the loss of your account. It’s not a risk worth taking.

You are more advised to make incremental products (e.g. 1, 5, 10, etc), break down the requested donation amount and prompt purchases of the products until the user meets the total amount or cancels the purchase. A donation center using such a strategy released their source code for doing this.

Hm, thats a good idea. Will consider it.

I do agree with you that it’s a bad system, and I would like to thank you for telling me. As I was getting this told to me alot of times, I edited my post to answer in advance to everyone not recommending this.

Your friend doesn’t understand the risks nor the consequences of this then and they need to be enlightened about them. I don’t take “my friend told me to just do it” as an appropriate response to an advisory against doing this which involves very serious repercussions for failure. Not only for the person intending to use this, but for everyone else who attempts to do this.

Arbitrary modification of developer products from an external service is an inherent risk. We haven’t even yet asked the question if this is allowed and I strongly doubt it is.

Yes, all the answers were sent to my friends. Found an alternative way to do it (user would enter an amount, then It would list all the products he has to buy to complete that amount)

So… basically the post I linked earlier. Glad you’ve adopted that system instead of arbitrarily changing your developer products.

Please be sure to mark your post as the solution.

TL;DR: Using API to do this is really dangerous, consider other methods.

“Endgame” Post

I would like to thank everyone that warned me about the risks of this. I will be straightforward: do not use API to make dynamic developer products. There are a lot of ways to do that, but please do not take the API one, we do not know if it’s allowed and it’s really risky.

Solution 1: DevProduct Wall
You would have a list of DevProducts

Solution 2: The Counter
Basically, you input a number, (31 for instance), then a script will show a list of DevProducts to buy to reach the said amount (31).

I will NOT go into details in this post, but I will link all posts that told me to NOT do that.

1 Like

I understand why lot’s of people call this a bad idea - but if done right it’s actually really cool and powerful.

I’m not sure what you want to code this in - I’m going to assume it’s Node.js.

Editing existing developer products is a very bad idea (for reasons already mentioned). However, creating a new product isn’t so bad. With the right checks, both off-game and in-game, you shouldn’t run into issues where someone is paying what they shouldn’t.


First off, you should have a private API key that no one knows, aside from you and the game owner. You should then use one of my modules, RoCheck, to make sure the request is really from your game.

When your Roblox client joins a game, it asks the Roblox API for the IP address and port to send packets to. RoCheck basically does the same thing - it asks the Roblox API for the IP of a server. Using this information, we can compare it to the requesters IP address and we will know for sure that the request is from a Roblox game.

And once you know it’s from a real Roblox game, just do a simple if statement to check if the roblox-id header is your game.


As for actually handling the developer products, you should set up an API which just takes in the developer product cost. Your server should have a database of already created developer products. When it receives the request it should query the database for a document with that developer product price. If it exists you return the developer product ID to the game.

If it doesn’t already exist, use the Roblox API to create a new developer product with the desired price. Then add that to the database and return it to the game.


When the game receives the developer product ID, it should use MarketplaceService to do a double-check that the developer product exists and that it’s the correct price. If it is then prompt the purchase!


I hope I could have been some help to you. When creating something risky like this, you should always do your research into all the different methods and ways of securing it. Please ask if you have any questions!

Creating throwaway assets for one-time use cases is just as bad but in a different mannerism. You’re inflating the asset database by creating one-time assets that aren’t used ever again. Also, whether this is allowed or not hasn’t been addressed.

1 Like

You’re not creating one-time assets. I don’t know the exact use-case so I can’t tell how much variation there’s gonna be in dev product prices. The whole point of the database is so you can use existing developer products. E.g:

Person A buys something for 100 Robux (New product created)
Person B buys something for 200 robux (New product created)
Person C buys something for 100 robux (Existing product used)

I imagine that using the API is allowed (if it wasn’t, why is it publicly documented?). The bit that isn’t allowed is charging your users the incorrect price - which my method would prevent, especially if you do a final MarketplaceService check before purchase.