Last updated on
8 September 2016

Please use Drupal.org’s APIs respectfully.

  • Use an appropriate user agent string.
  • Make requests from a single thread.
  • Cache results locally whenever possible.

Abuse will be blocked as needed.

For support and requesting API changes, use the Infrastructure issue queue.

RESTful Web Services

Drupal.org uses the RESTful Web Services module to expose node, comment, user, file, and taxonomy_term resources. An important difference is that Drupal.org prepends api-d7/ to paths, which may be removed in the future. For example, this page is available at https://www.drupal.org/api-d7/node/2773581.json. Only read access is allowed.

All requests must either have an Accept: [application/json|application/xml] request header or .[json|xml] extension.

Additionally the api provides querying capabilities. These endpoints are available at https://www.drupal.org/api-d7/{entity-type}.json

The query endpoints will return up to 100 resources, paged, and controlled by filters on the entity.
For example, https://www.drupal.org/api-d7/node.json?type=casestudy will return the first 100 nodes of the casestudy type. To filter the entity, add another querystring parameter for the field you wish to filter on.
https://www.drupal.org/api-d7/node.json?type=casestudy&field_status=feat... will show just the case studies that are 'featured'

The following entities are available through the Drupal.org API:

Adding filters to narrow your results

For further information and features see the RestWS documentation: http://cgit.drupalcode.org/restws/tree/README.txt#n92

Limit your query and paginate

You can pass special meta controls to your query: limit, page, sort, and direction. For example, if you only wanted users 11-20 sorted by user id descending: https://www.drupal.org/api-d7/user.json?limit=10&page=2&sort=uid&directi...

Filter by user status

Not all user data is useful. We have a large number of spam user accounts that have been created. It is recommended that any user query include the "status" filter set to "1"—this will only return "active" (not blocked) users: https://www.drupal.org/api-d7/user.json?status=1

Even with this filter, you will see a large amount of spam account data. This is a limitation of our data at this time. (If you want to write an application with our API to help identify and clean up spam users based on profile data, please do.)

Filter by content type

The content types listed below link to their filtered JSON query.

Deprecated content types

You probably will not need these.

Filtering on issue data

Of particular interest is interacting with the issue queues. Some of the field values returned by the api are the numeric representations in the database. The following mappings are used for some key fields on project_issue nodes:

  • 400 = Critical
  • 300 = Major
  • 200 = Normal
  • 100 = Minor
  • 1 = active
  • 2 = fixed
  • 3 = closed (duplicate)
  • 4 = postponed
  • 5 = closed (won't fix)
  • 6 = closed (works as designed)
  • 7 = closed (fixed)
  • 8 = needs review
  • 13 = needs work
  • 14 = reviewed & tested by the community
  • 15 = patch (to be ported)
  • 16 = postponed (maintainer needs more info)
  • 18 = closed (cannot reproduce)
  • 1 = Bug report
  • 2 = Task
  • 3 = Feature request
  • 4 = Support request
  • 5 = Plan
Available Taxonomy Vocabularies
  • 1 = Forums (Special case, uses taxonomy_forums instead of taxonomy_term_1)
  • 2 = Screenshots
  • 3 = Module categories
  • 5 = Drupal version
  • 6 = Core compatibility
  • 7 = Release type
  • 9 = Issue tags
  • 31 = Page status
  • 34 = Front page news
  • 38 = Audience
  • 44 = Maintenance status
  • 46 = Development status
  • 48 = Services
  • 50 = Sectors
  • 52 = Locations
  • 54 = Keywords
  • 56 = Level
  • 58 = License
  • 60 = Book availability
  • 62 = Book format

Sample Queries

Get the data for a project (like its nid):


Show all the change notices for a project:


Show all the critical, needs review issues for drupal 8.0.x:


Show all the issues tagged with "d8dx":


Show all the Drupal Core Security Advisory nodes (Forum taxonomy term 44)

Forum terms use taxonomy_forums= instead of taxonomy_term_1=tid:


Get all the comments for a particular node.

Note: Comments use the filter ‘node’, instead of nid.

Get information on a particular file.


Other APIs


Index of all projects

Drupal.org exposes a view with this information:

(Also works for theme engines, drupal.org projects and other project_foo types listed above.)


Drupal’s update status infrastructure provides information on available releases at https://updates.drupal.org/release-history/{project}/[all|5.x|6.x|7.x|8.x]. For example, https://updates.drupal.org/release-history/drupal/8.x.

This API is implemented by Drupal Core’s update module.

Git Attribution

All users have a git attribution value that can be obtained by using the following: /user/{uid}/git-attribution, where {uid} is the Drupal.org user ID. This does not work with the /u/{name} aliases, it must be the un-aliased path. This callback will result in a JSON object containing the author value to use as the git --author value:

Example: https://www.drupal.org/user/1/git-attribution

{ author: "dries <dries@1.no-reply.drupal.org>" } 


Various pages have RSS feeds, discoverable via <link rel="alternate" type="application/rss+xml" …> tags. This is a good way to find recently-updated content.

Drupal.org subsites

Assoc.Drupal.org’s APIs include Association Membership.
Localization client sends translations to localize.drupal.org.

Tools for interacting with Drupal.org's API

  • Drupal.org API Component: This SDK provides a simple PHP layer for interacting with Drupal.org's API. Currently it supports Users and Nodes with special handling for Project Issue & Page Nodes.
  • Drupal.org API client: An alternative to above based on Guzzle 6. It supports all the listed entity types and provides constants to deal with vocabularies, issue status, etc. It is used for DruStats and other projects.