Public Development API

Planned

Comments

81 comments

  • Avatar
    Daniel Thorp

    @Andargor I think that's because they don't actually plan on implementing it.

    0
    Comment actions Permalink
  • Avatar
    Robert Hall

    It's because earlier this year they narrowed the scope of the roadmap on Trello. It used to list every major feature that was planned, but now only shows what they're going to work on in the current and next quarters.

    1
    Comment actions Permalink
  • Avatar
    Jay Stevens

    +1 for this request. My party is using Tabletop Simulator to run our campaign, and as a DM I have to have multiple monitors -- one with Tabletop Simulator to see where the party is moving, and one with D&D Beyond so I can see the rolls the party is making.

    If there was a way I could get Avrae data in Tabletop Simulator, it would be great. But unfortunately, it doesn't seem like there's an easy way to do that.

    0
    Comment actions Permalink
  • Avatar
    Matthew Strasiotto

    Shame this is unlikely to see the light of day - there's clearly a lot of interest.

    Shawn Tabai put forward their own client facing api "hack" , with a strongly worded caveat warning that their solution is frail, hacky, breaks ddb's TOS, and is generally not good. 

    I won't argue the legalities, but I will argue that the method of scraping a webpage in lieu of an API is not necessarily terrible- As long as you provision this process in a way that gives upstream benefit to other services. 

    A few strong examples
    ( A note on terminology - I'm going to categorize the API's/dataflow into "north" and "south" bound - This is intended as in the vernacular of software defined networking and other system archietectures where generally, the northbound interface provides higher level abstractions, and the southbound interface decomposes nortbound queries into technical details, eg, interacting with a specific component etc.

    • https://github.com/Jackett/Jackett  is a torrent tracker site scraper that acts as a proxy server to support upstream services with a stable API.
      It essentially provides a stable northbound API to apps/services that implement its API, and translates this to a variety of unstable southbound "API"s ( http queries w/ html responses ) which it parses & translates to the northbound API.
      This really works, and works really quite well from what I can see - By centralizing the burden of the scraping, parsing & translating logic, northbound apps can focus on what they're good at, and there's minimal duplicated work. 
      The typical usage scenario is to self-host an instance of this, with dependant apps (docker-compose) making API calls to the proxy, and the proxy can scrape for the data.

    • https://github.com/jarun/googler googler is a popular CLI for google - typical usage is to alias `@g='googler'` , and then use that to fetch your results. It's a nifty gadget, with a lot of flexibility.
      The maintainer states:
      Google provides a search API which returns the results in JSON format. However, as per my understanding from the official docs, the API issues the queries against an existing instance of a custom search engine and is limited by 100 search queries per day for free. In addition, I have reservations in paying if they ever change their plan or restrict the API in other ways. So I refrained from coupling with Google plans & policies or exposing my trackable personal custom search API key and identifier for the public. I retained the browser-way of doing it by fetching html, which is a open and free specification.

      The speculated behaviour of revoking a free service or product is not uncharacteristic for google, they pull that stunt all the time, whenever they estimate that their free product they've probably operated at a loss for some time has enough market dominance, or is fundamental to enough processes, that they can gouge people for it.

    If i were to try to implement a service that interfaced with dndbeyond, I'd probably follow `jackett`'s approach, and first implement a middleware proxy service that translates standardized queries into fetch, scrape parse logic that returns a stable API.

    Ideally maintenence of the soutbound logic would then be concentrated enough that keeping up with an unstable frontend interface would no longer be unfeasible, and useful northbound apps could be actually be developed.

    The question of whether there would be enough community support / developer interest to support this is raised - There'd probably need to be a show of value before people jumped on board.

    From that point, the spectre of a DMCA takedown notice when some WOTC exec is having a bad day would hover over the project as well, especially if the project reaches scale, or if northbound apps start trying to do things that are actually in bad faith.

    2
    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
    Kyse Ghashim

    As a side note, though it's a ToS violation and discouraged at the risk of being banned, the character sheet's JSON is plainly visible as a get request in your developer tools network tab.

    If you want something programmatically, you can intercept the request to the player API with a few tweaks to the window objects XHR, and parse the resulting JSON. Alternatively, you can just send a request to their auth API with your cookies for an auth token and forward that to the character API with the character id, and receive the JSON back. All those things work so long as you're on that site, or falsifying headers in the request.

    A few things DND Beyond can do to limit that access to the API would be restructuring the site into subdomains to invoke CORS for the browsers that respect such policies. For the request for data that don't respect these policies, they can implement obfuscating/encrypting the data (decent idea) or instating a data quota/throttling (horrible idea).

    0
    Comment actions Permalink
  • Avatar
    jastreich

    Kyse Ghashim Ghashim - Yes, for personal use, you can curl the JSON, because the cookies are yours. And we've talked on page 2 how a chrome extension can be used to get around the simple CORS problem, because it isn't on another site.  The reluctance is all about TOS, legality and risk(s) of losing access to your "purchased" (I say it with quotes because it is really license, not purchase if you read the fine print. Like "buying" digital content from Amazon) content if you get banned.

    There is a ratelimit on the JSON for character sheets.  That said, when I get a spare minute I think I might write my own answer to DM notes that uses the chrome extension approach, as it is the least likely to killed by Fandom and WotC -- and if it is useful enough they might aquire it like they did the Discord bot (Really wishful thinking -- i know).

    0
    Comment actions Permalink
  • Avatar
    Kyse Ghashim

    You truly don't even need to develop an extension, you can simply use a userscript. Unless you plan to have the extensions dev loaded, I don't imagine any marketplace will keep it up after a DMCA is filed against it, if they do. With a userscript, you can simply upload it to any text host. If you want a more robust app, you can always use a bundler.

    You have an interesting idea. I don't DM, but purchased Master sub and almost all the books for my DMs and players to use, so I don't truly grasp the benefits that would bring.

    In any case, good luck!

    0
    Comment actions Permalink
  • Avatar
    Devin Birtciel

    Not sure if this is a good place for this:
    Some webhooks so dm's can monitor changes on character sheets especially with new players?

    The ability to post to homebrew so I could build monsters and items using custom tools?

    Some published events to display the log messages to online boards for those trapped in Roll20 etc?

    0
    Comment actions Permalink
  • Avatar
    Andrew Obrigewitsch

    I'm currently working on a project to help reduce the number of sites and app needed to play DND, I'm not replacing DND, but figure some folks here may be interested in helping out. 

    I've gotten a backend written with GraphQL API and am using Next.js with Typescript for the front end. Just getting started on the front end now. 

    1
    Comment actions Permalink
  • Avatar
    Matthew Strasiotto

    @andrew sounds cool, would love to help

    0
    Comment actions Permalink
  • Avatar
    Andrew Obrigewitsch

    @matthew, how do I get in contact with you? You can find me on LinkedIn if you google my name.

    0
    Comment actions Permalink
  • Avatar
    Matthew Strasiotto

    @andrew check your twitter dms

    0
    Comment actions Permalink
  • Avatar
    Josh Cash

    Andrew Obrigewitsch If you are still working on that project, I am interested

    0
    Comment actions Permalink
  • Avatar
    Andrew Obrigewitsch

    I am working on it.

    0
    Comment actions Permalink
  • Avatar
    Andrew Obrigewitsch

    I’m pretty easy to find on LinkedIn if you want to reach out.

    0
    Comment actions Permalink
  • Avatar
    Zachjallen

    Proper auth would be paramount as you don't want this to be abused but as the original request stated and I would like to include your campaigns, characters, and characters in your campaign. Getting all this info would be great and promote so many excellent tools and discord bots to augment or work with ddb would be a huge draw and boon to the community.

    1
    Comment actions Permalink
  • Avatar
    Lionel Di Giacomo

    API patterns are so standard at this point, virtually no design needs to go into auth.

    • Users generate an API key from their account. 
    • The key could be rate-limited based on your subscription plan.
    • For security, you could view usage and rotate the key whenever you want.

    The hardest part of the issue is that they'd have to settle on and document an API, but even if they change it all the time they could version it with /v1/, /v2/, etc. to accommodate apps on an older API.

    At this point, I believe that early in DDB's success the devs at the time were excited to offer this feature and promised it to us, but quickly business reasons to not offer the feature outweighed any internal enthusiasm. The reasons I speculate are:

    • Costs; DDB will have to spend money developing the API, maintaining hardware and software to handle all those additional API requests, and suddenly their support load increases.
    • Limited ROI; DDB is already popular. They may feel that the API is a niche product that won't attract many subscribers, and could even damage them in the market.
    • Competition; Enabling third party apps introduces competition against DDB's own products using their own database. Imagine some examples:
      - An app that can more efficiently manage your DDB content might gain popularity over DDB's app, losing them eyeballs on all their promotional links (ads) to their own paid content.
      - MapTool or foundry could suddenly sync perfectly with DDB characters / campaigns. There is little chance any group will bother with any far less mature first party Virtual Tabletop from DDB.
      - Imagine a site that you can sync your characters to, but organizes them into campaigns in a way smarter / easier way than DDB does without any of the restrictions that are unlocked by subscribing to DDB.

    The benefits to the community are obvious - a thriving marketplace of innovative, fun tools and cool integrations. There are  a variety of ways to limit others profiting off the API, and I personally think that the benefits outweigh the risks - a great API would make DDB even more massively popular and greatly strengthen the whole community.

    Right now, I'm pretty sure they're thinking of all the risks instead of how great it would be for everyone. Right now I subscribe so my players can make characters for my games, but we manually sync back and forth with our tabletop software.

    Since the promise of an API for all intents and purposes has been broken, I've lost enthusiasm for buying new sources on DDB; rather we just homebrew in anything we're missing we need from the physical books. 

    -1
    Comment actions Permalink
  • Avatar
    Shawn Tabai

    I agree, Lionel. This is a very well-established industry pattern, the only serious obstacle is business backing.

    I have moved to using simpler RPG systems that are not as data-centric. This wasn't necessarily driven by the lack of an API, but that certainly might have helped me stay interested.

    0
    Comment actions Permalink
  • Avatar
    Andrew Obrigewitsch

    I agree with everyone here as well. The lack of openness as well all know in the tech world can undo a company. If something easier to use comes along that integrates with many other services, DND Beyond may start reduce its market share. 

    0
    Comment actions Permalink
  • Avatar
    Jens Murer

    Tghere's an old post about the possibility to get the character-sheet data by JSON, which doesn't work for me. That alone would be a great read-only way for me to simplify my combat action. By now I have a paper sheet and marker telling me, what my charater can do. Is there still a way to get the json?

    0
    Comment actions Permalink

Please sign in to leave a comment.