5e-srd-api: a hosted REST and GraphQL API for the D&D 5e SRD

One monorepo, four separately released units

The repository is described as the 5e-bits monorepo, and its layout section lists four units, each with its own README and each with a different job.

`apps/api` is the REST and GraphQL API, the part that serves the data. `apps/docs` is the Docusaurus documentation site, published at docs.dnd5eapi.co. `apps/infrastructure` is an AWS CDK stack for the dnd5eapi.co S3, CloudFront and Route 53 resources, and the README notes it was merged in from a separate 5e-bits/infrastructure repository. `packages/5e-database` holds the seed data and scripts, and that too was merged in from its own repository, 5e-bits/5e-database.

The two merges are worth noting because they explain the release tags. The recent releases are not one version line. They are `5e-srd-api-v7.3.3`, `5e-database-v7.8.2` and `5e-database-v7.8.1`, three separate tags, each naming the unit it belongs to. The API and the database are versioned independently, and each has its own major line, so an API release and a database release can ship on the same day without sharing a version number.

That structure is a deliberate choice for a project that serves data and hosts its own infrastructure and documentation. It also means a consumer who pins a version has to decide which of the two version lines to pin, and which combination is known to work together.

The API answers with both REST and GraphQL

The API application is described in the layout as the REST/GraphQL API, which is the only detail the top-level README gives about its surface, and it points to the `apps/api` README and to the documentation site for more.

Offering both is a deliberate redundancy rather than a duplication. A REST client wants stable paths and query parameters, a browser client wants a typed schema and the ability to request exactly the fields it needs, and a tool that supports both lets the same consumer pick based on where the code runs. For a rules database with deep relationships, a monster with spell references, a spell with components and classes, a class with features, the GraphQL option is the one that avoids a waterfall of requests, and the REST option is the one that works from a script with no schema tooling.

The deployment target is worth noting too. The infrastructure stack covers S3, CloudFront and Route 53, which is a static-asset-plus-CDN shape, and the monorepo's database package holds seed data with scripts. That is consistent with a read-mostly published corpus: the data is versioned as files, and the serving layer sits in front of it.

What the top-level README does not describe is the schema itself, the authentication model, the pagination behavior, the rate limits, or the cache headers. For all of that, the documentation site at docs.dnd5eapi.co and the `apps/api` README are the sources, and this page cannot fill that gap.

Getting the repo running needs Node 24 and pnpm

The getting started section is short and specific. It requires Node 24 and pnpm, and notes that `corepack enable` picks up the pinned version.

The install itself is one command:

pnpm install

The root `package.json` confirms the pins. The package is private and named `5e-bits-monorepo`, the package manager field reads `[email protected]`, and the engines field requires `node: 24.x`. A `.nvmrc` sits at the top level as well, and there is a `pnpm-workspace.yaml` alongside a `pnpm-lock.yaml`.

The README then hands off to the individual apps. Each app has its own run instructions, and for starting the API and the database locally it points at `apps/api/README.md` under the how-to-run heading. That is the point to look if you want a local stack, since the top-level document deliberately does not duplicate each app's commands.

The pinned Node major version is worth flagging for anyone who wants to run this. Node 24 is required, not merely recommended, and the package manager version is pinned exactly rather than by range, so the same `corepack enable` step is what keeps a contributor's local setup aligned with what the lockfile expects.

The database package is versioned on its own cadence

The `packages/5e-database` unit holds seed data and scripts, and the release history shows it moving faster than the API.

The three most recent releases are `5e-database-v7.8.2` on 2026-10-19, `5e-database-v7.8.1` on 2026-10-15, and `5e-srd-api-v7.3.3` on 2026-10-19. So within a single day the database moved to 7.8.2 and the API moved to 7.3.3, and four days earlier the database had already shipped 7.8.1.

That pattern says something about the data. A rules database changes when the underlying content is corrected, expanded, or resynced with a new SRD version, and those changes are additive to the data without necessarily changing the API contract. The API, by contrast, changes when its shape changes. The two version lines therefore mean different things, and a consumer pinning the API version alone has not pinned the data version.

The scripts mentioned alongside the seed data are the other half of the picture. A package that carries both the data and the tooling to load it is the versioned unit, so a deployment can say precisely which corpus it is serving. The README does not describe the script names, the file format of the seed data, or how the load happens, and the `packages/5e-database` README is where that would be documented.

Releases are cut by release-please, not by hand

The top level of the repository contains `.release-please-manifest.json` and `release-please-config.json`, which is the standard configuration for release-please, the tool that derives a version bump and a changelog from conventional commit messages and opens a release pull request.

That choice explains the tag format. The release names are prefixed with the unit they belong to, `5e-srd-api-v7.3.3` and `5e-database-v7.8.2`, which is what release-please produces for a monorepo with multiple independently released packages. The version numbers themselves are not in step, 7.3.3 against 7.8.2, which confirms the independence rather than a shared root version.

For a consumer, the practical implication is that version history is readable from the tags without any interpretation. A tag beginning `5e-srd-api` is an API release, a tag beginning `5e-database` is a data release, and each has its own changelog in its own release page.

The other repository signals are conventional and worth a brief mention. There is a `CODE_OF_CONDUCT` link in the README pointing to the repository wiki, a CI badge for a workflow file at `ci.yml`, a Discord invite, and a contributing section that asks for a fork, a branch, a push and a pull request, with the encouraging note that incomplete work is totally fine and that maintainers would love to help get it ready for merging.

Compared with a self-hosted data set and a scraped game wiki

There are two other ways to get structured 5e rules data into an application, and the difference in approach is about where the data comes from and who maintains it.

A self-hosted data set means you keep your own copy of the rules, monsters, spells and items, in whatever format you choose, and you serve it from your own infrastructure. The advantage is total control over availability and query cost, and the ability to add fields the published API does not carry. The cost is that somebody owns the ingest. The SRD content changes, the text of a monster description changes, an item gets a variant, and keeping a local copy current is ongoing work that this repository's seed data and scripts exist to do for someone else.

A scraped wiki or a community-maintained JSON file is somewhere in between. It is free and often more complete, but it comes with no availability contract, no schema stability, and no versioning, so a consumer that depends on it has to handle the data changing shape under it.

This API takes the middle path. The data is a versioned artifact, the release history tells you exactly which corpus you are on, the schema is documented on a docs site, and the content is the published SRD, which is the point where licensing and completeness are settled rather than murky. What you give up is the ability to extend the data yourself without forking, and the guarantee that it covers anything outside the SRD.

For a tool that displays rules to players, that is the right trade. For a tool that needs to model a campaign's homebrew rules on top of the SRD, the SRD API is the base layer and you will still be writing your own storage for the rest.

Editorial conclusion

Adopt the 5e SRD API if you are building a tool that needs structured D&D 5e rules data, monsters, spells or equipment and want both REST and GraphQL from one hosted service with published documentation. Do not adopt it as a source of truth for anything beyond the SRD itself, since the rules content is the published SRD rather than a superset. Verify first which version of the database your queries expect, because the API and the database are versioned separately and both moved on 2026-10-19.

Frequently asked questions

Official sources

1. 5e-bits/5e-srd-api on GitHub
2. Issues
3. License: MIT
4. README
5. Releases