Can I use the API if I'm subscribed and the DM doesn't have it? And if not so .. why?

1518448069
Hi there I wanted to know if it was possible to use the API character sheets as a player in a game. When the DM doesn't have a subscription. Or even if it's possible for me to enable the API by being in the game. It just seems silly to me that the one with the subscription HAS to be the DM or we can't use the fancy macro sheets. I know this is probably to push subscriptions onto DM's but it makes it harder for those who can't afford subscriptions to set up games. Thanks in advance. 
1518448330
Scott C.
Pro
Sheet Author
API Scripter
Counterpoint: the API also has the potential to enable cheating and literally destroy a game. Would you want someone to join your game and enable a feature that you may not fully understand that could do all that? I realize that you're not asking to be able to load the scripts yourself, but the potential still exists for some serious problems. Also, yes, I'm sure it's part of the business model.
1518449373

Edited 1518449515
Well I'd say the issue of cheating comes down to who to play with. It's pretty obvious when someone is doing it and they eventually get caught and kicked. Usually I'd then offer their character up to a new player. I think that if someone wants to cheat. They're either going to get caught or they're going to do it anyway. It's not as if most DM's check the sheets with a fine tooth comb.  P.S Thank's Pantoufle that was just what I needed to know! 
1518458527
Ramez H. said: subscription HAS to be the DM or we can't use the fancy macro sheets This is not necessary. Your DM can utilize your subscription if you are the one who creates the game and then give GM access to the desired person. Games use the subscription of the creator, not the GM, but this is usually the same person as you have noticed.
1518459054
keithcurtis
Roll20 Mod Team
You would also run into problems if you had conflicting versions of API scripts installed between Player & GM. Even if an API script is designed as a companion to a sheet, it acts at the campaign level.
1518644620
keithcurtis
Roll20 Mod Team
I think the reason is far more related to the ones already mentioned: security, utility and compatibility, than profitability expressed within a business model. Otherwise, why would Roll20 care if a player used the API in an non-Pro GM's campaign? If it were profitability, they would tend to side on allowing such an arrangement, simply because it would encourage more people to subscribe. It simply makes no sense from a programming standpoint to allow two sources to control the API of a single instance.
Yep, I think Keithcurtis has a valid point here. If two instances of the API could be controlled by to separate GMs and maybe even run in parallel mayhem would occur. It would be hard enough to prevent race conditions, infinite loops and similar programming errors with pregenerated (or curated API scripts) if they're run side by side. But as User generated scripts are a thing those scripts would most likely cause complete chaos. Global variables, the State of the Script could and would get possibly overwritten by the second instance of the script. There's surely also reasoning from a business perspective that will go along the lines of "If we could run several API instances side by side for a game, we would have more cases where characters got messed up (The Devs said so). As we know users are really bad at heeding warning messages we will have more support cases with users having f'ed up a character or a game with the API and we cannot afford to hire that much support people". And one last point, JavaScript as the language driving the API scripts is a) easy to f' up, b) not that easy if you want to get it right. If you take a look at the API forums you relatively often see questions being asked by people who have a domain specific problem they want to solve (something about the VTT) but no prior experience in programming. Hell, a webdeveloper doing a little bit JavaScript here and there would have no idea on all the topics you have to understand to run JavaScript in the backend safely. Yes, I firmly believe this also has business reasons as I pointed out, but that is not the primary reason. The primary reason is that everything else would cause problems all over the place with no easy fix.
1518813419
Thorsten B.
KS Backer
@Kyle G has it right: Create a campaign on your account, invite people, make one of these people the GM. They now have full access to the API, as do you as the campaign creator. Obviously you'd want to work together on which APIs to enable for the campaign. We do this. We have a group that rotates GM duties, so we have three campaigns created, with three different people as GM for "their" campaign, and one subscription being maintained for the entire group. The reality is that if we required each GM to maintain their own subscriptions, we'd only have one campaign with API and two without.