Public Development API

Planned

Comments

76 comments

  • Avatar
    Seth Woodworth

    I think that an API would be a powerful tool to increase usage for Beyond.  I am very interested in building tools using content purchased in Beyond, and OGL licensed content.  If my tool's users could authenticate with their Beyond account and include their OGL, purchased, and homebrew content, I think that we both could benefit.

     

    I know you have higher priorities, but I appreciate you listening to your community, and hope that an API is prioritized at some point in the future.

    19
    Comment actions Permalink
  • Avatar
    Zaphodgame

    @Simon and @Matt

    Although I wouldn't count this as an API, you can get the JSON output of your characters by going to the character view page and adding "/json" to the end of the URL.

    Example: https://www.dndbeyond.com/profile/YourName/characters/#######/json

    13
    Comment actions Permalink
  • Avatar
    Matt Dekok

    Even just being able to create an API key tied to our account and use that access the JSON data for our characters. If the account has an API key, include a way to get the data URL from the character page.

    12
    Comment actions Permalink
  • Avatar
    Simon Davy

    I would be happy to just get character data, with hp/abilities/attacks/saves/etc. Features/items/spells listed with snippet level text, and DDB links to the details. I can then make my own GM dash boards, and integrate with tools like improved-initiative

    11
    Comment actions Permalink
  • Avatar
    Tony

    I love that the first comment says "they'll never do that" and yet the feature is now on "Planned". :D

     

    11
    Comment actions Permalink
  • Avatar
    Jeffrey Head

    A public API would benefit both D&D Beyond and the player-base, as the players would still need a D&D Beyond account in order to access the appropriate data.

    10
    Comment actions Permalink
  • Avatar
    Heather Nelson

    I would appreciate this.

    9
    Comment actions Permalink
  • Avatar
    Matt Dekok

    @Zaphodgame

    I am fully aware of that having worked on D&D Beyond Importers for various virtual table tops including Roll20 and a new one currently in alpha. However, there are various reasons for using API keys for data authorization.

    The biggest reason is that an API key is a way of ensuring someone has authorization to fetch the data. For example, allowing other types of API requests for purchased content, which D&D Beyond could restrict to a certain number of requests in a period of time to ensure it's not being granted access to publicly. And then if a person was doing so, they could trace the requests to an account that is abusing the API and either ban the account or remove its API privileges.

    9
    Comment actions Permalink
  • Avatar
    Austin Humphreys

    I've been developing a Google Home integration for D&D so and have only been able to use content from the System Reference Document so this would be amazing. I could have users log in with their D&D Beyond account and therefore have access to all the content they own on Beyond.

    7
    Comment actions Permalink
  • Avatar
    jason

    Another vote for an API.


    With a community API, DDB can concentrate on what they do best, provide a great tool, at an affordable price for D&D books and player characters. Add in some campaign features for the DM and perfect all that. As they say, do one thing, and do it well.

     

    Anything past that, let the community build it. If there is an API, Roll 20 and Fantasy Grounds can just pull from DDB. If they choose not too, an new up and coming vtt will. But DDB is not a VTT company, sure they could be, but why? Let someone else do that work and DDB still gets the book sales, along with sharing subs.

    All these sites that keep getting shutdown because of copyright, along with others such as Kobold Fight Club, and DonJon can all do what they do, provide better services, and send their users to DDB to buy content. It's a win for all involved.

     

    So in my personal opinion, this should be the # 1 priority. It opens up the most potential for the community, third party sites, and DDB's bottom line.

    5
    Comment actions Permalink
  • Avatar
    Sam Henry

    Same!!!

    4
    Comment actions Permalink
  • Avatar
    Andrew Obrigewitsch

    So as was stated, because Wizards of the Coast or rather Hasbo doesn't understand technology and they are blocking an API through the use of legal contractual control. Hasbro is constantly tripping over their own feet and doing their best to slow down the expansion of the RPG industry. They are still trying to operate as if D&D just publishes books and the internet doesn't even really exist.  

    I'm working on a project to bring tech to the RPG industry. I'm a senior full stack developer working with React, TS, Node, GraphQL, Docker and AWS. I have many ideas, but unfortunately limited time. I am happy to work with and even mentor others with the same interest. My project is just getting started is gaining some traction, but the more on board the faster it can move forward. 

     

    4
    Comment actions Permalink
  • Avatar
    Permanently Deleted User

    If you request the json a lot though you will get a “Too many requests” error, so take it easy.

    3
    Comment actions Permalink
  • Avatar
    Zaphodgame

    @Matt

    I totally agree on the need for an API key. I just wanted to mention the JSON process in case people didn't know about it.

    Dave

    3
    Comment actions Permalink
  • Avatar
    Cory R Owens

    I've been begging for this from day 1. IMO, it should have been feature #1 after the MVP of rules compendium and character sheets. 

    3
    Comment actions Permalink
  • Avatar
    Shawn Tabai

    I'm no longer using it, but I created a hacky way to access my D&D Beyond content from my own tool. I made a Chrome Extension that exposes a JS interface to my web app, which essentially looks up the page I want from D&D Beyond and then examines it to find the desired data (much like what a human does when viewing a web site, it just does it for you quickly and then translates it into JSON data). So it's not a great way to provide an API, and it's not stable, and it only has the features I needed, and I wouldn't recommend using it for any public product, but it does allow your web app to do things like dndBeyond.searchMonsters('orc').then(displayTypesOfOrcs); and get structured JSON data out of it.

    If anyone is interested in playing with it, I can put it in a public GitHub repo. Note: it is NOT universal, and you would be expected to fork it and make your own. In order for your website to be able to interface with the Chrome extension, its URL needs to be specified in the extension's externally_connectable manifest. You could technically make the extension accessible to every site, but that would be a very very bad idea. It's best to make your own version for your app.

    3
    Comment actions Permalink
  • Avatar
    Matthew Strasiotto

    Dömötör Péter 

    I heartily disagree with your assertion that exposing an API would necessarily be unfeasible for DDB, though perhaps you're right that their current license does not allow them to do so without a change in its terms.

    The DDB product is not the same as the source material, which I could easily obtain for free - I've spent money on the DDB product purely for the service of automating character sheets, and I've done so to help make dnd more accessible & enjoyable for other members of my parties.

    Unfortunately, after significant investment in the product, I've also found myself disappointed with its features, and with the pace of development (No shade, sometimes I just wish for things that don't exist)

    An API doesn't equate to giving it away for free - an API might involve limited scope OAuth access, allowing an app to access whatever content a given individual has for their characters, read only access to a single campaign party, read/write access to a particular character, etc. 

    You would begin to see dndbeyond take on a different role - providing a flexible service to different client implementations. The same licensing restrictions for the service would stand - Needing to own first-party content (or be adjacent to someone that does, and is paying to share it), access rate limitations, etc, but with a more flexible UX.

    3
    Comment actions Permalink
  • Avatar
    Leighpierce90

    Just a heads up, the character JSON strings only work if you own the character, or have them in a campaign, you can't get a publicly shared JSON.


    So looking forward to seeing an integration with Arkenforge!

    2
    Comment actions Permalink
  • Avatar
    Matt Dekok

    When AL support has been added, including log sheets, it would be nice to have API access to add/edit the log sheets.

    2
    Comment actions Permalink
  • Avatar
    Shawn Tabai

    Here is a GitHub repo with what I did:

    https://github.com/shawntabai/dndbeyond-api-extension

    I've tried to make it very clear that this is a bad idea for a number of reasons, including those that jastreich said (and, in fact, his idea uses a much better paradigm than mine, though both solutions are pretty unstable).

    Janusz Kamieński I think the key point is that you don't, in fact, own the content; you've licensed it. :) The same would probably be true with buying a physical source book; making photo copies of the pages is probably prohibited, even if it's just so that you can use it for your DM screen.

    With regard to this being against the ToS, it specifically prohibits the following:

    "Use any robot, spider, site search and/or retrieval application, or other device to scrape, extract, retrieve or index any portion of the content;"

    This is one of the many reasons why I've stated that any such solutions are a bad idea, and I'm no longer even using mine. However, because there is no real API to use all of the content you paid for in your own tools, this situation is incredibly annoying. Preventing the evolution of an ecosystem is generally a hard thing to do... "life, uh, finds a way".

    2
    Comment actions Permalink
  • Avatar
    Zesquishmitten

    Honestly, it wouldn't be hard to set API access similar to how they handle content sharing for premium, etc.

    Basically just set up a sort of "premium check" at the API handshake, that confirms the DM is on a premium account.
    That is to say that if a DM has a premium (or whatever potential thing they might want to call it instead), then their campaigns, etc could be accessed via the API.
    Conversely, if they are NOT a premium account, the server just refuses to supply additional data via the API.

    Really, you'd only need to have the API connection occurring through one client -ultimately it makes the most sense for a sole client device to connect via API, and if individual players want to access that custom app experience (whatever app that might be), the DAM/master device can handle hosting duties for the rest of the group from there. This mitigates pretty much any concern over excessive bandwidth usage for DNDBeyond/Curse. Shoot, this method would actually utilize far less of their bandwidth than having a bunch of individual players refreshing pages and making changes to their characters all at once while playing -all of the write commands would be coming from one single device, and player data could be grabbed all at once but the host device at the beginning of the session.

    Hopefully they'll do something like this soon, because honestly, I'd be happy to write the API interface myself. Being able to customize my own app layout in a way that makes more sense for me as a DM would be worth all the trouble.

    1
    Comment actions Permalink
  • Avatar
    Steven Strauss

    if you know json, you may want to look at this till an api comes available.

     

    https://github.com/mivalsten/ddb-dm-screen

    1
    Comment actions Permalink
  • Avatar
    David Cooley

    Would absolutely, 100% use this. It would increase the value of the product to developers and the eagerness with which it would be likely to be consumed, would propagate a vast community-supported expansion of the dndbeyond ecosystem, that would fundamentally rely on a Wizards sanctioned product that is not free, so everyone (that doesn't just want valuable things for free) would win in this situation.

    1
    Comment actions Permalink
  • Avatar
    Matt Dekok

    James the D&D Beyond API that Avrae uses requires information (such as an API key) that are not present in the Github repository. They are stored in hidden environment variables.

    https://github.com/avrae/avrae/blob/master/utils/config.py

    1
    Comment actions Permalink
  • Avatar
    James

    I guess my question then is how did they get that information originally? I was under the impression they had kind of reverse engineered it previously.

    1
    Comment actions Permalink
  • Avatar
    Ross Kilgariff

    This would be awesome. It would add a lot of flexibility to heavily customised campaigns.

    1
    Comment actions Permalink
  • Avatar
    Richard B Way

    Listening to one of the dev talks about setting up shops got me thinking on this one again. How cool would it be to let DMs set up a couple of shops by setting some general parameters about the size/availability/age/race/attitude/etc... of the shop and shop keeper, and dynamically create an interactive experience for the players where the shop looks at their character for characteristics/equipment to create unique bartering opportunities. 

    An orc walking into an old dwarf's shop - everything costs double. 

    An elf with regal cloths and connections window shopping at a clothier? Everything is on sale, tell your friends!

    A halfling rogue in a jewelry shop? The security guard follows you around. 

    A talkative human with high charisma engaging a street merchant? Excellent haggling commences! 

    I could whip up an MVP over the weekend if I could access the player, campaign, and equipment details from DNDBeyond through an API! 

    1
    Comment actions Permalink
  • Avatar
    James

    So in theory Avrae has full access to everything you have access to and you can set up your own Avrae server.
    So if you can set up your own Avrae server and you can set up something like that with full access then it has access to all of it just because there’s an interface that uses a bot for discord doesn’t mean that you can’t access that data in other ways from that server. There may be limitations but anything that Avrae can display the server should have access to and be able to display and then on top of that discord itself has a whole set of APIs for adding things into it such as buttons and special uses and things like that so either of those are a pretty direct way to access the DNDBeyond content without a public API. This of course is all Theory without really looking into the model of either Avrae or Discord I’m not sure what artificial limits have been put in place.

    1
    Comment actions Permalink
  • Avatar
    jastreich

    I also tried what Shawn Tabai did, but took it a step beyond by making the same requests that DNDBeyond's ajax scripts call from the chrome extension.  I didn't continue down the path because it technically violates the TOS and the files they make calls to could change because it requires the extension and not being a public API could change at any moment without warn

    The thing I want to write, or DNDBeyond to add is content management. A way to store the contients, the nations on the continents, the towns in those nations, the shops and people and other places in those towns, and then the offerings of the various shops.  I currently have a very long DM Notes (private) in my campaign.

    While I COULD just write those notes in Google Docs or the like (and did previously), the problem because not having the nice hover previews, and having to jump back and forth between tabs and such. Having it open during the game means I can add new people/places during the game -- but even there DNDBeyond's campaign notes falls apart because the [magicItem] and [spell] aren't active while editing, and switching to/from editing scrolls to the top because it is just a normal link and normal form element.

    So, I'm very tempted to make a local app in nodejs and compile with electron to get around CORS, or to just to make a web app that requires a chrome extension.  The things stoping me are the TOS and possibility of constant breaking change from DNDBeyond.  (And the other projects I'm working on, that if I weren't I might not let the other two bother me).

    Sorry rant over.

    1
    Comment actions Permalink
  • Avatar
    Shawn Tabai

    Dömötör Péter There is a lot to be said for the business strategy of a platform/ecosystem vs a standalone product. WotC seems to see it the way you do, but providing integrations into other tools comes with a lot of opportunities to capitalize (e.g. charging for API quota, advertising tools in their ecosystem, taking a cut of all purchases). The risk of allowing data services is minimal; it's trivial to already do this with web scraping (as my code shows), and any real business would be incredibly foolish to risk their livelihood by violating the API's terms. I believe they're hurting their platform by force-feeding their product, and it really is a shame.

    1
    Comment actions Permalink

Please sign in to leave a comment.