Good news! A public development API is on the road map. Additionally, the character sheet is currently in development to be added to the app beta. Road map.
D&D Beyond does not put out dates for the release of future features. You can watch the feedback Trello that I linked above as well as the weekly Dev Updates on Twitch to keep up to date with development progress. It should be noted that the Public Development API is on the list of longer term planned features.
The API disappeared from the road map a while ago. So did the content thing, and user defined shops/shop builder. It seems like things were moving along with the roll out of Dice, Encounter Builder and the new version of the character sheets. I don't know if it is COVID-19, all the work on different dice sets, or the changes for the two new books, but the road map got pruned at some point to just the more immediate list. Unless there is a long term list I'm missing in Trello?
The API disappeared from the road map a while ago. So did the content thing, and user defined shops/shop builder. It seems like things were moving along with the roll out of Dice, Encounter Builder and the new version of the character sheets. I don't know if it is COVID-19, all the work on different dice sets, or the changes for the two new books, but the road map got pruned at some point to just the more immediate list. Unless there is a long term list I'm missing in Trello?
The roadmap was reorganized recently and now only shows immediate and next quarter plans/goals. Items on the longer term roadmap are no longer on the public board. I’m confident those things are still on the list, just out there further.
Wonder if the public API is still a possibility after all the recent changes in the company?
I don’t see why the recent changes would affect plans for a public API. Note,however, that a public API is way down the roadmap, in part because they have a lot of code/database restructuring to do yet. Makes no sense to release a public API when changes they need to make will break it repeatedly, requiring them to spend developer time to fix it and annoying the folks who are using it every time it breaks.
Makes no sense to release a public API when changes they need to make will break it repeatedly,
That's not right. A public API would be a product. Like any of their other products, it would need tests in order to ensure it stays working.
You might be assuming their front-end would depend on this same public API. In that case you'd have a point. They need the ability to move fast, and that means they wouldn't want to be tied to a stable API. But of course the front-end could continue using its private API, even while they publish a stable public API.
Makes no sense to release a public API when changes they need to make will break it repeatedly,
That's not right. A public API would be a product. Like any of their other products, it would need tests in order to ensure it stays working.
You might be assuming their front-end would depend on this same public API. In that case you'd have a point. They need the ability to move fast, and that means they wouldn't want to be tied to a stable API. But of course the front-end could continue using its private API, even while they publish a stable public API.
I'm telling you what the developers and other staff have said when asked about a public API: they won't do an API anytime soon because they don't want to have to keep updating/changing it, and they think constant changes would be a bad user experience. Furthermore, as you point out, creating a public API also means dedicating resources to maintaining it. There are a TON of projects they want to do and/or that the user base wants them to do. They don't have the resources to do everything at once--not even close. They have to prioritize. And a public API is below a lot of other things on the priority list. Plus, that list keeps changing, both because WOTC keeps dropping new mechanics and new books, and because they come across systems that have to be re-written to accommodate either that new content or new features they want to add. Case in point: they (and many users) want to add pc statistics like HP and the like to the combat tracker. They designed, and maybe even developed code to do that, only to discover in testing that it would take so many data calls on the database that it would crash the database. So now they are developing a "Simplified character data" system the combat tracker can use without crashing everything. That pushes back other parts of the combat tracker development, along with whatever other projects the team currently working on the combat tracker has on their list.
Of course if they'd coded with a proper API from the start, which could have been publicized, that HP call / database crash problem likely wouldn't have become a problem when it did.
Honestly, this fixation on THE api as an all-or-nothing is pretty ridiculous. Just like they roll out individual features for their interface tools, they can roll out features for the API.
For a tool I have in mind, I only need a few things.
the ability to link to a user's account using Oauth or some other authentication method
an API Key unique to my app for any rate limiting / revocation of access purposes
the ability to query which content the user has access to, and the link to the relevant page / excerpt on dndbeyond.
Using this incredibly simplified API, I could allow users to use content they "purchased" through dndbeyond without actually housing, or copying it. This would be an incredibly simplified api MVP, and it should be a much easier sale to WOTC as it doesn't actually allow the embedding or copying of any content, just linking to it.
Honestly, this fixation on THE api as an all-or-nothing is pretty ridiculous. Just like they roll out individual features for their interface tools, they can roll out features for the API.
For a tool I have in mind, I only need a few things.
the ability to link to a user's account using Oauth or some other authentication method
an API Key unique to my app for any rate limiting / revocation of access purposes
the ability to query which content the user has access to, and the link to the relevant page / excerpt on dndbeyond.
Using this incredibly simplified API, I could allow users to use content they "purchased" through dndbeyond without actually housing, or copying it. This would be an incredibly simplified api MVP, and it should be a much easier sale to WOTC as it doesn't actually allow the embedding or copying of any content, just linking to it.
You, I like you. You seem to both understand Agile and iterative development.
https://character-service.dndbeyond.com/character/v5/character/(character ID) seems to pull most things you would want, and is visible without being logged in. Obviously this has no guarantees about performance, or data shape, but the character sheet itself already seems to be a REST api. The real reason it seems like they haven't put out an "Official" API is because they don't want to have to provide guarantees about backwards compatibility or performance, which, yeah, these are expensive guarantees to have hovering over a small team.
Wasn't the Avrae bot developed outside of DDB and then brought onboard officially? However Avrae is accessing the data, checking authorization for content, and the like, is all that I'm really looking for when hacking some kinda project together.
Wasn't the Avrae bot developed outside of DDB and then brought onboard officially? However Avrae is accessing the data, checking authorization for content, and the like, is all that I'm really looking for when hacking some kinda project together.
All that has already been done by people, [REDACTED]
Notes: Please keep posts respectful and constructive.
I understand that this has probably been either cancelled or indefinitely backlogged but it would be pants-poopingly awesome to be able to tap into the insane wealth of knowledge on dndbeyond (both OGL and licensed).
If Wizards is worried about people using licensed content without having paid for it, the logical outcome to an API would be to have anyone using the API to authenticate against dndbeyond. This would be via some dndbeyond auth portal or mechanism. It would even be easy enough once set up to limit API availability to source books/etc; really however they wanted to do it. They could even make the OGL content public, with licensed content behind auth.
It would take some work, and it would all need to be maintained, but it would be a favourable resolution to the issue of "how can we keep our IP from being used by normies" that Wizards focuses on (rightly so; although I understand that is a contentious topic...) and the lawyers would (should) be okay with this.
Anyhow, if you're looking to architect an API and hire developers, please DM me. Having a centralized library of content would be a huge step forward for the community. Thanks for coming to my TED Talk.
Makes no sense to release a public API when changes they need to make will break it repeatedly,
That's not right. A public API would be a product. Like any of their other products, it would need tests in order to ensure it stays working.
You might be assuming their front-end would depend on this same public API. In that case you'd have a point. They need the ability to move fast, and that means they wouldn't want to be tied to a stable API. But of course the front-end could continue using its private API, even while they publish a stable public API.
Yeah I think some folks on this board don't know the reality of what "bad technical debt that requires open heart software surgery" entails. From my understanding D&D Beyond has (or maybe had if they've gotten through it) a bit of technical debt. Technical debt can be very very costly. This kind of technical debt can also require a significant restructuring of the processes that define the different layers of the system's logic: business, domain, database even... the works. I know how that can happen. A company starts off small, get stuff done ASAP while simple hack jobs, bandaid solutions and the "fastest path to working" takes precedence. As time goes on it gets more complicated and a massive mess is inevitably created. You'd be surprised how many companies have done that where on the surface everything looks honky dory but when you get a good look underneath the hood you realize it's a fricken nightmare to maintain because there's no separation of concern, there's squirrelly business logic everywhere that forces you to step through everything to find out what does what, looks like it was hack jobbed together from interns with no software architecture concerns, views are tangled in with models... a total mess.
I'm not sure where D&D Beyond is, but it's possible they got a good wiff of that and if so, then yeah, everything gets put on hold as it's crucial to build the right foundation of processes to build more complicated and service oriented architecture on top of it, like an API. To think of an API as a modular component of their entire system, you have to ASSUME they've built their system to be modular like that, and that's a really big assumption to make. To plan out an API like that, you have to write the architectural principles in place and build it right from the onset so that it's not brittle, is able to change and maintain as well as modular to add on new kinds of features and components.
@PaulTheBroDude: I believe you have hit the nail on the head. I’m not a developer, but I’ve watched the developer updates from the beginning and I have some small experience building (local) relational databases from the ground up using apps like DoubleHelix and OpenOffice’s Base. The devs here acknowledge quite openly that there’s a lot of tech debt. They have even started talking recently about “rules debt,” i.e. rules their system can’t support yet. And yes, based on what I’ve heard developers say on the update over the years, their initial system was monolithic, brittle, and built quickly to prove they could. It didn’t (and in many ways still does not) have the flexibility to adapt to all the new mechanics and variations Wizards of the Coast keeps putting out. Moreover, it was built on a system they knew was long in the teeth/obsolete, but it was what they had to work with. And, DDB grew exponentially faster than they expected, forcing them to address scaling issues far sooner than they thought. For the last two or three (or more?) years, they have been slowly—oh so slowly—disentangling the monolith and building out more modular systems. Mostly that’s been with newer pieces, like the Encounters tools, although doing that has required extricating other older elements from the monolith. (For encounters, they started with the monsters data). The need to (begin to?) extricate the character sheet from the monolith is part of why it took so long for HP, AC and other character info to show up in the Encounters tool.
My apologies if you know all those details already; I thought if you didn’t you might find it interesting verification of your guesses, and that others who read a through the thread might appreciate a little more in the way of specifics.
In terms of the API issue (not for you, but for other readers), this is precisely why some of the initial 3rd party tools that were using jsons and the like to pull data broke a couple of years ago or more. As I understand it, as part of beginning to extricate the character sheet from the monolith, things had to change. DDB announced those changes, and that this would break some 3rd party services ahead of the changes, and some people still went ballistic. That incident proved to me that I was right in my assessment that releasing an API while they are restructuring things (which will take a long time) makes no sense.
Yeah I think some folks on this board don't know the reality of what "bad technical debt that requires open heart software surgery" entails.
As a full-stack polyglot developer who has worked on many web apps of varying degrees of disarray, this hits home SO hard. Technical Debt is a real thing, and often misunderstood even by the stakeholders within the business itself as not a "real" issue, often deprioritized in favor of pumping out new features. They don't understand how much it slows down progress over time, like the brakes on a train -- each break only applies a little bit of pressure to each wheel, but the compound effect is enough to slow and eventually stop a speeding train quite effectively. Left unaddressed, you'll wake up one day wondering why your development team can't get anything done. Code rots over time.
Decoupling a tightly bound and quickly put-together codebase takes time, and that time means you're not allocating it to releasing new features. Designing and writing quality code that is easier to maintain across a team of developers with varying experience and talent is a ART form and a balancing act, often negotiating quality standards with the business folks and making a case for sustained engineering.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Is there an API D&D Beyond? Or is there any way to integrate it to an app?
Good news! A public development API is on the road map. Additionally, the character sheet is currently in development to be added to the app beta. Road map.
When it will be available ?
D&D Beyond does not put out dates for the release of future features. You can watch the feedback Trello that I linked above as well as the weekly Dev Updates on Twitch to keep up to date with development progress. It should be noted that the Public Development API is on the list of longer term planned features.
The API disappeared from the road map a while ago. So did the content thing, and user defined shops/shop builder. It seems like things were moving along with the roll out of Dice, Encounter Builder and the new version of the character sheets. I don't know if it is COVID-19, all the work on different dice sets, or the changes for the two new books, but the road map got pruned at some point to just the more immediate list. Unless there is a long term list I'm missing in Trello?
I'd forgotten about Zenddesk: https://dndbeyond.zendesk.com/hc/en-us/community/posts/115007431827-Public-Development-API
The roadmap was reorganized recently and now only shows immediate and next quarter plans/goals. Items on the longer term roadmap are no longer on the public board. I’m confident those things are still on the list, just out there further.
Trying to Decide if DDB is for you? A few helpful threads: A Buyer's Guide to DDB; What I/We Bought and Why; How some DMs use DDB; A Newer Thread on Using DDB to Play
Helpful threads on other topics: Homebrew FAQ by IamSposta; Accessing Content by ConalTheGreat;
Check your entitlements here. | Support Ticket LInk
Wonder if the public API is still a possibility after all the recent changes in the company?
I don’t see why the recent changes would affect plans for a public API. Note,however, that a public API is way down the roadmap, in part because they have a lot of code/database restructuring to do yet. Makes no sense to release a public API when changes they need to make will break it repeatedly, requiring them to spend developer time to fix it and annoying the folks who are using it every time it breaks.
Trying to Decide if DDB is for you? A few helpful threads: A Buyer's Guide to DDB; What I/We Bought and Why; How some DMs use DDB; A Newer Thread on Using DDB to Play
Helpful threads on other topics: Homebrew FAQ by IamSposta; Accessing Content by ConalTheGreat;
Check your entitlements here. | Support Ticket LInk
I'm telling you what the developers and other staff have said when asked about a public API: they won't do an API anytime soon because they don't want to have to keep updating/changing it, and they think constant changes would be a bad user experience. Furthermore, as you point out, creating a public API also means dedicating resources to maintaining it. There are a TON of projects they want to do and/or that the user base wants them to do. They don't have the resources to do everything at once--not even close. They have to prioritize. And a public API is below a lot of other things on the priority list. Plus, that list keeps changing, both because WOTC keeps dropping new mechanics and new books, and because they come across systems that have to be re-written to accommodate either that new content or new features they want to add. Case in point: they (and many users) want to add pc statistics like HP and the like to the combat tracker. They designed, and maybe even developed code to do that, only to discover in testing that it would take so many data calls on the database that it would crash the database. So now they are developing a "Simplified character data" system the combat tracker can use without crashing everything. That pushes back other parts of the combat tracker development, along with whatever other projects the team currently working on the combat tracker has on their list.
Trying to Decide if DDB is for you? A few helpful threads: A Buyer's Guide to DDB; What I/We Bought and Why; How some DMs use DDB; A Newer Thread on Using DDB to Play
Helpful threads on other topics: Homebrew FAQ by IamSposta; Accessing Content by ConalTheGreat;
Check your entitlements here. | Support Ticket LInk
Of course if they'd coded with a proper API from the start, which could have been publicized, that HP call / database crash problem likely wouldn't have become a problem when it did.
Honestly, this fixation on THE api as an all-or-nothing is pretty ridiculous. Just like they roll out individual features for their interface tools, they can roll out features for the API.
For a tool I have in mind, I only need a few things.
Using this incredibly simplified API, I could allow users to use content they "purchased" through dndbeyond without actually housing, or copying it. This would be an incredibly simplified api MVP, and it should be a much easier sale to WOTC as it doesn't actually allow the embedding or copying of any content, just linking to it.
You, I like you. You seem to both understand Agile and iterative development.
https://character-service.dndbeyond.com/character/v5/character/(character ID) seems to pull most things you would want, and is visible without being logged in. Obviously this has no guarantees about performance, or data shape, but the character sheet itself already seems to be a REST api. The real reason it seems like they haven't put out an "Official" API is because they don't want to have to provide guarantees about backwards compatibility or performance, which, yeah, these are expensive guarantees to have hovering over a small team.
Wasn't the Avrae bot developed outside of DDB and then brought onboard officially? However Avrae is accessing the data, checking authorization for content, and the like, is all that I'm really looking for when hacking some kinda project together.
All that has already been done by people, [REDACTED]
I understand that this has probably been either cancelled or indefinitely backlogged but it would be pants-poopingly awesome to be able to tap into the insane wealth of knowledge on dndbeyond (both OGL and licensed).
If Wizards is worried about people using licensed content without having paid for it, the logical outcome to an API would be to have anyone using the API to authenticate against dndbeyond. This would be via some dndbeyond auth portal or mechanism. It would even be easy enough once set up to limit API availability to source books/etc; really however they wanted to do it. They could even make the OGL content public, with licensed content behind auth.
It would take some work, and it would all need to be maintained, but it would be a favourable resolution to the issue of "how can we keep our IP from being used by normies" that Wizards focuses on (rightly so; although I understand that is a contentious topic...) and the lawyers would (should) be okay with this.
Anyhow, if you're looking to architect an API and hire developers, please DM me. Having a centralized library of content would be a huge step forward for the community. Thanks for coming to my TED Talk.
Yeah I think some folks on this board don't know the reality of what "bad technical debt that requires open heart software surgery" entails. From my understanding D&D Beyond has (or maybe had if they've gotten through it) a bit of technical debt. Technical debt can be very very costly. This kind of technical debt can also require a significant restructuring of the processes that define the different layers of the system's logic: business, domain, database even... the works. I know how that can happen. A company starts off small, get stuff done ASAP while simple hack jobs, bandaid solutions and the "fastest path to working" takes precedence. As time goes on it gets more complicated and a massive mess is inevitably created. You'd be surprised how many companies have done that where on the surface everything looks honky dory but when you get a good look underneath the hood you realize it's a fricken nightmare to maintain because there's no separation of concern, there's squirrelly business logic everywhere that forces you to step through everything to find out what does what, looks like it was hack jobbed together from interns with no software architecture concerns, views are tangled in with models... a total mess.
I'm not sure where D&D Beyond is, but it's possible they got a good wiff of that and if so, then yeah, everything gets put on hold as it's crucial to build the right foundation of processes to build more complicated and service oriented architecture on top of it, like an API. To think of an API as a modular component of their entire system, you have to ASSUME they've built their system to be modular like that, and that's a really big assumption to make. To plan out an API like that, you have to write the architectural principles in place and build it right from the onset so that it's not brittle, is able to change and maintain as well as modular to add on new kinds of features and components.
@PaulTheBroDude: I believe you have hit the nail on the head. I’m not a developer, but I’ve watched the developer updates from the beginning and I have some small experience building (local) relational databases from the ground up using apps like DoubleHelix and OpenOffice’s Base. The devs here acknowledge quite openly that there’s a lot of tech debt. They have even started talking recently about “rules debt,” i.e. rules their system can’t support yet. And yes, based on what I’ve heard developers say on the update over the years, their initial system was monolithic, brittle, and built quickly to prove they could. It didn’t (and in many ways still does not) have the flexibility to adapt to all the new mechanics and variations Wizards of the Coast keeps putting out. Moreover, it was built on a system they knew was long in the teeth/obsolete, but it was what they had to work with. And, DDB grew exponentially faster than they expected, forcing them to address scaling issues far sooner than they thought. For the last two or three (or more?) years, they have been slowly—oh so slowly—disentangling the monolith and building out more modular systems. Mostly that’s been with newer pieces, like the Encounters tools, although doing that has required extricating other older elements from the monolith. (For encounters, they started with the monsters data). The need to (begin to?) extricate the character sheet from the monolith is part of why it took so long for HP, AC and other character info to show up in the Encounters tool.
My apologies if you know all those details already; I thought if you didn’t you might find it interesting verification of your guesses, and that others who read a through the thread might appreciate a little more in the way of specifics.
In terms of the API issue (not for you, but for other readers), this is precisely why some of the initial 3rd party tools that were using jsons and the like to pull data broke a couple of years ago or more. As I understand it, as part of beginning to extricate the character sheet from the monolith, things had to change. DDB announced those changes, and that this would break some 3rd party services ahead of the changes, and some people still went ballistic. That incident proved to me that I was right in my assessment that releasing an API while they are restructuring things (which will take a long time) makes no sense.
Trying to Decide if DDB is for you? A few helpful threads: A Buyer's Guide to DDB; What I/We Bought and Why; How some DMs use DDB; A Newer Thread on Using DDB to Play
Helpful threads on other topics: Homebrew FAQ by IamSposta; Accessing Content by ConalTheGreat;
Check your entitlements here. | Support Ticket LInk
As a full-stack polyglot developer who has worked on many web apps of varying degrees of disarray, this hits home SO hard. Technical Debt is a real thing, and often misunderstood even by the stakeholders within the business itself as not a "real" issue, often deprioritized in favor of pumping out new features. They don't understand how much it slows down progress over time, like the brakes on a train -- each break only applies a little bit of pressure to each wheel, but the compound effect is enough to slow and eventually stop a speeding train quite effectively. Left unaddressed, you'll wake up one day wondering why your development team can't get anything done. Code rots over time.
Decoupling a tightly bound and quickly put-together codebase takes time, and that time means you're not allocating it to releasing new features. Designing and writing quality code that is easier to maintain across a team of developers with varying experience and talent is a ART form and a balancing act, often negotiating quality standards with the business folks and making a case for sustained engineering.