Just to clarify, user permissions are still intact - for example it is only possible for a python/js script to access your character data if you are the one that is running it, whilst successfully authenticated on the site.
It's not possible for people to access the data of other people's characters, unless they have been granted permission (ie. the DM in a campaign) or have elevated permissions (moderators, admin & developers)
Sorry, my bad on trying not to ramble it wound up being too easy to misinterpret. :) I apologize for implying that people's characters are accessible by others through the JSON. I was mainly trying to respond to the thought that Curse could just throw an API out there quick and easy and we'd have great 3rd party tools.
What I meant was that if someone wanted to write, say, a character importer for Roll20 or FG or whatever - they could have done so months ago. I already toyed with something along those lines soon after launch to try and make a "dashboard" of the PCs in my campaign. (Reverse engineering and/or completely rewrite the Armor Class calculations is what finally tipped the scales to "not worth it" for me.) The main point is that there are no significant technical limitations right now. If someone wanted to take the time to build one, they could have already. All character data (again, for characters you have access to) is already viewable in a standardized, structured format. The only limitations are A) taking the time to understand that format, and B) taking on the risk of it changing without notice because it's an undocumented & unsupported "feature."
For a personal project, I have no problem with "B" but don't have the time to devote to "A." For a potential 3rd party business project, "A" might be worth it, but not "B," and I imagine that's probably true for a lot of professional programmers and businesses since we haven't seen anyone do it yet. There's no technical limitation stopping them from doing it already, just business ones of risk and effort.
Sorry, my bad on trying not to ramble it wound up being too easy to misinterpret. :) I apologize for implying that people's characters are accessible by others through the JSON. I was mainly trying to respond to the thought that Curse could just throw an API out there quick and easy and we'd have great 3rd party tools.
What I meant was that if someone wanted to write, say, a character importer for Roll20 or FG or whatever - they could have done so months ago. I already toyed with something along those lines soon after launch to try and make a "dashboard" of the PCs in my campaign. (Reverse engineering and/or completely rewrite the Armor Class calculations is what finally tipped the scales to "not worth it" for me.) The main point is that there are no significant technical limitations right now. If someone wanted to take the time to build one, they could have already. All character data (again, for characters you have access to) is already viewable in a standardized, structured format. The only limitations are A) taking the time to understand that format, and B) taking on the risk of it changing without notice because it's an undocumented & unsupported "feature."
For a personal project, I have no problem with "B" but don't have the time to devote to "A." For a potential 3rd party business project, "A" might be worth it, but not "B," and I imagine that's probably true for a lot of professional programmers and businesses since we haven't seen anyone do it yet. There's no technical limitation stopping them from doing it already, just business ones of risk and effort.
Problem is that that API (the internal one) can, and likely will, change w/o notice, responding to the necessities of development of the site. Were they to document it, it would either slow down development, or the documentation would fall behind, and third-party apps would break, all of which would reflect negatively (unfairly) on DDB. And, since the site is under active development, and more than simply bug fixes, this is something that can be expected to happen frequently. Having the API undocumented and not officially available allows them to be more agile in their development, since they don't have to consider whether API changes break other apps. :)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
D&D Beyond FoundersJust to clarify, user permissions are still intact - for example it is only possible for a python/js script to access your character data if you are the one that is running it, whilst successfully authenticated on the site.
It's not possible for people to access the data of other people's characters, unless they have been granted permission (ie. the DM in a campaign) or have elevated permissions (moderators, admin & developers)
Pun-loving nerd | Faith Elisabeth Lilley | She/Her/Hers | Profile art by Becca Golins
If you need help with homebrew, please post on the homebrew forums, where multiple staff and moderators can read your post and help you!
"We got this, no problem! I'll take the twenty on the left - you guys handle the one on the right!"🔊
Sorry, my bad on trying not to ramble it wound up being too easy to misinterpret. :) I apologize for implying that people's characters are accessible by others through the JSON. I was mainly trying to respond to the thought that Curse could just throw an API out there quick and easy and we'd have great 3rd party tools.
What I meant was that if someone wanted to write, say, a character importer for Roll20 or FG or whatever - they could have done so months ago. I already toyed with something along those lines soon after launch to try and make a "dashboard" of the PCs in my campaign. (Reverse engineering and/or completely rewrite the Armor Class calculations is what finally tipped the scales to "not worth it" for me.) The main point is that there are no significant technical limitations right now. If someone wanted to take the time to build one, they could have already. All character data (again, for characters you have access to) is already viewable in a standardized, structured format. The only limitations are A) taking the time to understand that format, and B) taking on the risk of it changing without notice because it's an undocumented & unsupported "feature."
For a personal project, I have no problem with "B" but don't have the time to devote to "A." For a potential 3rd party business project, "A" might be worth it, but not "B," and I imagine that's probably true for a lot of professional programmers and businesses since we haven't seen anyone do it yet. There's no technical limitation stopping them from doing it already, just business ones of risk and effort.