├── .gitignore ├── bin ├── templates │ ├── reference-parts │ │ ├── examples │ │ │ ├── update-post-curl.html │ │ │ └── update-comment-curl.html │ │ ├── create-item.html │ │ ├── delete-item.html │ │ ├── update-item.html │ │ ├── get-item.html │ │ ├── list-item.html │ │ ├── args-list.html │ │ └── schema.html │ └── endpoint.md ├── generate-manifest.php ├── parse-wxr.php └── regenerate.php ├── composer.json ├── README.md ├── reference ├── navigation-fallbacks.md ├── block-pattern-categories.md ├── rendered-blocks.md ├── wp_global_styles.md ├── menu-locations.md ├── widget-types.md ├── search-results.md ├── wp-site-health-tests.md ├── post-statuses.md ├── block-patterns.md ├── wp_global_styles-revisions.md ├── block-directory-items.md ├── pattern-directory-items.md ├── taxonomies.md ├── sidebars.md ├── themes.md ├── post-types.md ├── widgets.md ├── application-passwords.md ├── plugins.md └── nav_menu_item-revisions.md ├── extending-the-rest-api.md ├── using-the-rest-api.md ├── using-the-rest-api ├── client-libraries.md ├── pagination.md ├── linking-and-embedding.md ├── authentication.md ├── global-parameters.md ├── discovery.md └── backbone-javascript-client.md ├── key-concepts.md ├── glossary.md ├── index.md ├── reference.md ├── frequently-asked-questions.md └── extending-the-rest-api └── adding-rest-api-support-for-custom-content-types.md /.gitignore: -------------------------------------------------------------------------------- 1 | # Ignore Composer files 2 | .idea/ 3 | vendor/ 4 | -------------------------------------------------------------------------------- /bin/templates/reference-parts/examples/update-post-curl.html: -------------------------------------------------------------------------------- 1 | $ curl -X POST https://example.com/wp-json{{ route.nicename }} -d '{"title":"My New Title"}' 2 | -------------------------------------------------------------------------------- /bin/templates/reference-parts/examples/update-comment-curl.html: -------------------------------------------------------------------------------- 1 | $ curl -X POST https://example.com/wp-json{{ route.nicename }} -d '{"content":"My updated comment"}' 2 | -------------------------------------------------------------------------------- /composer.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "wp-api/docs", 3 | "description": "The WordPress REST API Handbook", 4 | "require": { 5 | "rmccue/requests": "^2.0", 6 | "twig/twig": "^3.0" 7 | }, 8 | "scripts": { 9 | "regenerate": "php bin/regenerate.php" 10 | } 11 | } 12 | -------------------------------------------------------------------------------- /bin/templates/reference-parts/create-item.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |

Create a {{ name | title }}

4 | {{ include( 'reference-parts/args-list.html', { args: endpoint.args, link: true } ) }} 5 |
6 |
7 |

Definition

8 | 9 | POST {{ route.nicename }} 10 |
11 |
12 | -------------------------------------------------------------------------------- /bin/templates/endpoint.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # {{ plural | title }} 5 | 6 |
7 |
8 | {{ include('reference-parts/schema.html') }} 9 |
10 |
11 | 12 |
13 | {%- for route in routes -%} 14 | {%- for endpoint in route.endpoints -%} 15 | {{- include( 'reference-parts/' ~ endpoint.type ~ '.html' ) -}} 16 | {%- endfor -%} 17 | {%- endfor -%} 18 |
19 | -------------------------------------------------------------------------------- /bin/templates/reference-parts/delete-item.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |

Delete a {{ name | title }}

4 | {{ include( 'reference-parts/args-list.html', { args: endpoint.args } ) }} 5 |
6 |
7 |

Definition

8 | 9 | DELETE {{ route.nicename }} 10 | 11 |

Example Request

12 | 13 | $ curl -X DELETE https://example.com/wp-json{{ route.nicename }} 14 |
15 |
16 | -------------------------------------------------------------------------------- /bin/templates/reference-parts/update-item.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |

Update a {{ name | title }}

4 | {{ include( 'reference-parts/args-list.html', { args: endpoint.args, link: true } ) }} 5 |
6 |
7 |

Definition

8 | 9 | POST {{ route.nicename }} 10 | 11 |

Example Request

12 | 13 | {{ include( 'reference-parts/examples/update-' ~ route.schema.title ~ '-curl.html', ignore_missing = true ) }} 14 |
15 |
16 | -------------------------------------------------------------------------------- /bin/templates/reference-parts/get-item.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |

Retrieve a {{ name | title }}

4 | 5 |

Definition & Example Request

6 | 7 | GET {{ route.nicename }} 8 | 9 |

Query this endpoint to retrieve a specific {{ name }} record.

10 | 11 | $ curl https://example.com/wp-json{{ route.nicename }} 12 |
13 |
14 | {{ include( 'reference-parts/args-list.html', { args: endpoint.args, link: false } ) }} 15 |
16 |
17 | -------------------------------------------------------------------------------- /bin/templates/reference-parts/list-item.html: -------------------------------------------------------------------------------- 1 |
2 |
3 |

List {{ plural | title }}

4 |

Query this endpoint to retrieve a collection of {{ plural }}. The response you receive can be controlled and filtered using the URL query parameters below.

5 | 6 |

Definition

7 | 8 | GET {{ route.nicename }} 9 | 10 |

Example Request

11 | 12 | $ curl https://example.com/wp-json{{ route.nicename }} 13 |
14 |
15 | {{ include( 'reference-parts/args-list.html', { args: endpoint.args, link: false } ) }} 16 |
17 |
18 | -------------------------------------------------------------------------------- /bin/templates/reference-parts/args-list.html: -------------------------------------------------------------------------------- 1 | {% if args|length > 0 %} 2 |

Arguments

3 | 4 | {% for key, arg in args %} 5 | 6 | 13 | 31 | 32 | {% endfor %} 33 |
7 | {% if link %} 8 | {{ key }}
9 | {% else %} 10 | {{ key }}
11 | {% endif %} 12 |
14 | {% if arg.description %} 15 |

{{ arg.description }}

16 | {% endif %} 17 | {% if arg.required %} 18 |

19 | Required: {{ arg.required }} 20 |

21 | {% endif %} 22 | {% if arg.default %} 23 |

24 | Default: {{ arg.default }} 25 |

26 | {% endif %} 27 | {% if arg.enum %} 28 |

One of: {{ arg.enum | e | join(", ") | raw }}

29 | {% endif %} 30 |
34 | {% else %} 35 |

There are no arguments for this endpoint.

36 | {% endif %} 37 | -------------------------------------------------------------------------------- /bin/generate-manifest.php: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env php 2 | $slug, 33 | 'parent' => $parent, 34 | 'markdown_source' => sprintf( 'https://github.com/%s/blob/master/%s.md', $repo, $key ), 35 | ); 36 | } 37 | } 38 | 39 | file_put_contents( $root . '/bin/manifest.json', json_encode( (object) $manifest, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES ) ); 40 | 41 | $count = count( $manifest ); 42 | echo "Generated manifest.json of {$count} pages\n"; 43 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # API Docs 2 | 3 | This repo contains the source for [documentation for the API](https://developer.wordpress.org/rest-api/) on developer.wordpress.org (DevHub). 4 | 5 | ## Adding/Removing Files 6 | 7 | When creating new files, these must be added to the manifest. Run `bin/generate-manifest.php` to update this. 8 | 9 | Removing files also requires regenerating the manifest. After deletion and sync with DevHub, the page also needs to be manually deleted from DevHub. 10 | 11 | ## Refreshing the Templated API Reference 12 | 13 | The reference section is created by parsing the output of a site's schema as retrieved from that site's REST API index route. The current method used to generate this approach is as follows: 14 | 15 | - Create a local WordPress environment (always use the current or Release Candidate version of WordPress) using the local environment tool of your choice. 16 | - Edit `/etc/hosts` to map the domain `example.com` to the IP of that WordPress instance, and ensure the site is configured to run at `example.com`. 17 | - Run `composer install` in this project's root directory to install dependencies. 18 | - Run `composer run-script regenerate` in this project's root directory to run the asset regeneration script. 19 | - Use `git status` and `git diff` to validate that the files were updated as expected. 20 | -------------------------------------------------------------------------------- /bin/templates/reference-parts/schema.html: -------------------------------------------------------------------------------- 1 |

Schema

2 |

The schema defines all the fields that exist within a {{ name }} record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

3 | 4 | {% for key, property in schema.properties %} 5 | 6 | 9 | 29 | 30 | {% endfor %} 31 |
7 | {{ key }} 8 | 10 |

{{ property.description }}

11 |

12 | JSON data type: {{ property.type | join(' or ') }}{% if property.format %}, 13 | {% if property.format == 'date-time' %} 14 | Format: datetime (details) 15 | {% elseif property.format == 'uri' %} 16 | Format: uri 17 | {% else %} 18 | Format: {{ property.format }} 19 | {% endif %}{% endif %} 20 |

21 | {% if property.readonly %} 22 |

Read only

23 | {% endif %} 24 |

Context: {{ property.context | e | join(", ") | raw }}

25 | {% if property.enum %} 26 |

One of: {{ property.enum | e | join(", ") | raw }}

27 | {% endif %} 28 |
32 | -------------------------------------------------------------------------------- /reference/navigation-fallbacks.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Navigation Fallbacks 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a navigation fallback record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 |
13 | id 14 | 16 |

The unique identifier for the Navigation Menu.

17 |

18 | JSON data type: integer

19 |

Read only

20 |

Context: view, edit, embed

21 |
24 | 25 |
26 |
27 | 28 |
29 |
30 |

Retrieve a Navigation Fallback

31 | 32 |

Definition & Example Request

33 | 34 | GET /wp-block-editor/v1/navigation-fallback 35 | 36 |

Query this endpoint to retrieve a specific navigation fallback record.

37 | 38 | $ curl https://example.com/wp-json/wp-block-editor/v1/navigation-fallback 39 |
40 |
41 |

There are no arguments for this endpoint.

42 | 43 |
44 |
45 |
46 | -------------------------------------------------------------------------------- /extending-the-rest-api.md: -------------------------------------------------------------------------------- 1 | # Extending the REST API 2 | 3 | ## Guides 4 | 5 | [Modifying responses](https://developer.wordpress.org/rest-api/extending-the-rest-api/modifying-responses/): add fields to REST API response objects using `register_meta` or `register_rest_field` 6 | 7 | [Adding Endpoints](https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-custom-endpoints/): create custom REST API endpoints for your plugin or application 8 | 9 | [Working with Custom Content Types](https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-rest-api-support-for-custom-content-types/): learn how to interact with your [custom post types](https://developer.wordpress.org/plugins/post-types/) and [custom taxonomies](https://developer.wordpress.org/plugins/post-types/) through the REST API 10 | 11 | 12 | ## Resources 13 | 14 | [Defining your API Schema](https://developer.wordpress.org/rest-api/extending-the-rest-api/schema/): define the schema for your REST API resources and their arguments 15 | 16 | [Glossary](https://developer.wordpress.org/rest-api/glossary/): get up to speed with phrases used throughout our documentation 17 | 18 | [Routes & Endpoints](https://developer.wordpress.org/rest-api/extending-the-rest-api/routes-and-endpoints/): dive deeper into the nuances of REST API routes and the endpoints they provide 19 | 20 | [Controller Classes](https://developer.wordpress.org/rest-api/extending-the-rest-api/controller-classes/): discover how to structure and extend REST API endpoint controller classes 21 | 22 | 23 | [Frequently Asked Questions](https://developer.wordpress.org/rest-api/frequently-asked-questions/): see some of the most frequent inquiries about the REST API and learn how to solve common problems 24 | -------------------------------------------------------------------------------- /using-the-rest-api.md: -------------------------------------------------------------------------------- 1 | # Using the REST API 2 | 3 | These articles explore the basic structure of the WordPress REST API. 4 | 5 | [Global Parameters](https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/): learn about the global REST API query parameters that apply to every endpoint 6 | 7 | [Pagination](https://developer.wordpress.org/rest-api/using-the-rest-api/pagination/): work with large collections of resources & control how many records you receive from the REST API 8 | 9 | [Linking & Embedding](https://developer.wordpress.org/rest-api/using-the-rest-api/linking-and-embedding/): understand how to read and modify connections between different objects, and embed related resources such as author and media data in the REST API's responses 10 | 11 | [Discovery](https://developer.wordpress.org/rest-api/using-the-rest-api/discovery/): determine what REST API resources a site supports, and where they are located 12 | 13 | [Authentication](https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/): authorize your REST API requests so that you can create, update and delete your data 14 | 15 | [Frequently Asked Questions](https://developer.wordpress.org/rest-api/frequently-asked-questions/): see some of the most frequent inquiries about the REST API and learn how to solve common problems 16 | 17 | 18 | ## Resources & Utilities 19 | 20 | [Backbone.js Client](https://developer.wordpress.org/rest-api/using-the-rest-api/backbone-javascript-client/): interact with the API from within WP-Admin using Backbone models & collections 21 | 22 | [Client Libraries](https://developer.wordpress.org/rest-api/using-the-rest-api/client-libraries/): utilities in a variety of programming languages that simplify interacting with the API 23 | -------------------------------------------------------------------------------- /bin/parse-wxr.php: -------------------------------------------------------------------------------- 1 | ' => '## ', 9 | '' => '', 10 | '

' => '### ', 11 | '

' => '', 12 | '[php]' => '```php', 13 | '<?php' => '<' . '?php', 14 | '[/php]' => '```', 15 | '' => '`', 16 | '' => '`', 17 | '' => '*', 18 | '' => '*', 19 | '' => '**', 20 | '' => '**', 21 | '“' => '"', 22 | '”' => '"', 23 | '’' => "'", 24 | '<' => '<', 25 | '>' => '>', 26 | '"' => '"', 27 | '&' => '&', 28 | ]; 29 | 30 | foreach ( $reader->channel->item as $item ) { 31 | $title = (string) $item->title; 32 | $url = (string) $item->link; 33 | $content = (string) $item->children( 'http://purl.org/rss/1.0/modules/content/' )->encoded; 34 | 35 | $wxr_item = $item->children( 'http://wordpress.org/export/1.2/' ); 36 | 37 | $status = (string) $wxr_item->status; 38 | if ( $status !== 'publish' ) { 39 | printf( "Skipping draft %s\n", $title ); 40 | continue; 41 | } 42 | 43 | $slug = str_replace( 'https://developer.wordpress.org/rest-api/', '', $url ); 44 | if ( empty( $slug ) ) { 45 | $slug = 'index'; 46 | } 47 | 48 | $slug = rtrim( $slug, '/' ) . '.md'; 49 | 50 | $path = $root . '/' . $slug; 51 | if ( ! file_exists( dirname( $path ) ) ) { 52 | mkdir( dirname( $path ), 0755, true ); 53 | } 54 | printf( "Creating %s: %s\n", $title, $path ); 55 | 56 | $markdowned = str_replace( 57 | array_keys( $markdown_map ), 58 | array_values( $markdown_map ), 59 | $content 60 | ); 61 | $markdowned = preg_replace( 62 | '#([^<]+)#i', 63 | '[\2](\1)', 64 | $markdowned 65 | ); 66 | $data = sprintf( "# %s\n\n%s\n", $title, $markdowned ); 67 | // echo str_replace( "\n", "\n\t", $data ) . "\n\n"; 68 | file_put_contents( $path, $data ); 69 | } 70 | -------------------------------------------------------------------------------- /reference/block-pattern-categories.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Block Pattern Categories 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a block pattern category record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 46 | 47 |
13 | name 14 | 16 |

The category name.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context: view, edit, embed

21 |
25 | label 26 | 28 |

The category label, in human readable format.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context: view, edit, embed

33 |
37 | description 38 | 40 |

The category description, in human readable format.

41 |

42 | JSON data type: string

43 |

Read only

44 |

Context: view, edit, embed

45 |
48 | 49 |
50 |
51 | 52 |
53 |
54 |

Retrieve a Block Pattern Category

55 | 56 |

Definition & Example Request

57 | 58 | GET /wp/v2/block-patterns/categories 59 | 60 |

Query this endpoint to retrieve a specific block pattern category record.

61 | 62 | $ curl https://example.com/wp-json/wp/v2/block-patterns/categories 63 |
64 |
65 |

There are no arguments for this endpoint.

66 | 67 |
68 |
69 |
70 | -------------------------------------------------------------------------------- /reference/rendered-blocks.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Rendered Blocks 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a Rendered Block record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 21 | 22 |
13 | rendered 14 | 16 |

The rendered block.

17 |

18 | JSON data type: string

19 |

Context: edit

20 |
23 | 24 |
25 |
26 | 27 |
28 |
29 |

Create a Rendered Block

30 |

Arguments

31 | 32 | 33 | 36 | 39 | 40 | 41 | 44 | 51 | 52 | 53 | 56 | 59 | 60 | 61 | 64 | 67 | 68 |
34 | name
35 |
37 |

Unique registered name for the block.

38 |
42 | context
43 |
45 |

Scope under which the request is made; determines fields present in response.

46 |

47 | Default: view 48 |

49 |

One of: edit

50 |
54 | attributes
55 |
57 |

Attributes for the block.

58 |
62 | post_id
63 |
65 |

ID of the post context.

66 |
69 | 70 |
71 |
72 |

Definition

73 | 74 | POST /wp/v2/block-renderer/<name> 75 |
76 |
77 |
78 | -------------------------------------------------------------------------------- /using-the-rest-api/client-libraries.md: -------------------------------------------------------------------------------- 1 | # Client Libraries 2 | 3 | The API can be used from any application by sending basic HTTP requests; however, client libraries simplify the process of querying or creating specific resources. These libraries make it easy to connect an external application to the WordPress REST API using a variety of programming languages. 4 | 5 | [alert]Aside from the Backbone.js client, these libraries are not part of WordPress core, and are not necessarily maintained or endorsed by the WordPress REST API team.[/alert] 6 | 7 | [info]To perform authenticated requests from outside of the WordPress admin, themes, or plugins, a separate authentication plugin is required.[/info] 8 | 9 | ## PHP 10 | 11 | [Requests](https://github.com/WordPress/Requests) for PHP is a general purpose HTTP request library. While not specifically designed for the WordPress REST API, it is a great tool for interacting with any HTTP API. 12 | 13 | [WordPress-PHP-SDK](https://github.com/madeITBelgium/WordPress-PHP-SDK) is a PHP SDK for the WordPress REST API, which can be installed using [composer](https://getcomposer.org/). 14 | 15 | [WordPress-SDK](https://github.com/storipress/wordpress-sdk) is a Laravel package for the WordPress REST API, which can be installed using [composer](https://getcomposer.org). 16 | 17 | ## JavaScript 18 | 19 | The [Backbone.js client](https://developer.wordpress.org/rest-api/backbone-javascript-client/) is built in to WordPress core and provides Backbone.js models & collections for working with REST API resources. 20 | 21 | [node-wpapi](http://wp-api.org/node-wpapi) is an isomorphic JavaScript client library for querying or writing to the REST API using an intuitive chaining syntax. It can be used with Node.js or with client-side JavaScript applications. 22 | 23 | [ember-wordpress](https://github.com/oskarrough/ember-wordpress) provides a connection between Ember Data and the REST API 24 | 25 | 26 | ## Ruby 27 | 28 | [wp-api-client](https://github.com/duncanjbrown/wp-api-client): a read-only REST API client written in Ruby. 29 | 30 | ## C# / .NET 31 | [WordPressPCL](https://github.com/wp-net/WordPressPCL): a full REST API client written in C#. 32 | 33 | ## Dart / Flutter 34 | [wordpress_client](https://pub.dev/packages/wordpress_client): A library exposing a fluent api to interact with the WordPress REST API. 35 | -------------------------------------------------------------------------------- /using-the-rest-api/pagination.md: -------------------------------------------------------------------------------- 1 | # Pagination 2 | 3 | WordPress sites can have a lot of content—far more than you'd want to pull down in a single request. The API endpoints default to providing a limited number of items per request, the same way that a WordPress site will default to 10 posts per page in archive views. 4 | 5 | 6 | ## Pagination Parameters 7 | 8 | Any API response which contains multiple resources supports several common query parameters to handle paging through the response data: 9 | 10 | * `?page=`: specify the page of results to return. 11 | * For example, `/wp/v2/posts?page=2` is the second page of posts results 12 | * By retrieving `/wp/v2/posts`, then `/wp/v2/posts?page=2`, and so on, you may access every available post through the API, one page at a time. 13 | 14 | * `?per_page=`: specify the number of records to return in one request, specified as an integer from 1 to 100. 15 | * For example, `/wp/v2/posts?per_page=1` will return only the first post in the collection 16 | 17 | * `?offset=`: specify an arbitrary offset at which to start retrieving posts 18 | * For example, `/wp/v2/posts?offset=6` will use the default number of posts per page, but start at the 6th post in the collection 19 | * `?per_page=5&page=4` is equivalent to `?per_page=5&offset=15` 20 | 21 | [tip] 22 | Large queries can hurt site performance, so per_page is capped at 100 records. If you wish to retrieve more than 100 records, for example to build a client-side list of all available categories, you may make multiple API requests and combine the results within your application. 23 | [/tip] 24 | 25 | To determine how many pages of data are available, the API returns two header fields with every paginated response: 26 | 27 | * `X-WP-Total`: the total number of records in the collection 28 | * `X-WP-TotalPages`: the total number of pages encompassing all available records 29 | 30 | By inspecting these header fields you can determine how much more data is available within the API. 31 | 32 | 33 | ## Ordering Results 34 | 35 | In addition to the pagination query parameters detailed above, several other parameters control the order of the returned results: 36 | 37 | * `?order=`: control whether results are returned in ascending or descending order 38 | * Valid values are `?order=asc` (for ascending order) and `?order=desc` (for descending order). 39 | * All native collections are returned in descending order by default. 40 | * `?orderby=`: control the field by which the collection is sorted 41 | * The valid values for `orderby` will vary depending on the queried resource; for the `/wp/v2/posts` collection, the valid values are "date," "relevance," "id," "include," "title," and "slug" 42 | * See the [REST API reference](https://developer.wordpress.org/rest-api/reference) for the values supported by other collections 43 | * All collections with dated resources default to `orderby=date` 44 | -------------------------------------------------------------------------------- /reference/wp_global_styles.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Global_Styles 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a global_styles record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 33 | 34 | 35 | 38 | 44 | 45 | 46 | 49 | 55 | 56 |
13 | id 14 | 16 |

ID of global styles config.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context: embed, view, edit

21 |
25 | styles 26 | 28 |

Global styles.

29 |

30 | JSON data type: object

31 |

Context: view, edit

32 |
36 | settings 37 | 39 |

Global settings.

40 |

41 | JSON data type: object

42 |

Context: view, edit

43 |
47 | title 48 | 50 |

Title of the global styles variation.

51 |

52 | JSON data type: object or string

53 |

Context: embed, view, edit

54 |
57 | 58 |
59 |
60 | 61 |
62 |
63 |

Retrieve a Global_Styles

64 | 65 |

Definition & Example Request

66 | 67 | GET /wp/v2/global-styles/<id> 68 | 69 |

Query this endpoint to retrieve a specific global_styles record.

70 | 71 | $ curl https://example.com/wp-json/wp/v2/global-styles/<id> 72 |
73 |
74 |

Arguments

75 | 76 | 77 | 80 | 83 | 84 |
78 | id
79 |
81 |

The id of a template

82 |
85 | 86 |
87 |
88 |
89 |
90 |

Update a Global_Styles

91 |

Arguments

92 | 93 | 94 | 97 | 100 | 101 | 102 | 105 | 108 | 109 | 110 | 113 | 116 | 117 |
95 | styles
96 |
98 |

Global styles.

99 |
103 | settings
104 |
106 |

Global settings.

107 |
111 | title
112 |
114 |

Title of the global styles variation.

115 |
118 | 119 |
120 |
121 |

Definition

122 | 123 | POST /wp/v2/global-styles/<id> 124 | 125 |

Example Request

126 | 127 | 128 |
129 |
130 |
131 | -------------------------------------------------------------------------------- /reference/menu-locations.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Menu Locations 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a menu location record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 46 | 47 |
13 | name 14 | 16 |

The name of the menu location.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context: embed, view, edit

21 |
25 | description 26 | 28 |

The description of the menu location.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context: embed, view, edit

33 |
37 | menu 38 | 40 |

The ID of the assigned menu.

41 |

42 | JSON data type: integer

43 |

Read only

44 |

Context: embed, view, edit

45 |
48 | 49 |
50 |
51 | 52 |
53 |
54 |

Retrieve a Menu Location

55 | 56 |

Definition & Example Request

57 | 58 | GET /wp/v2/menu-locations 59 | 60 |

Query this endpoint to retrieve a specific menu location record.

61 | 62 | $ curl https://example.com/wp-json/wp/v2/menu-locations 63 |
64 |
65 |

Arguments

66 | 67 | 68 | 71 | 78 | 79 |
69 | context
70 |
72 |

Scope under which the request is made; determines fields present in response.

73 |

74 | Default: view 75 |

76 |

One of: view, embed, edit

77 |
80 | 81 |
82 |
83 |
84 |
85 |

Retrieve a Menu Location

86 | 87 |

Definition & Example Request

88 | 89 | GET /wp/v2/menu-locations/<location> 90 | 91 |

Query this endpoint to retrieve a specific menu location record.

92 | 93 | $ curl https://example.com/wp-json/wp/v2/menu-locations/<location> 94 |
95 |
96 |

Arguments

97 | 98 | 99 | 102 | 105 | 106 | 107 | 110 | 117 | 118 |
100 | location
101 |
103 |

An alphanumeric identifier for the menu location.

104 |
108 | context
109 |
111 |

Scope under which the request is made; determines fields present in response.

112 |

113 | Default: view 114 |

115 |

One of: view, embed, edit

116 |
119 | 120 |
121 |
122 |
123 | -------------------------------------------------------------------------------- /key-concepts.md: -------------------------------------------------------------------------------- 1 | # Key Concepts 2 | 3 | In this page we'll break down some of the key concepts and terms associated with the REST API: **Routes & Endpoints,** **Requests**, **Responses**, **Schema**, and **Controller Classes**. Each of these concepts play a crucial role in understanding, using, and extending the WordPress REST API, and each is explored in greater depth within this handbook. 4 | 5 | ## Routes & Endpoints 6 | 7 | In the context of the WordPress REST API a **route** is a URI which can be mapped to different HTTP methods. The mapping of an individual HTTP method to a route is known as an **endpoint**. 8 | 9 | As an example, if we make a `GET` request to the URI http://oursite.com/wp-json/ we are returned a JSON response showing what routes are available, and what endpoints are available within each route. 10 | 11 | `/wp-json/` is a route, and when that route receives a `GET` request then that request is handled by the endpoint which displays what is known as the index for the WordPress REST API. 12 | 13 | The route `wp-json/wp/v2/posts` by contrast has a `GET` endpoint which returns a list of posts, but also a `POST` endpoint which accepts authenticated requests to create new posts. 14 | 15 | We will learn how to register our own routes and endpoints in the following sections. 16 | 17 | [info]If you are using [non-pretty permalinks](https://wordpress.org/support/article/using-permalinks/), you should pass the REST API route as a query string parameter. The route http://oursite.com/wp-json/ in the example above would hence be http://oursite.com/?rest_route=/.[/info] 18 | 19 | If you get a `404` error when trying to access http://oursite.com/wp-json/, consider enabling pretty permalinks or try using the `rest_route` parameter instead. 20 | 21 | ## Requests 22 | 23 | A REST API request is represented within WordPress by an instance of the `WP_REST_Request` class, which is used to store and retrieve information for the current request. A `WP_REST_Request` object is automatically generated when you make an HTTP request to a registered API route. 24 | 25 | The data specified in this object (derived from the route URI or the JSON payload sent as a part of the request) determines what response you will get back out of the API. 26 | 27 | Requests are usually submitted remotely via HTTP but may also be made internally from PHP within WordPress plugin or theme code. There are a lot of neat things you can do using this class, detailed further elsewhere in the handbook. 28 | 29 | ## Responses 30 | 31 | Responses are the data you get back from the API. The `WP_REST_Response` class provides a way to interact with the response data returned by endpoints. Responses return the requested data, or can also be used to return errors if something goes wrong while fulfilling the request. 32 | 33 | ## Schema 34 | 35 | Each endpoint requires a particular structure of input data, and returns data using a defined and predictable structure. Those data structures are defined in the API Schema. 36 | 37 | The schema structures API data and provides a comprehensive list of all of the properties the API can return and which input parameters it can accept. 38 | 39 | Well-defined schema also provides one layer of security within the API, as it enables us to validate and sanitize the requests being made to the API. The [Schema section](https://developer.wordpress.org/rest-api/extending-the-rest-api/schema/) explores this large topic further. 40 | 41 | 42 | ## Controller Classes 43 | 44 | Controller classes unify and coordinate all these various moving parts within a REST API response cycle. With a controller class you can manage the registration of routes & endpoints, handle requests, utilize schema, and generate API responses. 45 | 46 | A single class usually contains all of the logic for a given route, and a given route usually represents a specific type of data object within your WordPress site (like a custom post type or taxonomy). -------------------------------------------------------------------------------- /using-the-rest-api/linking-and-embedding.md: -------------------------------------------------------------------------------- 1 | # Linking and Embedding 2 | 3 | The WP REST API incorporates hyperlinking throughout the API to allow discoverability and browsability, as well as embedding related resources together in one response. While the REST API does not completely conform to the entire [HAL standard](https://en.wikipedia.org/wiki/Hypertext_Application_Language), it implements the `._links` and `._embedded` properties from that standard as described below. 4 | 5 | 6 | ## Links 7 | 8 | The `_links` property of the response object contains a map of links to other API resources, grouped by "relation." The relation specifies how the linked resource relates to the primary resource. 9 | 10 | Examples include: 11 | - `author` - describing a relationship between a resource and its author 12 | - `wp:term` - describing the relationship between a post and its tags or categories 13 | 14 | The relation is either a 15 | - [standardized relation](http://www.iana.org/assignments/link-relations/link-relations.xhtml#link-relations-1) 16 | - a `URI relation` - like https://api.w.org/term 17 | - or a `Compact URI relation` - like `wp:term` 18 | 19 | Compact URI relations can be normalized to full URI relations to ensure full compatibility if required. This is similar to HTML `` tags, or `` links. 20 | 21 | The links are an object containing a `href` property with an absolute URL to the resource, as well as other optional properties. These include content types, disambiguation information, and data on actions that can be taken with the link. 22 | 23 | For collection responses (those that return a list of objects rather than a top-level object), each item contains links, and the top-level response includes links via the `Link` header instead. 24 | 25 | [info] 26 | If your client library does not allow accessing headers, you can use the _envelope parameter to include the headers as body data instead. 27 | [/info] 28 | 29 | 30 | ### Example Response 31 | 32 | A typical single post request (`/wp/v2/posts/42`): 33 | 34 | ```js 35 | { 36 | "id": 42, 37 | "_links": { 38 | "collection": [ 39 | { 40 | "href": "https://example.com/wp-json/wp/v2/posts" 41 | } 42 | ], 43 | "author": [ 44 | { 45 | "href": "https://example.com/wp-json/wp/v2/users/1", 46 | "embeddable": true 47 | } 48 | ] 49 | } 50 | } 51 | ``` 52 | 53 | 54 | ## Embedding 55 | 56 | Optionally, some linked resources may be included in the response to reduce the number of HTTP requests required. These resources are "embedded" into the main response. 57 | 58 | Embedding is triggered by setting the [`_embed` query parameter](https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/#_embed) on the request. This will then include embedded resources under the `_embedded` key adjacent to the `_links` key. The layout of this object mirrors the `_links` object, but includes the embedded resource in place of the link properties. 59 | 60 | Only links with the `embeddable` flag set to `true` can be embedded, and `_embed` will cause all embeddable links to be embedded. Only relations containing embedded responses are included in `_embedded`, however relations with mixed embeddable and unembeddable links will contain dummy responses for the unembeddable links to ensure numeric indexes match those in `_links`. 61 | 62 | When embedding a collection response, for instance `/wp/v2/posts?author=1`, the embedded collection will have the default pagination limits applied. 63 | 64 | ### Example Response 65 | 66 | ```js 67 | { 68 | "id": 42, 69 | "_links": { 70 | "collection": [ 71 | { 72 | "href": "https://example.com/wp-json/wp/v2/posts" 73 | } 74 | ], 75 | "author": [ 76 | { 77 | "href": "https://example.com/wp-json/wp/v2/users/1", 78 | "embeddable": true 79 | } 80 | ] 81 | }, 82 | "_embedded": { 83 | "author": { 84 | "id": 1, 85 | "name": "admin", 86 | "description": "Site administrator" 87 | } 88 | } 89 | } 90 | ``` -------------------------------------------------------------------------------- /glossary.md: -------------------------------------------------------------------------------- 1 | # Glossary 2 | 3 | New to REST APIs? Get up to speed with phrases used throughout our documentation. 4 | 5 | 6 |

Controller

7 | 8 | [Model-View-Controller](http://en.wikipedia.org/wiki/Model-view-controller) is a standard pattern in software development. If you aren't already familiar with it, you should do a bit of reading to get up to speed. 9 | 10 | Within WP-API, we've adopted the controller concept to have a standard pattern for the classes representing our resource endpoints. All resource endpoints extend `WP_REST_Controller` to ensure they implement common methods. 11 | 12 | 13 |

HEAD, GET, POST, PUT, and DELETE Requests

14 | 15 | These "HTTP verbs" represent the *type* of action a HTTP client might perform against a resource. For instance, `GET` requests are used to fetch a Post's data, whereas `DELETE` requests are used to delete a Post. They're collectively called "HTTP verbs" because they're standardized across the web. 16 | 17 | If you're familiar with WordPress functions, a `GET` request is the equivalent of `wp_remote_get()`, and a `POST` request is the same as `wp_remote_post()`. 18 | 19 | 20 |

HTTP Client

21 | 22 | The phrase "HTTP Client" refers to the tool you use to interact with WP-API. You might use [Postman](https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en) (Chrome) or [REST Easy](https://github.com/nathan-osman/REST-Easy) (Firefox) to test requests in your browser, or [httpie](https://github.com/jakubroztocil/httpie) to test requests at the commandline. 23 | 24 | WordPress itself provides a HTTP Client in the [`WP_HTTP` class](https://developer.wordpress.org/plugins/http-api/) and related functions (e.g. `wp_remote_get()`). This can be used to access one WordPress site from another. 25 | 26 | 27 |

Resource

28 | 29 | A "Resource" is a *discrete entity* within WordPress. You may know these resources already as Posts, Pages, Comments, Users, Terms, and so on. WP-API permits HTTP clients to perform CRUD operations against resources (CRUD stands for Create, Read, Update, and Delete). 30 | 31 | Pragmatically, here's how you'd typically interact with WP-API resources: 32 | 33 | * `GET /wp-json/wp/v2/posts` to get a collection of Posts. This is roughly equivalent to using `WP_Query`. 34 | * `GET /wp-json/wp/v2/posts/123` to get a single Post with ID 123. This is roughly equivalent to using `get_post()`. 35 | * `POST /wp-json/wp/v2/posts` to create a new Post. This is roughly equivalent to using `wp_insert_post()`. 36 | * `DELETE /wp-json/wp/v2/posts/123` to delete Post with ID 123. This is roughly equivalent to `wp_delete_post()`. 37 | 38 | 39 |

Routes / Endpoints

40 | 41 | Endpoints are functions available through the API. This can be things like retrieving the API index, updating a post, or deleting a comment. Endpoints perform a specific function, taking some number of parameters and return data to the client. 42 | 43 | A route is the "name" you use to access endpoints, used in the URL. A route can have multiple endpoints associated with it, and which is used depends on the HTTP verb. 44 | 45 | For example, with the URL `http://example.com/wp-json/wp/v2/posts/123`: 46 | 47 | * The "route" is `wp/v2/posts/123` - The route doesn't include `wp-json` because `wp-json` is the base path for the API itself. 48 | * This route has 3 endpoints: 49 | * `GET` triggers a `get_item` method, returning the post data to the client. 50 | * `PUT` triggers an `update_item` method, taking the data to update, and returning the updated post data. 51 | * `DELETE` triggers a `delete_item` method, returning the now-deleted post data to the client. 52 | 53 | **Note:** On sites without pretty permalinks, the route is instead added to the URL as the `rest_route` parameter. For the above example, the full URL would then be `http://example.com/?rest_route=wp/v2/posts/123` 54 | 55 | 56 |

Schema

57 | 58 | A "schema" is a representation of the format for WP-API's response data. For instance, the Post schema communicates that a request to get a Post will return `id`, `title`, `content`, `author`, and other fields. Our schemas also indicate the type each field is, provide a human-readable description, and show which contexts the field will be returned in. 59 | -------------------------------------------------------------------------------- /reference/widget-types.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Widget Types 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a widget type record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 45 | 46 | 47 | 50 | 57 | 58 | 59 | 62 | 69 | 70 |
13 | id 14 | 16 |

Unique slug identifying the widget type.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context: embed, view, edit

21 |
25 | name 26 | 28 |

Human-readable name identifying the widget type.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context: embed, view, edit

33 |
37 | description 38 | 40 |

Description of the widget.

41 |

42 | JSON data type: string

43 |

Context: view, edit, embed

44 |
48 | is_multi 49 | 51 |

Whether the widget supports multiple instances

52 |

53 | JSON data type: boolean

54 |

Read only

55 |

Context: view, edit, embed

56 |
60 | classname 61 | 63 |

Class name

64 |

65 | JSON data type: string

66 |

Read only

67 |

Context: embed, view, edit

68 |
71 | 72 |
73 |
74 | 75 |
76 |
77 |

Retrieve a Widget Type

78 | 79 |

Definition & Example Request

80 | 81 | GET /wp/v2/widget-types 82 | 83 |

Query this endpoint to retrieve a specific widget type record.

84 | 85 | $ curl https://example.com/wp-json/wp/v2/widget-types 86 |
87 |
88 |

Arguments

89 | 90 | 91 | 94 | 101 | 102 |
92 | context
93 |
95 |

Scope under which the request is made; determines fields present in response.

96 |

97 | Default: view 98 |

99 |

One of: view, embed, edit

100 |
103 | 104 |
105 |
106 |
107 |
108 |

Retrieve a Widget Type

109 | 110 |

Definition & Example Request

111 | 112 | GET /wp/v2/widget-types/<id> 113 | 114 |

Query this endpoint to retrieve a specific widget type record.

115 | 116 | $ curl https://example.com/wp-json/wp/v2/widget-types/<id> 117 |
118 |
119 |

Arguments

120 | 121 | 122 | 125 | 128 | 129 | 130 | 133 | 140 | 141 |
123 | id
124 |
126 |

The widget type id.

127 |
131 | context
132 |
134 |

Scope under which the request is made; determines fields present in response.

135 |

136 | Default: view 137 |

138 |

One of: view, embed, edit

139 |
142 | 143 |
144 |
145 |
146 | -------------------------------------------------------------------------------- /using-the-rest-api/authentication.md: -------------------------------------------------------------------------------- 1 | # Authentication 2 | 3 | ## Cookie Authentication 4 | 5 | Cookie authentication is the standard authentication method included with WordPress. When you log in to your dashboard, this sets up the cookies correctly for you, so plugin and theme developers need only to have a logged-in user. 6 | 7 | However, the REST API includes a technique called [nonces](https://developer.wordpress.org/apis/security/nonces/) to avoid [CSRF](http://en.wikipedia.org/wiki/Cross-site_request_forgery) issues. This prevents other sites from forcing you to perform actions without explicitly intending to do so. This requires slightly special handling for the API. 8 | 9 | For developers using the built-in Javascript API, this is handled automatically for you. This is the recommended way to use the API for plugins and themes. Custom data models can extend `wp.api.models.Base` to ensure this is sent correctly for any custom requests. 10 | 11 | For developers making manual Ajax requests, the nonce will need to be passed with each request. The API uses nonces with the action set to `wp_rest`. These can then be passed to the API via the `_wpnonce` data parameter (either POST data or in the query for GET requests), or via the `X-WP-Nonce` header. If no nonce is provided the API will set the current user to 0, turning the request into an **unauthenticated request**, even if you're logged into WordPress. 12 | 13 | Note: Until recently, most software had spotty support for `DELETE` requests. For instance, PHP doesn't transform the request body of a `DELETE` request into a super global. As such, supplying the nonce as a header is the most reliable approach. 14 | 15 | It is important to keep in mind that this authentication method relies on WordPress cookies. As a result this method is only applicable when the REST API is used inside of WordPress and the current user is logged in. In addition, the current user must have the appropriate capability to perform the action being performed. 16 | 17 | As an example, this is how the built-in Javascript client creates the nonce: 18 | 19 | ```php 20 | esc_url_raw( rest_url() ), 23 | 'nonce' => wp_create_nonce( 'wp_rest' ) 24 | ) ); 25 | ``` 26 | 27 | This is then used in the base model: 28 | 29 | ```js 30 | options.beforeSend = function(xhr) { 31 | xhr.setRequestHeader('X-WP-Nonce', wpApiSettings.nonce); 32 | 33 | if (beforeSend) { 34 | return beforeSend.apply(this, arguments); 35 | } 36 | }; 37 | ``` 38 | 39 | Here is an example of editing the title of a post, using jQuery AJAX: 40 | 41 | ```js 42 | $.ajax( { 43 | url: wpApiSettings.root + 'wp/v2/posts/1', 44 | method: 'POST', 45 | beforeSend: function ( xhr ) { 46 | xhr.setRequestHeader( 'X-WP-Nonce', wpApiSettings.nonce ); 47 | }, 48 | data:{ 49 | 'title' : 'Hello Moon' 50 | } 51 | } ).done( function ( response ) { 52 | console.log( response ); 53 | } ); 54 | ``` 55 | 56 | Note that you do not need to verify that the nonce is valid inside your custom end point. This is automatically done for you in `rest_cookie_check_errors()`. 57 | 58 | ## Basic Authentication with Application Passwords 59 | 60 | As of 5.6, WordPress has shipped with [Application Passwords](https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/), which can be generated from an Edit User page (wp-admin -> Users -> Edit User). 61 | 62 | The credentials can be passed along to REST API requests served over https:// using [Basic Auth](https://ec.haxx.se/libcurl-http/auth.html#basic) / [RFC 7617](https://tools.ietf.org/html/rfc7617) — [here’s the documentation for how to use it with cURL](https://ec.haxx.se/http/auth.html). 63 | 64 | For a simple command-line script example, just swap out USERNAME, PASSWORD, and HOSTNAME in this with their respective values: 65 | 66 | ``` 67 | curl --user "USERNAME:PASSWORD" https://HOSTNAME/wp-json/wp/v2/users?context=edit 68 | ``` 69 | 70 | ## Authentication Plugins 71 | 72 | Plugins may be added to support alternative modes of authentication that will work from remote applications. Some example plugins are [OAuth 1.0a Server](https://wordpress.org/plugins/rest-api-oauth1/) and [JSON Web Tokens](https://wordpress.org/plugins/jwt-authentication-for-wp-rest-api/). 73 | 74 | [info] 75 | 76 | There's also a [Basic Authentication](https://github.com/WP-API/Basic-Auth) plugin. 77 | 78 | Note that this plugin requires sending your username and password with every request, and should only be used for development and testing i.e. not in a production environment. Using Application Passwords (see above) is preferred. 79 | 80 | [/info] 81 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | # REST API Handbook 2 | 3 | The WordPress REST API provides an interface for applications to interact with your WordPress site by sending and receiving data as [JSON](https://en.wikipedia.org/wiki/JSON) (JavaScript Object Notation) objects. It is the foundation of the [WordPress Block Editor](https://developer.wordpress.org/block-editor/), and can likewise enable your theme, plugin or custom application to present new, powerful interfaces for managing and publishing your site content. 4 | 5 | Using the WordPress REST API you can create a plugin to provide an entirely new admin experience for WordPress, build a brand new interactive front-end experience, or bring your WordPress content into completely separate applications. 6 | 7 | The REST API is a developer-oriented feature of WordPress. It provides data access to the content of your site, and implements the same authentication restrictions -- content that is public on your site is generally publicly accessible via the REST API, while private content, password-protected content, internal users, custom post types, and metadata is only available with authentication or if you specifically set it to be so. If you are not a developer, the most important thing to understand about the API is that it enables the block editor and modern plugin interfaces without compromising the security or privacy of your site. 8 | 9 | ## What Is A REST API? 10 | 11 | An API is an Application Programming Interface. REST, standing for "REpresentational State Transfer," is a set of concepts for modeling and accessing your application's data as interrelated objects and collections. The WordPress REST API provides REST endpoints (URLs) representing the posts, pages, taxonomies, and other built-in WordPress data types. Your application can send and receive JSON data to these endpoints to query, modify and create content on your site. JSON is an open standard data format that is lightweight and human-readable, and looks like Objects do in JavaScript. When you request content from or send content to the API, the response will also be returned in JSON. Because JSON is widely supported in many programming languages, developers can build WordPress applications in client-side JavaScript (like the block editor), as mobile apps, or as desktop or command line tools. 12 | 13 | [info]The REST API is just one of many APIs provided by WordPress. You can find the [documentation on these additional APIs here](https://codex.wordpress.org/WordPress_APIs).[/info] 14 | 15 | ## Using the WordPress REST API 16 | 17 | WordPress already provides a rich set of tools and interfaces for building sites, and you should not feel pressured to use the REST API if your site is already working the way you expect. You do not need to use the REST API to build a WordPress theme or plugin. 18 | 19 | However, if you do wish to write your theme, plugin, or external application as a client-side JavaScript application, or a standalone program in a language other than PHP, then your application will need a structured way to access content within your WordPress site. Any programming language which can make HTTP requests and interpret JSON can use the REST API to interact with WordPress, from PHP, Node.js, Go, and Java, to Swift, Kotlin, and beyond. 20 | 21 | Even if you're using vanilla JavaScript or jQuery within a theme or plugin the REST API provides a more predictable and structured way to interact with your site's content than [`admin-ajax`](https://codex.wordpress.org/AJAX_in_Plugins), enabling you to spend less time accessing the data you need and more time creating better user experiences. 22 | 23 | If you want a structured, extensible, and simple way to get data in and out of WordPress, you probably want to use the REST API. 24 | 25 | For all of its simplicity the REST API can feel quite complex at first, so in this handbook we will attempt to break it down into smaller components to explain each part of the full puzzle. 26 | 27 | ## Next Steps 28 | 29 | Familiarize yourself with the [key technical concepts](https://developer.wordpress.org/rest-api/key-concepts/) behind how the REST API functions. 30 | 31 | Learn more about how to interact with API resources and query for specific data in the [Using the REST API](https://developer.wordpress.org/rest-api/using-the-rest-api/) section. 32 | 33 | Once you're comfortable with the default workings of the default routes and methods, discover how to add new data to the API or enhance and manipulate existing response objects in the [Extending the REST API](https://developer.wordpress.org/rest-api/extending-the-rest-api/) section. 34 | 35 | For a comprehensive overview of the resources and routes available by default, review the [API reference](https://developer.wordpress.org/rest-api/reference/). 36 | -------------------------------------------------------------------------------- /bin/regenerate.php: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env php 2 | body, true ); 49 | 50 | foreach ( $parsed_data['routes'] as $key => $route ) { 51 | if ( ! isset( $route['schema'] ) ) { 52 | continue; 53 | } 54 | 55 | # make a readable route name from the route regex 56 | $route_nicename = preg_replace( '/\(\?P<(\w+?)>.*?\)/', '<\1>', $key ); 57 | $route['nicename'] = $route_nicename; 58 | 59 | # group the objects by unique schema titles [ post => ..., term => ..., etc ] 60 | $title = $route['schema']['title']; 61 | 62 | # pluralise, super-dodgy. 63 | if ( substr( $title, -1 ) === 's' ) { 64 | $plural = $title; 65 | } else { 66 | $plural = substr( $title, -1 ) === 'y' ? substr( $title, 0, -1 ) . 'ies' : $title . 's'; 67 | } 68 | $key = $plural; 69 | 70 | # overrides 71 | switch ( $title ) { 72 | case 'attachment': 73 | $key = 'media'; 74 | $title = 'Media Item'; 75 | $plural = 'media'; 76 | break; 77 | 78 | case 'rendered-block': 79 | $key = 'rendered-blocks'; 80 | $title = 'Rendered Block'; 81 | $plural = 'Rendered Blocks'; 82 | break; 83 | 84 | case 'settings': 85 | $key = 'settings'; 86 | $title = 'Site Setting'; 87 | $plural = 'Site Settings'; 88 | break; 89 | 90 | case 'status': 91 | $plural = 'statuses'; 92 | $key = 'post-statuses'; 93 | break; 94 | 95 | case 'type': 96 | $key = 'post-types'; 97 | break; 98 | 99 | case 'wp_block': 100 | $key = 'blocks'; 101 | $title = 'Editor Block'; 102 | $plural = 'Editor Blocks'; 103 | break; 104 | 105 | case 'wp_block-revision': 106 | $key = 'block-revisions'; 107 | $title = 'Block Revision'; 108 | $plural = 'Block Revisions'; 109 | break; 110 | 111 | default: 112 | // Fallback title cleaning logic, to remove kebab-casing, etcetera. 113 | $title = cleanup_name( $title ); 114 | $plural = cleanup_name( $plural ); 115 | } 116 | 117 | if ( ! isset( $objects[ $key ] ) ) { 118 | $objects[ $key ] = [ 119 | 'name' => $title, 120 | 'plural' => $plural, 121 | 'routes' => [ $route_nicename => update_route( $route ) ], 122 | 'schema' => $route['schema'], 123 | ]; 124 | } else { 125 | $objects[ $key ]['routes'][ $route_nicename ] = update_route( $route ); 126 | } 127 | } 128 | 129 | return $objects; 130 | } 131 | 132 | function add_terms_schema() { 133 | $response = Requests::options( SITE_URL . '?rest_route=/wp/v2/terms/category' ); 134 | $file = fopen( '_data/terms.json', 'w' ); 135 | $parsed_data = json_decode( $response->body ); 136 | 137 | # puts data 138 | fwrite( $file, json_encode( $parsed_data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES ) ); 139 | fclose( $file ); 140 | } 141 | 142 | function twig() { 143 | static $twig; 144 | if ( ! empty( $twig ) ) { 145 | return $twig; 146 | } 147 | 148 | $loader = new Twig\Loader\FilesystemLoader( __DIR__ . '/templates' ); 149 | 150 | $twig = new Twig\Environment( $loader, [ 151 | 'cache' => false, 152 | ] ); 153 | return $twig; 154 | } 155 | 156 | function generate_reference() { 157 | $template = twig()->load( 'endpoint.md' ); 158 | 159 | $schemas = add_simple_schemas(); 160 | $rendered = []; 161 | foreach ( $schemas as $key => $value ) { 162 | $rendered[ $key ] = $template->render( $value ); 163 | file_put_contents( dirname( __DIR__ ) . '/reference/' . $key . '.md', $rendered[ $key ] ); 164 | } 165 | } 166 | 167 | generate_reference(); 168 | -------------------------------------------------------------------------------- /reference/search-results.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Search Results 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a search result record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 48 | 49 | 50 | 53 | 61 | 62 | 63 | 66 | 74 | 75 |
13 | id 14 | 16 |

Unique identifier for the object.

17 |

18 | JSON data type: integer or string

19 |

Read only

20 |

Context: view, embed

21 |
25 | title 26 | 28 |

The title for the object.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context: view, embed

33 |
37 | url 38 | 40 |

URL to the object.

41 |

42 | JSON data type: string, 43 | Format: uri 44 |

45 |

Read only

46 |

Context: view, embed

47 |
51 | type 52 | 54 |

Object type.

55 |

56 | JSON data type: string

57 |

Read only

58 |

Context: view, embed

59 |

One of: post, term, post-format

60 |
64 | subtype 65 | 67 |

Object subtype.

68 |

69 | JSON data type: string

70 |

Read only

71 |

Context: view, embed

72 |

One of: post, page, category, post_tag

73 |
76 | 77 |
78 |
79 | 80 |
81 |
82 |

List Search Results

83 |

Query this endpoint to retrieve a collection of search results. The response you receive can be controlled and filtered using the URL query parameters below.

84 | 85 |

Definition

86 | 87 | GET /wp/v2/search 88 | 89 |

Example Request

90 | 91 | $ curl https://example.com/wp-json/wp/v2/search 92 |
93 |
94 |

Arguments

95 | 96 | 97 | 100 | 107 | 108 | 109 | 112 | 118 | 119 | 120 | 123 | 129 | 130 | 131 | 134 | 137 | 138 | 139 | 142 | 149 | 150 | 151 | 154 | 160 | 161 | 162 | 165 | 168 | 169 | 170 | 173 | 176 | 177 |
98 | context
99 |
101 |

Scope under which the request is made; determines fields present in response.

102 |

103 | Default: view 104 |

105 |

One of: view, embed

106 |
110 | page
111 |
113 |

Current page of the collection.

114 |

115 | Default: 1 116 |

117 |
121 | per_page
122 |
124 |

Maximum number of items to be returned in result set.

125 |

126 | Default: 10 127 |

128 |
132 | search
133 |
135 |

Limit results to those matching a string.

136 |
140 | type
141 |
143 |

Limit results to items of an object type.

144 |

145 | Default: post 146 |

147 |

One of: post, term, post-format

148 |
152 | subtype
153 |
155 |

Limit results to items of one or more object subtypes.

156 |

157 | Default: any 158 |

159 |
163 | exclude
164 |
166 |

Ensure result set excludes specific IDs.

167 |
171 | include
172 |
174 |

Limit result set to specific IDs.

175 |
178 | 179 |
180 |
181 |
182 | -------------------------------------------------------------------------------- /reference/wp-site-health-tests.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Wp Site Health Tests 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a wp site health test record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 47 | 48 | 49 | 52 | 59 | 60 | 61 | 64 | 71 | 72 | 73 | 76 | 83 | 84 |
13 | test 14 | 16 |

The name of the test being run.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context:

21 |
25 | label 26 | 28 |

A label describing the test.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context:

33 |
37 | status 38 | 40 |

The status of the test.

41 |

42 | JSON data type: string

43 |

Read only

44 |

Context:

45 |

One of: good, recommended, critical

46 |
50 | badge 51 | 53 |

The category this test is grouped in.

54 |

55 | JSON data type: object

56 |

Read only

57 |

Context:

58 |
62 | description 63 | 65 |

A more descriptive explanation of what the test looks for, and why it is important for the user.

66 |

67 | JSON data type: string

68 |

Read only

69 |

Context:

70 |
74 | actions 75 | 77 |

HTML containing an action to direct the user to where they can resolve the issue.

78 |

79 | JSON data type: string

80 |

Read only

81 |

Context:

82 |
85 | 86 |
87 |
88 | 89 |
90 |
91 |

Retrieve a Wp Site Health Test

92 | 93 |

Definition & Example Request

94 | 95 | GET /wp-site-health/v1/tests/background-updates 96 | 97 |

Query this endpoint to retrieve a specific wp site health test record.

98 | 99 | $ curl https://example.com/wp-json/wp-site-health/v1/tests/background-updates 100 |
101 |
102 |

There are no arguments for this endpoint.

103 | 104 |
105 |
106 |
107 |
108 |

Retrieve a Wp Site Health Test

109 | 110 |

Definition & Example Request

111 | 112 | GET /wp-site-health/v1/tests/loopback-requests 113 | 114 |

Query this endpoint to retrieve a specific wp site health test record.

115 | 116 | $ curl https://example.com/wp-json/wp-site-health/v1/tests/loopback-requests 117 |
118 |
119 |

There are no arguments for this endpoint.

120 | 121 |
122 |
123 |
124 |
125 |

Retrieve a Wp Site Health Test

126 | 127 |

Definition & Example Request

128 | 129 | GET /wp-site-health/v1/tests/https-status 130 | 131 |

Query this endpoint to retrieve a specific wp site health test record.

132 | 133 | $ curl https://example.com/wp-json/wp-site-health/v1/tests/https-status 134 |
135 |
136 |

There are no arguments for this endpoint.

137 | 138 |
139 |
140 |
141 |
142 |

Retrieve a Wp Site Health Test

143 | 144 |

Definition & Example Request

145 | 146 | GET /wp-site-health/v1/tests/dotorg-communication 147 | 148 |

Query this endpoint to retrieve a specific wp site health test record.

149 | 150 | $ curl https://example.com/wp-json/wp-site-health/v1/tests/dotorg-communication 151 |
152 |
153 |

There are no arguments for this endpoint.

154 | 155 |
156 |
157 |
158 |
159 |

Retrieve a Wp Site Health Test

160 | 161 |

Definition & Example Request

162 | 163 | GET /wp-site-health/v1/tests/authorization-header 164 | 165 |

Query this endpoint to retrieve a specific wp site health test record.

166 | 167 | $ curl https://example.com/wp-json/wp-site-health/v1/tests/authorization-header 168 |
169 |
170 |

There are no arguments for this endpoint.

171 | 172 |
173 |
174 |
175 | -------------------------------------------------------------------------------- /reference/post-statuses.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Statuses 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a status record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 46 | 47 | 48 | 51 | 58 | 59 | 60 | 63 | 70 | 71 | 72 | 75 | 82 | 83 | 84 | 87 | 94 | 95 | 96 | 99 | 106 | 107 |
13 | name 14 | 16 |

The title for the status.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context: embed, view, edit

21 |
25 | private 26 | 28 |

Whether posts with this status should be private.

29 |

30 | JSON data type: boolean

31 |

Read only

32 |

Context: edit

33 |
37 | protected 38 | 40 |

Whether posts with this status should be protected.

41 |

42 | JSON data type: boolean

43 |

Read only

44 |

Context: edit

45 |
49 | public 50 | 52 |

Whether posts of this status should be shown in the front end of the site.

53 |

54 | JSON data type: boolean

55 |

Read only

56 |

Context: view, edit

57 |
61 | queryable 62 | 64 |

Whether posts with this status should be publicly-queryable.

65 |

66 | JSON data type: boolean

67 |

Read only

68 |

Context: view, edit

69 |
73 | show_in_list 74 | 76 |

Whether to include posts in the edit listing for their post type.

77 |

78 | JSON data type: boolean

79 |

Read only

80 |

Context: edit

81 |
85 | slug 86 | 88 |

An alphanumeric identifier for the status.

89 |

90 | JSON data type: string

91 |

Read only

92 |

Context: embed, view, edit

93 |
97 | date_floating 98 | 100 |

Whether posts of this status may have floating published dates.

101 |

102 | JSON data type: boolean

103 |

Read only

104 |

Context: view, edit

105 |
108 | 109 |
110 |
111 | 112 |
113 |
114 |

Retrieve a Status

115 | 116 |

Definition & Example Request

117 | 118 | GET /wp/v2/statuses 119 | 120 |

Query this endpoint to retrieve a specific status record.

121 | 122 | $ curl https://example.com/wp-json/wp/v2/statuses 123 |
124 |
125 |

Arguments

126 | 127 | 128 | 131 | 138 | 139 |
129 | context
130 |
132 |

Scope under which the request is made; determines fields present in response.

133 |

134 | Default: view 135 |

136 |

One of: view, embed, edit

137 |
140 | 141 |
142 |
143 |
144 |
145 |

Retrieve a Status

146 | 147 |

Definition & Example Request

148 | 149 | GET /wp/v2/statuses/<status> 150 | 151 |

Query this endpoint to retrieve a specific status record.

152 | 153 | $ curl https://example.com/wp-json/wp/v2/statuses/<status> 154 |
155 |
156 |

Arguments

157 | 158 | 159 | 162 | 165 | 166 | 167 | 170 | 177 | 178 |
160 | status
161 |
163 |

An alphanumeric identifier for the status.

164 |
168 | context
169 |
171 |

Scope under which the request is made; determines fields present in response.

172 |

173 | Default: view 174 |

175 |

One of: view, embed, edit

176 |
179 | 180 |
181 |
182 |
183 | -------------------------------------------------------------------------------- /reference.md: -------------------------------------------------------------------------------- 1 | # Reference 2 | 3 | The WordPress REST API is organized around [REST](http://en.wikipedia.org/wiki/Representational_state_transfer), and is designed to have predictable, resource-oriented URLs and to use HTTP response codes to indicate API errors. The API uses built-in HTTP features, like HTTP authentication and HTTP verbs, which can be understood by off-the-shelf HTTP clients, and supports cross-origin resource sharing to allow you to interact securely with the API from a client-side web application. 4 | 5 | The REST API uses JSON exclusively as the request and response format, including error responses. While the REST API does not completely conform to the [HAL standard](http://stateless.co/hal_specification.html), it does implement HAL's `._links` and `._embedded` properties for linking API resources, and is fully discoverable via hyperlinks in the responses. 6 | 7 | The REST API provides public data accessible to any client anonymously, as well as private data only available after [authentication](https://developer.wordpress.org/rest-api/authentication/). Once authenticated the REST API supports most content management actions, allowing you to build alternative dashboards for a site, enhance your plugins with more responsive management tools, or build complex single-page applications. 8 | 9 | This API reference provides information on the specific endpoints available through the API, their parameters, and their response data format. 10 | 11 | ## REST API Developer Endpoint Reference 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 |
ResourceBase Route
Posts/wp/v2/posts
Post Revisions/wp/v2/posts/<id>/revisions
Categories/wp/v2/categories
Tags/wp/v2/tags
Pages/wp/v2/pages
Page Revisions/wp/v2/pages/<id>/revisions
Comments/wp/v2/comments
Taxonomies/wp/v2/taxonomies
Media/wp/v2/media
Users/wp/v2/users
Post Types/wp/v2/types
Post Statuses/wp/v2/statuses
Settings/wp/v2/settings
Themes/wp/v2/themes
Search/wp/v2/search
Block Types/wp/v2/block-types
Blocks/wp/v2/blocks
Block Revisions/wp/v2/blocks/<id>/autosaves/
Block Renderer/wp/v2/block-renderer
Block Directory Items/wp/v2/block-directory/search
Plugins/wp/v2/plugins
103 | 104 | ## A Distributed API 105 | 106 | Unlike many other REST APIs, the WordPress REST API is distributed and available individually on each site that supports it. This means there is no singular API root or base to contact; instead, we have [a discovery process](https://developer.wordpress.org/rest-api/discovery/) that allows interacting with sites without prior contact. The API also exposes self-documentation at the index endpoint, or via an `OPTIONS` request to any endpoint, allowing human- or machine-discovery of endpoint capabilities. 107 | -------------------------------------------------------------------------------- /reference/block-patterns.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Block Patterns 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a block pattern record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 46 | 47 | 48 | 51 | 58 | 59 | 60 | 63 | 70 | 71 | 72 | 75 | 82 | 83 | 84 | 87 | 94 | 95 | 96 | 99 | 106 | 107 | 108 | 111 | 118 | 119 | 120 | 123 | 130 | 131 | 132 | 135 | 142 | 143 | 144 | 147 | 155 | 156 |
13 | name 14 | 16 |

The pattern name.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context: view, edit, embed

21 |
25 | title 26 | 28 |

The pattern title, in human readable format.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context: view, edit, embed

33 |
37 | content 38 | 40 |

The pattern content.

41 |

42 | JSON data type: string

43 |

Read only

44 |

Context: view, edit, embed

45 |
49 | description 50 | 52 |

The pattern detailed description.

53 |

54 | JSON data type: string

55 |

Read only

56 |

Context: view, edit, embed

57 |
61 | viewport_width 62 | 64 |

The pattern viewport width for inserter preview.

65 |

66 | JSON data type: number

67 |

Read only

68 |

Context: view, edit, embed

69 |
73 | inserter 74 | 76 |

Determines whether the pattern is visible in inserter.

77 |

78 | JSON data type: boolean

79 |

Read only

80 |

Context: view, edit, embed

81 |
85 | categories 86 | 88 |

The pattern category slugs.

89 |

90 | JSON data type: array

91 |

Read only

92 |

Context: view, edit, embed

93 |
97 | keywords 98 | 100 |

The pattern keywords.

101 |

102 | JSON data type: array

103 |

Read only

104 |

Context: view, edit, embed

105 |
109 | block_types 110 | 112 |

Block types that the pattern is intended to be used with.

113 |

114 | JSON data type: array

115 |

Read only

116 |

Context: view, edit, embed

117 |
121 | post_types 122 | 124 |

An array of post types that the pattern is restricted to be used with.

125 |

126 | JSON data type: array

127 |

Read only

128 |

Context: view, edit, embed

129 |
133 | template_types 134 | 136 |

An array of template types where the pattern fits.

137 |

138 | JSON data type: array

139 |

Read only

140 |

Context: view, edit, embed

141 |
145 | source 146 | 148 |

Where the pattern comes from e.g. core

149 |

150 | JSON data type: string

151 |

Read only

152 |

Context: view, edit, embed

153 |

One of: core, plugin, theme, pattern-directory/core, pattern-directory/theme, pattern-directory/featured

154 |
157 | 158 |
159 |
160 | 161 |
162 |
163 |

Retrieve a Block Pattern

164 | 165 |

Definition & Example Request

166 | 167 | GET /wp/v2/block-patterns/patterns 168 | 169 |

Query this endpoint to retrieve a specific block pattern record.

170 | 171 | $ curl https://example.com/wp-json/wp/v2/block-patterns/patterns 172 |
173 |
174 |

There are no arguments for this endpoint.

175 | 176 |
177 |
178 |
179 | -------------------------------------------------------------------------------- /reference/wp_global_styles-revisions.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Global_Styles Revisions 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a global_styles revision record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 21 | 22 | 23 | 26 | 34 | 35 | 36 | 39 | 47 | 48 | 49 | 52 | 58 | 59 | 60 | 63 | 71 | 72 | 73 | 76 | 84 | 85 | 86 | 89 | 95 | 96 | 97 | 100 | 106 | 107 | 108 | 111 | 117 | 118 |
13 | author 14 | 16 |

The ID for the author of the revision.

17 |

18 | JSON data type: integer

19 |

Context: view, edit, embed

20 |
24 | date 25 | 27 |

The date the revision was published, in the site's timezone.

28 |

29 | JSON data type: string, 30 | Format: datetime (details) 31 |

32 |

Context: view, edit, embed

33 |
37 | date_gmt 38 | 40 |

The date the revision was published, as GMT.

41 |

42 | JSON data type: string, 43 | Format: datetime (details) 44 |

45 |

Context: view, edit

46 |
50 | id 51 | 53 |

Unique identifier for the revision.

54 |

55 | JSON data type: integer

56 |

Context: view, edit, embed

57 |
61 | modified 62 | 64 |

The date the revision was last modified, in the site's timezone.

65 |

66 | JSON data type: string, 67 | Format: datetime (details) 68 |

69 |

Context: view, edit

70 |
74 | modified_gmt 75 | 77 |

The date the revision was last modified, as GMT.

78 |

79 | JSON data type: string, 80 | Format: datetime (details) 81 |

82 |

Context: view, edit

83 |
87 | parent 88 | 90 |

The ID for the parent of the revision.

91 |

92 | JSON data type: integer

93 |

Context: view, edit, embed

94 |
98 | styles 99 | 101 |

Global styles.

102 |

103 | JSON data type: object

104 |

Context: view, edit

105 |
109 | settings 110 | 112 |

Global settings.

113 |

114 | JSON data type: object

115 |

Context: view, edit

116 |
119 | 120 |
121 |
122 | 123 |
124 |
125 |

List Global_Styles Revisions

126 |

Query this endpoint to retrieve a collection of global_styles revisions. The response you receive can be controlled and filtered using the URL query parameters below.

127 | 128 |

Definition

129 | 130 | GET /wp/v2/global-styles/<parent>/revisions 131 | 132 |

Example Request

133 | 134 | $ curl https://example.com/wp-json/wp/v2/global-styles/<parent>/revisions 135 |
136 |
137 |

Arguments

138 | 139 | 140 | 143 | 146 | 147 | 148 | 151 | 158 | 159 | 160 | 163 | 169 | 170 | 171 | 174 | 177 | 178 | 179 | 182 | 185 | 186 |
141 | parent
142 |
144 |

The ID for the parent of the revision.

145 |
149 | context
150 |
152 |

Scope under which the request is made; determines fields present in response.

153 |

154 | Default: view 155 |

156 |

One of: view, embed, edit

157 |
161 | page
162 |
164 |

Current page of the collection.

165 |

166 | Default: 1 167 |

168 |
172 | per_page
173 |
175 |

Maximum number of items to be returned in result set.

176 |
180 | offset
181 |
183 |

Offset the result set by a specific number of items.

184 |
187 | 188 |
189 |
190 |
191 | -------------------------------------------------------------------------------- /frequently-asked-questions.md: -------------------------------------------------------------------------------- 1 | # Frequently Asked Questions 2 | 3 | This page provides solutions to some common questions and problems that may arise while using the API. If your question is not explained here it may have been answered in the [WordPress support forums](https://wordpress.org/support/topic-tag/rest-api). 4 | 5 | 6 | ## Can I disable the REST API? 7 | 8 | You should not disable the REST API; doing so will break WordPress Admin functionality that depends on the API being active. However, you may use a filter to require that API consumers be authenticated, which effectively prevents anonymous external access. See below for more information. 9 | 10 | 11 | ## Require Authentication for All Requests 12 | 13 | You can require authentication for all REST API requests by adding an `is_user_logged_in` check to the [`rest_authentication_errors`](https://developer.wordpress.org/reference/hooks/rest_authentication_errors/) filter. 14 | 15 | Note: The incoming callback parameter can be either `null`, a `WP_Error`, or a boolean. The type of the parameter indicates the state of authentication: 16 | 17 | * `null`: no authentication check has yet been performed, and the hook callback may apply custom authentication logic. 18 | * boolean: indicates a previous authentication method check was performed. Boolean `true` indicates the request was successfully authenticated, and boolean `false` indicates authentication failed. 19 | * `WP_Error`: Some kind of error was encountered. 20 | 21 | ```php 22 | add_filter( 'rest_authentication_errors', function( $result ) { 23 | // If a previous authentication check was applied, 24 | // pass that result along without modification. 25 | if ( true === $result || is_wp_error( $result ) ) { 26 | return $result; 27 | } 28 | 29 | // No authentication has been performed yet. 30 | // Return an error if user is not logged in. 31 | if ( ! is_user_logged_in() ) { 32 | return new WP_Error( 33 | 'rest_not_logged_in', 34 | __( 'You are not currently logged in.' ), 35 | array( 'status' => 401 ) 36 | ); 37 | } 38 | 39 | // Our custom authentication check should have no effect 40 | // on logged-in requests 41 | return $result; 42 | }); 43 | ``` 44 | 45 | 46 | ## Can I make API requests from PHP within a plugin? 47 | 48 | Yes, you can! Use [rest_do_request](https://developer.wordpress.org/reference/functions/rest_do_request/) to make API requests internally within other WordPress code: 49 | 50 | ```php 51 | $request = new WP_REST_Request( 'GET', '/wp/v2/posts' ); 52 | // Set one or more request query parameters 53 | $request->set_param( 'per_page', 20 ); 54 | $response = rest_do_request( $request ); 55 | ``` 56 | 57 | ## How do I use the _embed parameter on internal requests? 58 | 59 | Setting the `_embed` param on the request object won't work. 60 | 61 | ```php 62 | $request = new WP_REST_Request( 'GET', '/wp/v2/posts' ); 63 | $request->set_param( '_embed', 1 ); 64 | $response = rest_do_request( $request ); 65 | ``` 66 | 67 | Instead, manually call the [`WP_REST_Server::response_to_data`](https://developer.wordpress.org/reference/classes/wp_rest_server/) function. 68 | 69 | ```php 70 | $request = new WP_REST_Request( 'GET', '/wp/v2/posts' ); 71 | $response = rest_do_request( $request ); 72 | $data = rest_get_server()->response_to_data( $response, true ); 73 | var_dump( $data['_embedded'] ); 74 | ``` 75 | 76 | ## What happened to the `?filter=` query parameter? 77 | 78 | When the REST API was merged into WordPress core the `?filter` query parameter was removed to prevent future compatibility and maintenance issues. The ability to pass arbitrary WP_Query arguments to the API using a `?filter` query parameter was necessary at the genesis of the REST API project, but most API response filtering functionality has been superseded by more robust query parameters like `?categories=`, `?slug=` and `?per_page=`. 79 | 80 | First-party query parameters should be used whenever possible. However, the [rest-filter](https://github.com/wp-api/rest-filter) plugin restores the ability to pass arbitrary `?filter` values in API request if needed. 81 | 82 | 83 | ## Query parameters are not working 84 | 85 | If you find that query parameters such as `?page=2` or `?_embed` are not having any effect, your server may not be properly configured to detect them. If you are using Nginx to serve your website, look for a `try_files` line in your site configuration. If it looks like this: 86 | 87 | ``` 88 | try_files $uri $uri/ /index.php$args; 89 | ``` 90 | 91 | change it to this: 92 | 93 | ``` 94 | try_files $uri $uri/ /index.php$is_args$args; 95 | ``` 96 | 97 | Adding `$is_args` (which will print a ? character if query arguments are found) will allow WordPress to properly receive and interpret the query parameters. 98 | 99 | 100 | ## Why is Authentication not working? 101 | 102 | If you're finding that you are sending Authentication headers but the request is not being accepted, and you are using a CGI environment, your webserver may be stripping the headers. Please try adding the appropriate configuration below to remedy this. 103 | 104 | ### Apache 105 | Add the following to a configuration file or .htaccess: 106 | ``` 107 | 108 | SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 109 | 110 | ``` 111 | 112 | ### Nginx 113 | Add the following to your server configurations fastcgi section: 114 | ``` 115 | fastcgi_pass_header Authorization; 116 | ``` 117 | 118 | ## Why is the REST API not verifying the incoming Origin header? Does this expose my site to CSRF attacks? 119 | 120 | Cross-Origin Resource Sharing (CORS) is a mechanism which allows a website to control which Origins (originating external sites) are allowed to access your site's data. CORS prevents against a particular type of attack known as Cross-Site Request Forgery, or CSRF. However, WordPress has an existing CSRF protection mechanism which uses [nonces](https://developer.wordpress.org/plugins/security/nonces/). Tightening CORS restrictions would prevent some authentication methods, so the WordPress REST API uses nonces for CSRF protection instead of CORS. 121 | 122 | Because the WordPress REST API does not verify the Origin header of incoming requests, public REST API endpoints may therefore be accessed from any site. 123 | 124 | This is an [intentional design decision](https://core.trac.wordpress.org/changeset/40600), but if you wish to prevent your site from being accessed from unknown origins you may unhook the default [`rest_send_cors_headers` function](https://developer.wordpress.org/reference/functions/rest_send_cors_headers/) from the [`rest_pre_serve_request` filter hook](https://developer.wordpress.org/reference/hooks/rest_pre_serve_request/), then hook in your own function to that same filter to specify stricter CORS headers. 125 | -------------------------------------------------------------------------------- /reference/block-directory-items.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Block Directory Items 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a block directory item record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 21 | 22 | 23 | 26 | 32 | 33 | 34 | 37 | 43 | 44 | 45 | 48 | 54 | 55 | 56 | 59 | 65 | 66 | 67 | 70 | 76 | 77 | 78 | 81 | 87 | 88 | 89 | 92 | 98 | 99 | 100 | 103 | 109 | 110 | 111 | 114 | 120 | 121 | 122 | 125 | 133 | 134 | 135 | 138 | 146 | 147 | 148 | 151 | 157 | 158 |
13 | name 14 | 16 |

The block name, in namespace/block-name format.

17 |

18 | JSON data type: string

19 |

Context: view

20 |
24 | title 25 | 27 |

The block title, in human readable format.

28 |

29 | JSON data type: string

30 |

Context: view

31 |
35 | description 36 | 38 |

A short description of the block, in human readable format.

39 |

40 | JSON data type: string

41 |

Context: view

42 |
46 | id 47 | 49 |

The block slug.

50 |

51 | JSON data type: string

52 |

Context: view

53 |
57 | rating 58 | 60 |

The star rating of the block.

61 |

62 | JSON data type: number

63 |

Context: view

64 |
68 | rating_count 69 | 71 |

The number of ratings.

72 |

73 | JSON data type: integer

74 |

Context: view

75 |
79 | active_installs 80 | 82 |

The number sites that have activated this block.

83 |

84 | JSON data type: integer

85 |

Context: view

86 |
90 | author_block_rating 91 | 93 |

The average rating of blocks published by the same author.

94 |

95 | JSON data type: number

96 |

Context: view

97 |
101 | author_block_count 102 | 104 |

The number of blocks published by the same author.

105 |

106 | JSON data type: integer

107 |

Context: view

108 |
112 | author 113 | 115 |

The WordPress.org username of the block author.

116 |

117 | JSON data type: string

118 |

Context: view

119 |
123 | icon 124 | 126 |

The block icon.

127 |

128 | JSON data type: string, 129 | Format: uri 130 |

131 |

Context: view

132 |
136 | last_updated 137 | 139 |

The date when the block was last updated.

140 |

141 | JSON data type: string, 142 | Format: datetime (details) 143 |

144 |

Context: view

145 |
149 | humanized_updated 150 | 152 |

The date when the block was last updated, in fuzzy human readable format.

153 |

154 | JSON data type: string

155 |

Context: view

156 |
159 | 160 |
161 |
162 | 163 |
164 |
165 |

List Block Directory Items

166 |

Query this endpoint to retrieve a collection of block directory items. The response you receive can be controlled and filtered using the URL query parameters below.

167 | 168 |

Definition

169 | 170 | GET /wp/v2/block-directory/search 171 | 172 |

Example Request

173 | 174 | $ curl https://example.com/wp-json/wp/v2/block-directory/search 175 |
176 |
177 |

Arguments

178 | 179 | 180 | 183 | 190 | 191 | 192 | 195 | 201 | 202 | 203 | 206 | 212 | 213 | 214 | 217 | 223 | 224 |
181 | context
182 |
184 |

Scope under which the request is made; determines fields present in response.

185 |

186 | Default: view 187 |

188 |

One of: view

189 |
193 | page
194 |
196 |

Current page of the collection.

197 |

198 | Default: 1 199 |

200 |
204 | per_page
205 |
207 |

Maximum number of items to be returned in result set.

208 |

209 | Default: 10 210 |

211 |
215 | term
216 |
218 |

Limit result set to blocks matching the search term.

219 |

220 | Required: 1 221 |

222 |
225 | 226 |
227 |
228 |
229 | -------------------------------------------------------------------------------- /reference/pattern-directory-items.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Pattern Directory Items 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a pattern directory item record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 21 | 22 | 23 | 26 | 32 | 33 | 34 | 37 | 43 | 44 | 45 | 48 | 54 | 55 | 56 | 59 | 65 | 66 | 67 | 70 | 76 | 77 | 78 | 81 | 87 | 88 | 89 | 92 | 98 | 99 |
13 | id 14 | 16 |

The pattern ID.

17 |

18 | JSON data type: integer

19 |

Context: view, edit, embed

20 |
24 | title 25 | 27 |

The pattern title, in human readable format.

28 |

29 | JSON data type: string

30 |

Context: view, edit, embed

31 |
35 | content 36 | 38 |

The pattern content.

39 |

40 | JSON data type: string

41 |

Context: view, edit, embed

42 |
46 | categories 47 | 49 |

The pattern's category slugs.

50 |

51 | JSON data type: array

52 |

Context: view, edit, embed

53 |
57 | keywords 58 | 60 |

The pattern's keywords.

61 |

62 | JSON data type: array

63 |

Context: view, edit, embed

64 |
68 | description 69 | 71 |

A description of the pattern.

72 |

73 | JSON data type: string

74 |

Context: view, edit, embed

75 |
79 | viewport_width 80 | 82 |

The preferred width of the viewport when previewing a pattern, in pixels.

83 |

84 | JSON data type: integer

85 |

Context: view, edit, embed

86 |
90 | block_types 91 | 93 |

The block types which can use this pattern.

94 |

95 | JSON data type: array

96 |

Context: view, embed

97 |
100 | 101 |
102 |
103 | 104 |
105 |
106 |

List Pattern Directory Items

107 |

Query this endpoint to retrieve a collection of pattern directory items. The response you receive can be controlled and filtered using the URL query parameters below.

108 | 109 |

Definition

110 | 111 | GET /wp/v2/pattern-directory/patterns 112 | 113 |

Example Request

114 | 115 | $ curl https://example.com/wp-json/wp/v2/pattern-directory/patterns 116 |
117 |
118 |

Arguments

119 | 120 | 121 | 124 | 131 | 132 | 133 | 136 | 142 | 143 | 144 | 147 | 153 | 154 | 155 | 158 | 161 | 162 | 163 | 166 | 169 | 170 | 171 | 174 | 177 | 178 | 179 | 182 | 185 | 186 | 187 | 190 | 193 | 194 | 195 | 198 | 205 | 206 | 207 | 210 | 217 | 218 |
122 | context
123 |
125 |

Scope under which the request is made; determines fields present in response.

126 |

127 | Default: view 128 |

129 |

One of: view, embed, edit

130 |
134 | page
135 |
137 |

Current page of the collection.

138 |

139 | Default: 1 140 |

141 |
145 | per_page
146 |
148 |

Maximum number of items to be returned in result set.

149 |

150 | Default: 100 151 |

152 |
156 | search
157 |
159 |

Limit results to those matching a string.

160 |
164 | category
165 |
167 |

Limit results to those matching a category ID.

168 |
172 | keyword
173 |
175 |

Limit results to those matching a keyword ID.

176 |
180 | slug
181 |
183 |

Limit results to those matching a pattern (slug).

184 |
188 | offset
189 |
191 |

Offset the result set by a specific number of items.

192 |
196 | order
197 |
199 |

Order sort attribute ascending or descending.

200 |

201 | Default: desc 202 |

203 |

One of: asc, desc

204 |
208 | orderby
209 |
211 |

Sort collection by post attribute.

212 |

213 | Default: date 214 |

215 |

One of: author, date, id, include, modified, parent, relevance, slug, include_slugs, title, favorite_count

216 |
219 | 220 |
221 |
222 |
223 | -------------------------------------------------------------------------------- /reference/taxonomies.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Taxonomies 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a taxonomy record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 46 | 47 | 48 | 51 | 58 | 59 | 60 | 63 | 70 | 71 | 72 | 75 | 82 | 83 | 84 | 87 | 94 | 95 | 96 | 99 | 106 | 107 | 108 | 111 | 118 | 119 | 120 | 123 | 130 | 131 | 132 | 135 | 142 | 143 |
13 | capabilities 14 | 16 |

All capabilities used by the taxonomy.

17 |

18 | JSON data type: object

19 |

Read only

20 |

Context: edit

21 |
25 | description 26 | 28 |

A human-readable description of the taxonomy.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context: view, edit

33 |
37 | hierarchical 38 | 40 |

Whether or not the taxonomy should have children.

41 |

42 | JSON data type: boolean

43 |

Read only

44 |

Context: view, edit

45 |
49 | labels 50 | 52 |

Human-readable labels for the taxonomy for various contexts.

53 |

54 | JSON data type: object

55 |

Read only

56 |

Context: edit

57 |
61 | name 62 | 64 |

The title for the taxonomy.

65 |

66 | JSON data type: string

67 |

Read only

68 |

Context: view, edit, embed

69 |
73 | slug 74 | 76 |

An alphanumeric identifier for the taxonomy.

77 |

78 | JSON data type: string

79 |

Read only

80 |

Context: view, edit, embed

81 |
85 | show_cloud 86 | 88 |

Whether or not the term cloud should be displayed.

89 |

90 | JSON data type: boolean

91 |

Read only

92 |

Context: edit

93 |
97 | types 98 | 100 |

Types associated with the taxonomy.

101 |

102 | JSON data type: array

103 |

Read only

104 |

Context: view, edit

105 |
109 | rest_base 110 | 112 |

REST base route for the taxonomy.

113 |

114 | JSON data type: string

115 |

Read only

116 |

Context: view, edit, embed

117 |
121 | rest_namespace 122 | 124 |

REST namespace route for the taxonomy.

125 |

126 | JSON data type: string

127 |

Read only

128 |

Context: view, edit, embed

129 |
133 | visibility 134 | 136 |

The visibility settings for the taxonomy.

137 |

138 | JSON data type: object

139 |

Read only

140 |

Context: edit

141 |
144 | 145 |
146 |
147 | 148 |
149 |
150 |

Retrieve a Taxonomy

151 | 152 |

Definition & Example Request

153 | 154 | GET /wp/v2/taxonomies 155 | 156 |

Query this endpoint to retrieve a specific taxonomy record.

157 | 158 | $ curl https://example.com/wp-json/wp/v2/taxonomies 159 |
160 |
161 |

Arguments

162 | 163 | 164 | 167 | 174 | 175 | 176 | 179 | 182 | 183 |
165 | context
166 |
168 |

Scope under which the request is made; determines fields present in response.

169 |

170 | Default: view 171 |

172 |

One of: view, embed, edit

173 |
177 | type
178 |
180 |

Limit results to taxonomies associated with a specific post type.

181 |
184 | 185 |
186 |
187 |
188 |
189 |

Retrieve a Taxonomy

190 | 191 |

Definition & Example Request

192 | 193 | GET /wp/v2/taxonomies/<taxonomy> 194 | 195 |

Query this endpoint to retrieve a specific taxonomy record.

196 | 197 | $ curl https://example.com/wp-json/wp/v2/taxonomies/<taxonomy> 198 |
199 |
200 |

Arguments

201 | 202 | 203 | 206 | 209 | 210 | 211 | 214 | 221 | 222 |
204 | taxonomy
205 |
207 |

An alphanumeric identifier for the taxonomy.

208 |
212 | context
213 |
215 |

Scope under which the request is made; determines fields present in response.

216 |

217 | Default: view 218 |

219 |

One of: view, embed, edit

220 |
223 | 224 |
225 |
226 |
227 | -------------------------------------------------------------------------------- /reference/sidebars.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Sidebars 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a sidebar record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 46 | 47 | 48 | 51 | 58 | 59 | 60 | 63 | 70 | 71 | 72 | 75 | 82 | 83 | 84 | 87 | 94 | 95 | 96 | 99 | 106 | 107 | 108 | 111 | 119 | 120 | 121 | 124 | 130 | 131 |
13 | id 14 | 16 |

ID of sidebar.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context: embed, view, edit

21 |
25 | name 26 | 28 |

Unique name identifying the sidebar.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context: embed, view, edit

33 |
37 | description 38 | 40 |

Description of sidebar.

41 |

42 | JSON data type: string

43 |

Read only

44 |

Context: embed, view, edit

45 |
49 | class 50 | 52 |

Extra CSS class to assign to the sidebar in the Widgets interface.

53 |

54 | JSON data type: string

55 |

Read only

56 |

Context: embed, view, edit

57 |
61 | before_widget 62 | 64 |

HTML content to prepend to each widget's HTML output when assigned to this sidebar. Default is an opening list item element.

65 |

66 | JSON data type: string

67 |

Read only

68 |

Context: embed, view, edit

69 |
73 | after_widget 74 | 76 |

HTML content to append to each widget's HTML output when assigned to this sidebar. Default is a closing list item element.

77 |

78 | JSON data type: string

79 |

Read only

80 |

Context: embed, view, edit

81 |
85 | before_title 86 | 88 |

HTML content to prepend to the sidebar title when displayed. Default is an opening h2 element.

89 |

90 | JSON data type: string

91 |

Read only

92 |

Context: embed, view, edit

93 |
97 | after_title 98 | 100 |

HTML content to append to the sidebar title when displayed. Default is a closing h2 element.

101 |

102 | JSON data type: string

103 |

Read only

104 |

Context: embed, view, edit

105 |
109 | status 110 | 112 |

Status of sidebar.

113 |

114 | JSON data type: string

115 |

Read only

116 |

Context: embed, view, edit

117 |

One of: active, inactive

118 |
122 | widgets 123 | 125 |

Nested widgets.

126 |

127 | JSON data type: array

128 |

Context: embed, view, edit

129 |
132 | 133 |
134 |
135 | 136 |
137 |
138 |

Retrieve a Sidebar

139 | 140 |

Definition & Example Request

141 | 142 | GET /wp/v2/sidebars 143 | 144 |

Query this endpoint to retrieve a specific sidebar record.

145 | 146 | $ curl https://example.com/wp-json/wp/v2/sidebars 147 |
148 |
149 |

Arguments

150 | 151 | 152 | 155 | 162 | 163 |
153 | context
154 |
156 |

Scope under which the request is made; determines fields present in response.

157 |

158 | Default: view 159 |

160 |

One of: view, embed, edit

161 |
164 | 165 |
166 |
167 |
168 |
169 |

Retrieve a Sidebar

170 | 171 |

Definition & Example Request

172 | 173 | GET /wp/v2/sidebars/<id> 174 | 175 |

Query this endpoint to retrieve a specific sidebar record.

176 | 177 | $ curl https://example.com/wp-json/wp/v2/sidebars/<id> 178 |
179 |
180 |

Arguments

181 | 182 | 183 | 186 | 189 | 190 | 191 | 194 | 201 | 202 |
184 | id
185 |
187 |

The id of a registered sidebar

188 |
192 | context
193 |
195 |

Scope under which the request is made; determines fields present in response.

196 |

197 | Default: view 198 |

199 |

One of: view, embed, edit

200 |
203 | 204 |
205 |
206 |
207 |
208 |

Update a Sidebar

209 |

Arguments

210 | 211 | 212 | 215 | 218 | 219 |
213 | widgets
214 |
216 |

Nested widgets.

217 |
220 | 221 |
222 |
223 |

Definition

224 | 225 | POST /wp/v2/sidebars/<id> 226 | 227 |

Example Request

228 | 229 | 230 |
231 |
232 |
233 | -------------------------------------------------------------------------------- /using-the-rest-api/global-parameters.md: -------------------------------------------------------------------------------- 1 | # Global Parameters 2 | 3 | The API includes a number of global parameters (also called "meta-parameters") which control how the API handles the request/response handling. These operate at a layer above the actual resources themselves, and are available on all resources. 4 | 5 | ## `_fields` 6 | 7 | A REST resource like a Post contains a large quantity of data: basic information such as content, title, and author ID, but also [registered metadata and fields](https://developer.wordpress.org/rest-api/extending-the-rest-api/modifying-responses/), media information, and links to other resources. Your application may not need all of this information on every request. 8 | 9 | To instruct WordPress to return only a subset of the fields in a response, you may use the `_fields` query parameter. If for example you are building an archive view and only need the ID, title, permalink, author and excerpt for a collection of posts, you can restrict the response to only those properties with this fields query: 10 | 11 | ``` 12 | /wp/v2/posts?_fields=author,id,excerpt,title,link 13 | ``` 14 | 15 | You may alternatively provide that same list using query parameter array syntax instead of a comma-separated list: 16 | 17 | ``` 18 | /wp/v2/posts?_fields[]=author&_fields[]=id&_fields[]=excerpt&_fields[]=title&_fields[]=link 19 | ``` 20 | 21 | When `_fields` is provided then WordPress will skip unneeded fields when generating your response object, avoiding potentially expensive internal computation or queries for data you don't need. This also means the JSON object returned from the REST API will be smaller, requiring less time to download and less time to parse on your client device. 22 | 23 | Carefully design your queries to pull in only the needed properties from each resource to make your application faster to use and more efficient to run. 24 | 25 | As of WordPress 5.3 the `_fields` parameter supports nested properties. This can be useful if you have registered many meta keys, permitting you to request the value for only one of the registered meta properties: 26 | 27 | ``` 28 | ?_fields=meta.one-of-many-keys 29 | ``` 30 | 31 | Only the meta value with the key `one-of-many-keys` will be returned, and others will be excluded. 32 | 33 | You can also request specific deeply-nested properties within a complex meta object: 34 | 35 | ``` 36 | ?_fields=meta.key_name.nested_prop.deeply_nested_prop,meta.key_name.other_nested_prop 37 | ``` 38 | 39 | 40 | ## `_embed` 41 | 42 | Most resources include links to related resources. For example, a post can link to the parent post, or to comments on the post. To reduce the number of HTTP requests required, clients may wish to fetch a resource as well as the linked resources. The `_embed` parameter indicates to the server that the response should include these embedded resources. 43 | 44 | Embed mode is enabled if the `_embed` parameter is passed in the query string (GET parameter). This parameter does not require a value (i.e. `?_embed` is valid), however can be passed "1" as a value if required by a client library. 45 | 46 | As of WordPress 5.4, the resources to embed can be limited by passing a list of link relation names to the `_embed` parameter. For example, `/wp/v2/posts?_embed=author,wp:term` will only embed the post's author and the lists of terms associated with the post. 47 | 48 | Resources in embed mode will contain an additional `_embedded` key next to the `_links` key containing the linked resources. Only links with the `embeddable` parameter set to `true` will be embedded. 49 | 50 | In order to use `_embed` together with `_fields`, add `_embedded` as well as `_links` to the fields, for instance, `/wp-json/wp/v2/posts/_embed=author,wp:term&_fields=title,author,_links,_embedded`. 51 | 52 | For more about linking and embedding, see the [Linking and Embedding](https://developer.wordpress.org/rest-api/linking-and-embedding/) page. 53 | 54 | ## `_method` (or `X-HTTP-Method-Override` header) 55 | 56 | Some servers and clients cannot correctly process some HTTP methods that the API makes use of. For example, all deletion requests on resources use the `DELETE` method, but some clients do not provide the ability to send this method. 57 | 58 | To ensure compatibility with these servers and clients, the API supports a method override. This can be passed either via a `_method` parameter or the `X-HTTP-Method-Override` header, with the value set to the HTTP method to use. 59 | 60 | [alert] 61 | Clients should only ever send a method override parameter or header with POST requests. Using the method override with GET requests may cause the request to be incorrectly cached. 62 | [/alert] 63 | 64 | A `POST` to `/wp-json/wp/v2/posts/42?_method=DELETE` would be translated to a `DELETE` to the `wp/v2/posts/42` route. 65 | 66 | Similarly, the following POST request would become a DELETE: 67 | 68 | ``` 69 | POST /wp-json/wp/v2/posts/42 HTTP/1.1 70 | Host: example.com 71 | X-HTTP-Method-Override: DELETE 72 | ``` 73 | 74 | ## `_envelope` 75 | 76 | Similarly to `_method`, some servers, clients, and proxies do not support accessing the full response data. The API supports passing an `_envelope` parameter, which sends all response data in the body, including headers and status code. 77 | 78 | Envelope mode is enabled if the `_envelope` parameter is passed in the query string (GET parameter). This parameter does not require a value (i.e. `?_envelope` is valid), but can be passed "1" as a value if required by a client library. 79 | 80 | [info] 81 | For future compatibility, other values should not be passed. 82 | [/info] 83 | 84 | Enveloped responses include a "fake" HTTP 200 response code with no additional headers (apart from Content-Type) that should ensure the response correctly passes through intermediaries. 85 | 86 | For example, given the following response to a `GET` to `wp/v2/users/me`: 87 | 88 | ``` 89 | HTTP/1.1 302 Found 90 | Location: http://example.com/wp-json/wp/v2/users/42 91 | 92 | { 93 | "id": 42, 94 | ... 95 | } 96 | ``` 97 | 98 | The equivalent enveloped response (with a `GET` to `wp/v2/users/me?_envelope`) would be: 99 | 100 | ``` 101 | HTTP/1.1 200 OK 102 | 103 | { 104 | "status": 302, 105 | "headers": { 106 | "Location": "http://example.com/wp-json/wp/v2/users/42" 107 | }, 108 | "body": { 109 | "id": 42 110 | } 111 | } 112 | ``` 113 | 114 | ## `_jsonp` 115 | 116 | The API natively supports [JSONP](https://en.wikipedia.org/wiki/JSONP) responses to allow cross-domain requests for legacy browsers and clients. This parameter takes a JavaScript callback function which will be prepended to the data. This URL can then be loaded via a ` 139 | 140 | ``` 141 | -------------------------------------------------------------------------------- /reference/themes.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Themes 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a theme record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 46 | 47 | 48 | 51 | 58 | 59 | 60 | 63 | 70 | 71 | 72 | 75 | 82 | 83 | 84 | 87 | 94 | 95 | 96 | 99 | 106 | 107 | 108 | 111 | 118 | 119 | 120 | 123 | 132 | 133 | 134 | 137 | 144 | 145 | 146 | 149 | 156 | 157 | 158 | 161 | 168 | 169 | 170 | 173 | 180 | 181 | 182 | 185 | 192 | 193 | 194 | 197 | 204 | 205 |
13 | stylesheet 14 | 16 |

The theme's stylesheet. This uniquely identifies the theme.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context:

21 |
25 | template 26 | 28 |

The theme's template. If this is a child theme, this refers to the parent theme, otherwise this is the same as the theme's stylesheet.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context:

33 |
37 | author 38 | 40 |

The theme author.

41 |

42 | JSON data type: object

43 |

Read only

44 |

Context:

45 |
49 | author_uri 50 | 52 |

The website of the theme author.

53 |

54 | JSON data type: object

55 |

Read only

56 |

Context:

57 |
61 | description 62 | 64 |

A description of the theme.

65 |

66 | JSON data type: object

67 |

Read only

68 |

Context:

69 |
73 | is_block_theme 74 | 76 |

Whether the theme is a block-based theme.

77 |

78 | JSON data type: boolean

79 |

Read only

80 |

Context:

81 |
85 | name 86 | 88 |

The name of the theme.

89 |

90 | JSON data type: object

91 |

Read only

92 |

Context:

93 |
97 | requires_php 98 | 100 |

The minimum PHP version required for the theme to work.

101 |

102 | JSON data type: string

103 |

Read only

104 |

Context:

105 |
109 | requires_wp 110 | 112 |

The minimum WordPress version required for the theme to work.

113 |

114 | JSON data type: string

115 |

Read only

116 |

Context:

117 |
121 | screenshot 122 | 124 |

The theme's screenshot URL.

125 |

126 | JSON data type: string, 127 | Format: uri 128 |

129 |

Read only

130 |

Context:

131 |
135 | tags 136 | 138 |

Tags indicating styles and features of the theme.

139 |

140 | JSON data type: object

141 |

Read only

142 |

Context:

143 |
147 | textdomain 148 | 150 |

The theme's text domain.

151 |

152 | JSON data type: string

153 |

Read only

154 |

Context:

155 |
159 | theme_supports 160 | 162 |

Features supported by this theme.

163 |

164 | JSON data type: object

165 |

Read only

166 |

Context:

167 |
171 | theme_uri 172 | 174 |

The URI of the theme's webpage.

175 |

176 | JSON data type: object

177 |

Read only

178 |

Context:

179 |
183 | version 184 | 186 |

The theme's current version.

187 |

188 | JSON data type: string

189 |

Read only

190 |

Context:

191 |
195 | status 196 | 198 |

A named status for the theme.

199 |

200 | JSON data type: string

201 |

Context:

202 |

One of: inactive, active

203 |
206 | 207 |
208 |
209 | 210 |
211 |
212 |

Retrieve a Theme

213 | 214 |

Definition & Example Request

215 | 216 | GET /wp/v2/themes 217 | 218 |

Query this endpoint to retrieve a specific theme record.

219 | 220 | $ curl https://example.com/wp-json/wp/v2/themes 221 |
222 |
223 |

Arguments

224 | 225 | 226 | 229 | 232 | 233 |
227 | status
228 |
230 |

Limit result set to themes assigned one or more statuses.

231 |
234 | 235 |
236 |
237 |
238 |
239 |

Retrieve a Theme

240 | 241 |

Definition & Example Request

242 | 243 | GET /wp/v2/themes/<stylesheet>?) 244 | 245 |

Query this endpoint to retrieve a specific theme record.

246 | 247 | $ curl https://example.com/wp-json/wp/v2/themes/<stylesheet>?) 248 |
249 |
250 |

Arguments

251 | 252 | 253 | 256 | 259 | 260 |
254 | stylesheet
255 |
257 |

The theme's stylesheet. This uniquely identifies the theme.

258 |
261 | 262 |
263 |
264 |
265 | -------------------------------------------------------------------------------- /using-the-rest-api/discovery.md: -------------------------------------------------------------------------------- 1 | # Discovery 2 | 3 | When your client talks to an unknown site, you'll need to discover what the site is capable of and how the site is configured. There are a couple of steps for this, depending on what you need to discover. 4 | 5 | 6 | ## Discovering the API 7 | 8 | The first step of connecting to a site is finding out whether the site has the API enabled. Typically, you'll be working with URLs from user input, so the site you're accessing could be anything. The discovery step lets you verify the API is available, as well as indicating how to access it. 9 | 10 | 11 | ### Link Header 12 | 13 | The preferred way to handle discovery is to send a HEAD request to the supplied address. The REST API automatically adds a Link header to all front-end pages that looks like the following: 14 | 15 | Link: ; rel="https://api.w.org/" 16 | 17 | This URL points to the root route (`/`) of the API, which is then used for further discovery steps. 18 | 19 | For sites without "pretty permalinks" enabled, `/wp-json/` isn't automatically handled by WordPress. This means that normal/default WordPress permalinks will be used instead. These headers look more like this: 20 | 21 | Link: ; rel="https://api.w.org/" 22 | 23 | Clients should keep this variation in mind and ensure that both routes can be handled seamlessly. 24 | 25 | This auto-discovery can be applied to any URL served by a WordPress installation, so no pre-processing on user input needs to be added. Since this is a HEAD request, the request should be safe to send blindly to servers without worrying about causing side-effects. 26 | 27 | 28 | ### Element 29 | 30 | For clients with a HTML parser, or running in the browser, the equivalent of the Link header is included in the `` of front-end pages through a `` element: 31 | 32 | 33 | 34 | In-browser Javascript can access this via the DOM: 35 | 36 | ```js 37 | // jQuery method 38 | var $link = jQuery( 'link[rel="https://api.w.org/"]' ); 39 | var api_root = $link.attr( 'href' ); 40 | 41 | // Native method 42 | var links = document.getElementsByTagName( 'link' ); 43 | var link = Array.prototype.filter.call( links, function ( item ) { 44 | return ( item.rel === 'https://api.w.org/' ); 45 | } ); 46 | var api_root = link[0].href; 47 | ``` 48 | 49 | For in-browser clients, or clients without access to HTTP headers, this may be a more usable way of discovering the API. This is similar to Atom/RSS feed discovery, so existing code for that purpose may also be automatically adapted instead. 50 | 51 | 52 | ### RSD (Really Simple Discovery) 53 | 54 | For clients with support for XML-RPC discovery, the [RSD method](http://cyber.law.harvard.edu/blogs/gems/tech/rsd.html) may be more applicable. This is an XML-based discovery format typically used for XML-RPC. RSD has two steps. The first step is to find the RSD endpoint, supplied as a `` element: 55 | 56 | 57 | 58 | The second step is to fetch the RSD document and parse the available endpoints. This involves using an XML parser on a document like the following: 59 | 60 | ```xml 61 | 62 | 63 | 64 | WordPress 65 | http://wordpress.org/ 66 | http://example.com/ 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | ``` 75 | 76 | The REST API always has a `name` attribute with the value equal to `WP-API`. 77 | 78 | RSD is the least-preferred method of autodiscovery for a couple of reasons. The first step of RSD-based discovery involves parsing the HTML to first find the RSD document itself, which is equivalent to the `` Element autodiscovery. It then involves another step to parse the RSD document, which requires a full XML parser. 79 | 80 | Where possible, we suggest avoiding RSD-based discovery due to the complexity, but existing XML-RPC clients may prefer to use this method if they already have an RSD parser enabled. For XML-RPC clients which wish to use the REST API as a progressive enhancement to the codebase, this avoids needing to support different forms of discovery. 81 | 82 | 83 | ## Authentication Discovery 84 | 85 | Discovery is also available for authentication methods available via the API. The API root's response is an object describing the API, which includes an `authentication` key: 86 | 87 | ``` 88 | { 89 | "name": "Example WordPress Site", 90 | "description": "YOLO", 91 | "routes": { ... }, 92 | "authentication": { 93 | "oauth1": { 94 | "request": "http://example.com/oauth/request", 95 | "authorize": "http://example.com/oauth/authorize", 96 | "access": "http://example.com/oauth/access", 97 | "version": "0.1" 98 | } 99 | } 100 | } 101 | ``` 102 | 103 | The `authentication` value is a map (associative array) of authentication method ID to authentication options. The options available here are specific to the authentication method itself. See the [authentication documentation](/rest-api/authentication/) for the options for specific authentication methods. 104 | 105 | 106 | ## Extension Discovery 107 | 108 | Once you've discovered the API, the next step is check what the API supports. The index of the API exposes the `namespaces` item, which contains the extensions to the API that are supported. 109 | 110 | For WordPress sites using versions 4.4 through 4.6, only the base API infrastructure is available, not the full API with endpoints. This also includes the oEmbed endpoints: 111 | 112 | ``` 113 | { 114 | "name": "Example WordPress Site", 115 | "namespaces": [ 116 | "oembed/1.0/" 117 | ] 118 | } 119 | ``` 120 | 121 | Sites with the full API available (i.e. with WordPress 4.7+ or the REST API plugin installed) will have the `wp/v2` item in `namespaces` as well: 122 | 123 | ``` 124 | { 125 | "name": "Example WordPress Site", 126 | "namespaces": [ 127 | "wp/v2", 128 | "oembed/1.0/" 129 | ] 130 | } 131 | ``` 132 | 133 | Before attempting to use any of the core endpoints, you should be sure to check that the API is supported by checking for `wp/v2` support. WordPress 4.4 enabled the API infrastructure for all sites, but did **not** include the core endpoints under `wp/v2`. Core endpoints were added in WordPress 4.7. 134 | 135 | This same mechanism can be used for detecting support for any plugins that support the REST API. For example, take a plugin which registers the following route: 136 | 137 | ```php 138 | ` element](#element). 158 | 159 | For instance, in the `` section of this page, the following `` appears. 160 | 161 | ```html 162 | 163 | ``` 164 | 165 | Links are added for post, pages, and other custom post types, as well as terms and author pages. Links are not currently output for post archives or search results. 166 | -------------------------------------------------------------------------------- /reference/post-types.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Types 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a type record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 46 | 47 | 48 | 51 | 58 | 59 | 60 | 63 | 70 | 71 | 72 | 75 | 82 | 83 | 84 | 87 | 94 | 95 | 96 | 99 | 106 | 107 | 108 | 111 | 118 | 119 | 120 | 123 | 130 | 131 | 132 | 135 | 142 | 143 | 144 | 147 | 154 | 155 | 156 | 159 | 166 | 167 | 168 | 171 | 178 | 179 |
13 | capabilities 14 | 16 |

All capabilities used by the post type.

17 |

18 | JSON data type: object

19 |

Read only

20 |

Context: edit

21 |
25 | description 26 | 28 |

A human-readable description of the post type.

29 |

30 | JSON data type: string

31 |

Read only

32 |

Context: view, edit

33 |
37 | hierarchical 38 | 40 |

Whether or not the post type should have children.

41 |

42 | JSON data type: boolean

43 |

Read only

44 |

Context: view, edit

45 |
49 | viewable 50 | 52 |

Whether or not the post type can be viewed.

53 |

54 | JSON data type: boolean

55 |

Read only

56 |

Context: edit

57 |
61 | labels 62 | 64 |

Human-readable labels for the post type for various contexts.

65 |

66 | JSON data type: object

67 |

Read only

68 |

Context: edit

69 |
73 | name 74 | 76 |

The title for the post type.

77 |

78 | JSON data type: string

79 |

Read only

80 |

Context: view, edit, embed

81 |
85 | slug 86 | 88 |

An alphanumeric identifier for the post type.

89 |

90 | JSON data type: string

91 |

Read only

92 |

Context: view, edit, embed

93 |
97 | supports 98 | 100 |

All features, supported by the post type.

101 |

102 | JSON data type: object

103 |

Read only

104 |

Context: edit

105 |
109 | has_archive 110 | 112 |

If the value is a string, the value will be used as the archive slug. If the value is false the post type has no archive.

113 |

114 | JSON data type: string or boolean

115 |

Read only

116 |

Context: view, edit

117 |
121 | taxonomies 122 | 124 |

Taxonomies associated with post type.

125 |

126 | JSON data type: array

127 |

Read only

128 |

Context: view, edit

129 |
133 | rest_base 134 | 136 |

REST base route for the post type.

137 |

138 | JSON data type: string

139 |

Read only

140 |

Context: view, edit, embed

141 |
145 | rest_namespace 146 | 148 |

REST route's namespace for the post type.

149 |

150 | JSON data type: string

151 |

Read only

152 |

Context: view, edit, embed

153 |
157 | visibility 158 | 160 |

The visibility settings for the post type.

161 |

162 | JSON data type: object

163 |

Read only

164 |

Context: edit

165 |
169 | icon 170 | 172 |

The icon for the post type.

173 |

174 | JSON data type: string or null

175 |

Read only

176 |

Context: view, edit, embed

177 |
180 | 181 |
182 |
183 | 184 |
185 |
186 |

Retrieve a Type

187 | 188 |

Definition & Example Request

189 | 190 | GET /wp/v2/types 191 | 192 |

Query this endpoint to retrieve a specific type record.

193 | 194 | $ curl https://example.com/wp-json/wp/v2/types 195 |
196 |
197 |

Arguments

198 | 199 | 200 | 203 | 210 | 211 |
201 | context
202 |
204 |

Scope under which the request is made; determines fields present in response.

205 |

206 | Default: view 207 |

208 |

One of: view, embed, edit

209 |
212 | 213 |
214 |
215 |
216 |
217 |

Retrieve a Type

218 | 219 |

Definition & Example Request

220 | 221 | GET /wp/v2/types/<type> 222 | 223 |

Query this endpoint to retrieve a specific type record.

224 | 225 | $ curl https://example.com/wp-json/wp/v2/types/<type> 226 |
227 |
228 |

Arguments

229 | 230 | 231 | 234 | 237 | 238 | 239 | 242 | 249 | 250 |
232 | type
233 |
235 |

An alphanumeric identifier for the post type.

236 |
240 | context
241 |
243 |

Scope under which the request is made; determines fields present in response.

244 |

245 | Default: view 246 |

247 |

One of: view, embed, edit

248 |
251 | 252 |
253 |
254 |
255 | -------------------------------------------------------------------------------- /using-the-rest-api/backbone-javascript-client.md: -------------------------------------------------------------------------------- 1 | # Backbone JavaScript Client 2 | 3 | The REST API includes a JavaScript/Backbone client library. 4 | 5 | The library provides an interface for the WP REST API by providing Backbone Models and Collections for all endpoints exposed through the API Schema. 6 | 7 | 8 | ## Using 9 | 10 | Activate the WP-API plugin. Enqueue the script directly: 11 | 12 | ```php 13 | wp_enqueue_script( 'wp-api' ); 14 | ``` 15 | 16 | or as a dependency for your script: 17 | 18 | ```php 19 | wp_enqueue_script( 'my_script', 'path/to/my/script', array( 'wp-api' ) ); 20 | ``` 21 | 22 | The library parses the root endpoint (the 'Schema') and creates matching Backbone models and collections. You will now have two root objects available to you: `wp.api.models` and `wp.api.collections`. 23 | 24 | The models and collections include: 25 | 26 | Models: 27 | * Category 28 | * Comment 29 | * Media 30 | * Page 31 | * PageMeta 32 | * PageRevision 33 | * Post 34 | * PostMeta 35 | * PostRevision 36 | * Schema 37 | * Status 38 | * Tag 39 | * Taxonomy 40 | * Type 41 | * User 42 | 43 | Collections: 44 | * Categories 45 | * Comments 46 | * Media 47 | * PageMeta 48 | * PageRevisions 49 | * Pages 50 | * Posts 51 | * Statuses 52 | * Tags 53 | * Taxonomies 54 | * Types 55 | * Users 56 | 57 | You can use these endpoints as-is to read, update, create and delete items using standard Backbone methods (fetch, sync, save & destroy for models, sync for collections). You can also extend these objects to make them your own, and build your views on top of them. 58 | 59 | 60 | ### Default values 61 | 62 | Each model and collection includes a reference to its default values, for example: 63 | 64 | `wp.api.models.Post.prototype.args` 65 | 66 | * author: null 67 | * comment_status: null 68 | * content: null 69 | * date: null 70 | * date_gmt: null 71 | * excerpt: null 72 | * featured_media: null 73 | * format: null 74 | * modified: null 75 | * modified_gmt: null 76 | * password: null 77 | * ping_status: null 78 | * slug: null 79 | * status: null 80 | * sticky: null 81 | * title: null 82 | 83 | 84 | ### Available methods 85 | 86 | Each model and collection contains a list of methods the corresponding endpoint supports. For example, models created from `wp.api.models.Post` have a methods array of: 87 | 88 | ```js 89 | ["GET", "POST", "PUT", "PATCH", "DELETE"] 90 | ``` 91 | 92 | 93 | ### Accepted options 94 | 95 | Each model and collection contains a list of options the corresponding endpoint accepts (note that options are passed as the second parameter when creating models or collections), for example: 96 | 97 | `wp.api.collections.Posts.prototype.options` 98 | 99 | * author 100 | * context 101 | * filter 102 | * order 103 | * orderby 104 | * page 105 | * per_page 106 | * search 107 | * status 108 | 109 | 110 | ### Localizing the API Schema 111 | 112 | The client will accept and use a localized schema as part of the `wpApiSettings` object. The Schema is currently not passed by default; instead the client makes an ajax request to the API to load the Schema, then caches it in the browser's session storage (if available). Activating the client-js plugin with `SCRIPT_DEBUG` enabled uses a localized Schema. Check the [client-js example](https://github.com/WP-API/client-js/blob/master/client-js.php) or this branch which [attempts to only localize the schema once per client](https://github.com/WP-API/client-js/compare/features/only-localize-schma-once?expand=1). 113 | 114 | 115 | ### Waiting for the client to load 116 | 117 | Client startup is asynchronous. If the api schema is localized, the client can start immediately; if not the client makes an ajax request to load the schema. The client exposes a load promise for provide a reliable wait to wait for client to be ready: 118 | 119 | ```js 120 | wp.api.loadPromise.done( function() { 121 | //... use the client here 122 | } ) 123 | ``` 124 | 125 | 126 | ### Model examples: 127 | 128 | To create a post and edit its categories, make sure you are logged in, then: 129 | 130 | ```js 131 | // Create a new post 132 | var post = new wp.api.models.Post( { title: 'This is a test post' } ); 133 | post.save(); 134 | 135 | // Load an existing post 136 | var post = new wp.api.models.Post( { id: 1 } ); 137 | post.fetch(); 138 | 139 | // Get a collection of the post's categories (returns a promise) 140 | // Uses _embedded data if available, in which case promise resolves immediately. 141 | post.getCategories().done( function( postCategories ) { 142 | // ... do something with the categories. 143 | // The new post has an single Category: Uncategorized 144 | console.log( postCategories[0].name ); 145 | // response -> "Uncategorized" 146 | } ); 147 | 148 | // Get a posts author User model. 149 | post.getAuthorUser().done( function( user ){ 150 | // ... do something with user 151 | console.log( user.get( "name" ) ); 152 | } ); 153 | 154 | // Get a posts featured image Media model. 155 | post.getFeaturedMedia().done( function( image ){ 156 | // ... do something with image 157 | console.log( image ); 158 | } ); 159 | 160 | // Set the post categories. 161 | post.setCategories( [ "apples", "oranges" ] ); 162 | 163 | // Get all the categories 164 | var allCategories = new wp.api.collections.Categories() 165 | allCategories.fetch(); 166 | 167 | var appleCategory = allCategories.findWhere( { slug: "apples" } ); 168 | 169 | // Add the category to the postCategories collection we previously fetched. 170 | appleCategory.set( "parent_post", post.get( "id" ) ); 171 | 172 | // Use the POST method so Backbone will not PUT it even though it has an id. 173 | postCategories.create( appleCategory.toJSON(), { type: "POST" } ); 174 | 175 | // Remove the Uncategorized category 176 | postCategories.at( 0 ).destroy(); 177 | 178 | // Check the results - re-fetch 179 | postCategories = post.getCategories(); 180 | 181 | postCategories.at( 0 ).get( "name" ); 182 | // response -> "apples" 183 | ``` 184 | 185 | ### Collection examples: 186 | To get the last 10 posts: 187 | 188 | ```js 189 | var postsCollection = new wp.api.collections.Posts(); 190 | postsCollection.fetch(); 191 | ``` 192 | 193 | To get the last 25 posts: 194 | 195 | ```js 196 | postsCollection.fetch( { data: { per_page: 25 } } ); 197 | ``` 198 | 199 | Use filter to change the order & orderby options: 200 | 201 | ```js 202 | postsCollection.fetch( { data: { 'filter': { 'orderby': 'title', 'order': 'ASC' } } } ); 203 | ``` 204 | 205 | All collections support pagination automatically, and you can get the next page of results using `more`: 206 | 207 | ```js 208 | postsCollection.more(); 209 | ``` 210 | 211 | To get page 5 of a collection: 212 | 213 | ```js 214 | posts.fetch( { data: { page: 5 } } ); 215 | ``` 216 | 217 | Check if the collection has any more posts: 218 | 219 | ```js 220 | posts.hasMore(); 221 | ``` 222 | 223 | 224 | ### Working With Revisions 225 | 226 | You can access post or page revisions using the PostRevisions or PageRevisions collections or through the Post or Page collection. 227 | 228 | For example, to get a collection of all revisions of post ID 1: 229 | 230 | ```js 231 | var revisions = new wp.api.collections.PostRevisions({}, { parent: 1 }); 232 | ``` 233 | 234 | Revision collections can also be accessed via their parent's collection. This example makes 2 HTTP requests instead of one, but now the original post and its revisions are available: 235 | 236 | ```js 237 | var post = new wp.api.models.Post( { id: 1 } ); 238 | post.fetch(); 239 | post.getRevisions().done( function( revisions ){ 240 | console.log( revisions ); 241 | }); 242 | ``` 243 | 244 | If you add custom endpoints to the API they will also become available as models/collections. For example, you will get new models and collections when you [add REST API support to your custom post type](https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-rest-api-support-for-custom-content-types/). To access custom endpoints created, use the item's JSON endpoint name as CamelCase; for example if the item is found at the JSON path of /wp-json/wp/v2/my-custom-post, it can be accessed via the api at wp.api.collections.MyCustomPost. Note: Because the schema is stored in the user's session cache to avoid re-fetching, you may need to open a new tab to get a new read of the Schema. 245 | 246 | ```js 247 | // Extend wp.api.models.Post and wp.api.collections.Posts to load a custom post type 248 | const CustomPost = wp.api.models.Post.extend( { 249 | urlRoot: wpApiSettings.root + 'wp/v2/custom_post_slug', 250 | defaults: { 251 | type: 'custom_post_slug', 252 | }, 253 | } ); 254 | const CustomPosts = wp.api.collections.Posts.extend( { 255 | url: wpApiSettings.root + 'wp/v2/custom_post_slug', 256 | model: BLProduct, 257 | } ); 258 | const someCustomPosts = new CustomPosts(); 259 | someCustomPosts.fetch().then( ( posts ) => { 260 | // do something with the custom posts 261 | } ); 262 | ``` 263 | -------------------------------------------------------------------------------- /reference/widgets.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Widgets 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a widget record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 21 | 22 | 23 | 26 | 32 | 33 | 34 | 37 | 43 | 44 | 45 | 48 | 55 | 56 | 57 | 60 | 67 | 68 | 69 | 72 | 78 | 79 | 80 | 83 | 89 | 90 |
13 | id 14 | 16 |

Unique identifier for the widget.

17 |

18 | JSON data type: string

19 |

Context: view, edit, embed

20 |
24 | id_base 25 | 27 |

The type of the widget. Corresponds to ID in widget-types endpoint.

28 |

29 | JSON data type: string

30 |

Context: view, edit, embed

31 |
35 | sidebar 36 | 38 |

The sidebar the widget belongs to.

39 |

40 | JSON data type: string

41 |

Context: view, edit, embed

42 |
46 | rendered 47 | 49 |

HTML representation of the widget.

50 |

51 | JSON data type: string

52 |

Read only

53 |

Context: view, edit, embed

54 |
58 | rendered_form 59 | 61 |

HTML representation of the widget admin form.

62 |

63 | JSON data type: string

64 |

Read only

65 |

Context: edit

66 |
70 | instance 71 | 73 |

Instance settings of the widget, if supported.

74 |

75 | JSON data type: object

76 |

Context: edit

77 |
81 | form_data 82 | 84 |

URL-encoded form data from the widget admin form. Used to update a widget that does not support instance. Write only.

85 |

86 | JSON data type: string

87 |

Context:

88 |
91 | 92 |
93 |
94 | 95 |
96 |
97 |

Retrieve a Widget

98 | 99 |

Definition & Example Request

100 | 101 | GET /wp/v2/widgets 102 | 103 |

Query this endpoint to retrieve a specific widget record.

104 | 105 | $ curl https://example.com/wp-json/wp/v2/widgets 106 |
107 |
108 |

Arguments

109 | 110 | 111 | 114 | 121 | 122 | 123 | 126 | 129 | 130 |
112 | context
113 |
115 |

Scope under which the request is made; determines fields present in response.

116 |

117 | Default: view 118 |

119 |

One of: view, embed, edit

120 |
124 | sidebar
125 |
127 |

The sidebar to return widgets for.

128 |
131 | 132 |
133 |
134 |
135 |
136 |

Create a Widget

137 |

Arguments

138 | 139 | 140 | 143 | 146 | 147 | 148 | 151 | 154 | 155 | 156 | 159 | 168 | 169 | 170 | 173 | 176 | 177 | 178 | 181 | 184 | 185 |
141 | id
142 |
144 |

Unique identifier for the widget.

145 |
149 | id_base
150 |
152 |

The type of the widget. Corresponds to ID in widget-types endpoint.

153 |
157 | sidebar
158 |
160 |

The sidebar the widget belongs to.

161 |

162 | Required: 1 163 |

164 |

165 | Default: wp_inactive_widgets 166 |

167 |
171 | instance
172 |
174 |

Instance settings of the widget, if supported.

175 |
179 | form_data
180 |
182 |

URL-encoded form data from the widget admin form. Used to update a widget that does not support instance. Write only.

183 |
186 | 187 |
188 |
189 |

Definition

190 | 191 | POST /wp/v2/widgets 192 |
193 |
194 |
195 |
196 |

Retrieve a Widget

197 | 198 |

Definition & Example Request

199 | 200 | GET /wp/v2/widgets/<id> 201 | 202 |

Query this endpoint to retrieve a specific widget record.

203 | 204 | $ curl https://example.com/wp-json/wp/v2/widgets/<id> 205 |
206 |
207 |

Arguments

208 | 209 | 210 | 213 | 220 | 221 |
211 | context
212 |
214 |

Scope under which the request is made; determines fields present in response.

215 |

216 | Default: view 217 |

218 |

One of: view, embed, edit

219 |
222 | 223 |
224 |
225 |
226 |
227 |

Update a Widget

228 |

Arguments

229 | 230 | 231 | 234 | 237 | 238 | 239 | 242 | 245 | 246 | 247 | 250 | 253 | 254 | 255 | 258 | 261 | 262 | 263 | 266 | 269 | 270 |
232 | id
233 |
235 |

Unique identifier for the widget.

236 |
240 | id_base
241 |
243 |

The type of the widget. Corresponds to ID in widget-types endpoint.

244 |
248 | sidebar
249 |
251 |

The sidebar the widget belongs to.

252 |
256 | instance
257 |
259 |

Instance settings of the widget, if supported.

260 |
264 | form_data
265 |
267 |

URL-encoded form data from the widget admin form. Used to update a widget that does not support instance. Write only.

268 |
271 | 272 |
273 |
274 |

Definition

275 | 276 | POST /wp/v2/widgets/<id> 277 | 278 |

Example Request

279 | 280 | 281 |
282 |
283 |
284 |
285 |

Delete a Widget

286 |

Arguments

287 | 288 | 289 | 292 | 295 | 296 |
290 | force
291 |
293 |

Whether to force removal of the widget, or move it to the inactive sidebar.

294 |
297 | 298 |
299 |
300 |

Definition

301 | 302 | DELETE /wp/v2/widgets/<id> 303 | 304 |

Example Request

305 | 306 | $ curl -X DELETE https://example.com/wp-json/wp/v2/widgets/<id> 307 |
308 |
309 |
310 | -------------------------------------------------------------------------------- /extending-the-rest-api/adding-rest-api-support-for-custom-content-types.md: -------------------------------------------------------------------------------- 1 | # Adding REST API Support For Custom Content Types 2 | 3 | The REST API can create routes for custom post types and custom taxonomies inside of the `wp/v2` namespace, using the same controllers as the default post type or taxonomy term controllers. Alternatively, you can use your own controllers and namespace. This document will cover using the default controllers for your custom content type's API routes. This is the easiest way and ensures the highest chance of compatibility with third parties. 4 | 5 | 6 | ## Registering A Custom Post Type With REST API Support 7 | 8 | When registering a custom post type, if you want it to be available via the REST API you should set `'show_in_rest' => true` in the arguments passed to `register_post_type`. Setting this argument to true will add a route in the `wp/v2` namespace. 9 | 10 | ```php 11 | /** 12 | * Register a book post type, with REST API support 13 | * 14 | * Based on example at: https://developer.wordpress.org/reference/functions/register_post_type 15 | */ 16 | add_action( 'init', 'my_book_cpt' ); 17 | function my_book_cpt() { 18 | $args = array( 19 | 'public' => true, 20 | 'show_in_rest' => true, 21 | 'label' => 'Books' 22 | ); 23 | register_post_type( 'book', $args ); 24 | } 25 | ``` 26 | 27 | You can optionally set the `rest_base` argument to change the base url, which will otherwise default to the post type's name. In the example below, "books" is used as the value of `rest_base`. This will make the URL for the route `wp-json/wp/v2/books` instead of `wp-json/wp/v2/book/`, which would have been the default. 28 | 29 | In addition, you can pass an argument for `rest_controller_class`. This class must be a subclass of `WP_REST_Controller`. By default, `WP_REST_Posts_Controller` is used as the controller. If you are using a custom controller, then you likely will not be within the `wp/v2` namespace. 30 | 31 | Here is an example of registering a post type, with full labels, support for the REST API, a customized rest_base, and explicit registry of the default controller: 32 | 33 | ```php 34 | /** 35 | * Register a book post type, with REST API support 36 | * 37 | * Based on example at: https://developer.wordpress.org/reference/functions/register_post_type 38 | */ 39 | add_action( 'init', 'my_book_cpt' ); 40 | function my_book_cpt() { 41 | $labels = array( 42 | 'name' => _x( 'Books', 'post type general name', 'your-plugin-textdomain' ), 43 | 'singular_name' => _x( 'Book', 'post type singular name', 'your-plugin-textdomain' ), 44 | 'menu_name' => _x( 'Books', 'admin menu', 'your-plugin-textdomain' ), 45 | 'name_admin_bar' => _x( 'Book', 'add new on admin bar', 'your-plugin-textdomain' ), 46 | 'add_new' => _x( 'Add New', 'book', 'your-plugin-textdomain' ), 47 | 'add_new_item' => __( 'Add New Book', 'your-plugin-textdomain' ), 48 | 'new_item' => __( 'New Book', 'your-plugin-textdomain' ), 49 | 'edit_item' => __( 'Edit Book', 'your-plugin-textdomain' ), 50 | 'view_item' => __( 'View Book', 'your-plugin-textdomain' ), 51 | 'all_items' => __( 'All Books', 'your-plugin-textdomain' ), 52 | 'search_items' => __( 'Search Books', 'your-plugin-textdomain' ), 53 | 'parent_item_colon' => __( 'Parent Books:', 'your-plugin-textdomain' ), 54 | 'not_found' => __( 'No books found.', 'your-plugin-textdomain' ), 55 | 'not_found_in_trash' => __( 'No books found in Trash.', 'your-plugin-textdomain' ) 56 | ); 57 | 58 | $args = array( 59 | 'labels' => $labels, 60 | 'description' => __( 'Description.', 'your-plugin-textdomain' ), 61 | 'public' => true, 62 | 'publicly_queryable' => true, 63 | 'show_ui' => true, 64 | 'show_in_menu' => true, 65 | 'query_var' => true, 66 | 'rewrite' => array( 'slug' => 'book' ), 67 | 'capability_type' => 'post', 68 | 'has_archive' => true, 69 | 'hierarchical' => false, 70 | 'menu_position' => null, 71 | 'show_in_rest' => true, 72 | 'rest_base' => 'books', 73 | 'rest_controller_class' => 'WP_REST_Posts_Controller', 74 | 'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ) 75 | ); 76 | 77 | register_post_type( 'book', $args ); 78 | } 79 | ``` 80 | 81 | If you are using a custom `rest_controller_class`, then the REST API is unable to automatically determine the route for a given post. In this case, you can use the `rest_route_for_post` filter to provide this information. This allows for your custom post type to be properly formatted in the Search endpoint and enables automated discovery links. 82 | 83 | ```php 84 | function my_plugin_rest_route_for_post( $route, $post ) { 85 | if ( $post->post_type === 'book' ) { 86 | $route = '/wp/v2/books/' . $post->ID; 87 | } 88 | 89 | return $route; 90 | } 91 | add_filter( 'rest_route_for_post', 'my_plugin_rest_route_for_post', 10, 2 ); 92 | ``` 93 | 94 | ## Registering A Custom Taxonomy With REST API Support 95 | 96 | Registering a custom taxonomy with REST API support is very similar to registering a custom post type: pass `'show_in_rest' => true` in the arguments passed to `register_taxonomy`. You may optionally pass `rest_base` to change the base url for the taxonomy's routes. 97 | 98 | The default controller for taxonomies is `WP_REST_Terms_Controller`. You may modify this with the `rest_controller_class` if you choose to use a custom controller. 99 | 100 | Here is an example of how to register a custom taxonomy with REST API support: 101 | 102 | ```php 103 | /** 104 | * Register a genre post type, with REST API support 105 | * 106 | * Based on example at: https://developer.wordpress.org/reference/functions/register_taxonomy/ 107 | */ 108 | add_action( 'init', 'my_book_taxonomy', 30 ); 109 | function my_book_taxonomy() { 110 | 111 | $labels = array( 112 | 'name' => _x( 'Genres', 'taxonomy general name' ), 113 | 'singular_name' => _x( 'Genre', 'taxonomy singular name' ), 114 | 'search_items' => __( 'Search Genres' ), 115 | 'all_items' => __( 'All Genres' ), 116 | 'parent_item' => __( 'Parent Genre' ), 117 | 'parent_item_colon' => __( 'Parent Genre:' ), 118 | 'edit_item' => __( 'Edit Genre' ), 119 | 'update_item' => __( 'Update Genre' ), 120 | 'add_new_item' => __( 'Add New Genre' ), 121 | 'new_item_name' => __( 'New Genre Name' ), 122 | 'menu_name' => __( 'Genre' ), 123 | ); 124 | 125 | $args = array( 126 | 'hierarchical' => true, 127 | 'labels' => $labels, 128 | 'show_ui' => true, 129 | 'show_admin_column' => true, 130 | 'query_var' => true, 131 | 'rewrite' => array( 'slug' => 'genre' ), 132 | 'show_in_rest' => true, 133 | 'rest_base' => 'genre', 134 | 'rest_controller_class' => 'WP_REST_Terms_Controller', 135 | ); 136 | 137 | register_taxonomy( 'genre', array( 'book' ), $args ); 138 | 139 | } 140 | ``` 141 | 142 | If you are using a custom `rest_controller_class`, then the REST API is unable to automatically determine the route for a given term. In this case, you can use the `rest_route_for_term` filter to provide this information. This allows for your custom taxonomy to be properly formatted in the Search endpoint and enables automated discovery links. 143 | 144 | ```php 145 | function my_plugin_rest_route_for_term( $route, $term ) { 146 | if ( $term->taxonomy === 'genre' ) { 147 | $route = '/wp/v2/genre/' . $term->term_id; 148 | } 149 | 150 | return $route; 151 | } 152 | add_filter( 'rest_route_for_term', 'my_plugin_rest_route_for_term', 10, 2 ); 153 | ``` 154 | 155 | ## Adding REST API Support To Existing Content Types 156 | 157 | If you need to add REST API support for a custom post type or custom taxonomy you do not control, for example a theme or plugin you are using, you can use the `register_post_type_args` filter hook that exists since WordPress version 4.6.0. 158 | 159 | ```php 160 | /** 161 | * Add REST API support to an already registered post type. 162 | */ 163 | add_filter( 'register_post_type_args', 'my_post_type_args', 10, 2 ); 164 | 165 | function my_post_type_args( $args, $post_type ) { 166 | 167 | if ( 'book' === $post_type ) { 168 | $args['show_in_rest'] = true; 169 | 170 | // Optionally customize the rest_base or rest_controller_class 171 | $args['rest_base'] = 'books'; 172 | $args['rest_controller_class'] = 'WP_REST_Posts_Controller'; 173 | } 174 | 175 | return $args; 176 | } 177 | ``` 178 | 179 | 180 | For custom taxonomies it is almost the same. You can use the `register_taxonomy_args` filter that exists since WordPress version 4.4.0. 181 | 182 | ```php 183 | /** 184 | * Add REST API support to an already registered taxonomy. 185 | */ 186 | add_filter( 'register_taxonomy_args', 'my_taxonomy_args', 10, 2 ); 187 | 188 | function my_taxonomy_args( $args, $taxonomy_name ) { 189 | 190 | if ( 'genre' === $taxonomy_name ) { 191 | $args['show_in_rest'] = true; 192 | 193 | // Optionally customize the rest_base or rest_controller_class 194 | $args['rest_base'] = 'genres'; 195 | $args['rest_controller_class'] = 'WP_REST_Terms_Controller'; 196 | } 197 | 198 | return $args; 199 | } 200 | ``` 201 | 202 | ## Custom Link Relationships 203 | 204 | Taxonomies & custom post types have a built-in association within WordPress, but what if you want to establish a link between two custom post types? This is not supported formally within WordPress itself, but we can create our own connections between arbitrary content types using the `_link` relation. 205 | -------------------------------------------------------------------------------- /reference/application-passwords.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Application Passwords 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a application password record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 24 | 25 | 26 | 29 | 37 | 38 | 39 | 42 | 48 | 49 | 50 | 53 | 60 | 61 | 62 | 65 | 74 | 75 | 76 | 79 | 88 | 89 | 90 | 93 | 102 | 103 |
13 | uuid 14 | 16 |

The unique identifier for the application password.

17 |

18 | JSON data type: string, 19 | Format: uuid 20 |

21 |

Read only

22 |

Context: view, edit, embed

23 |
27 | app_id 28 | 30 |

A UUID provided by the application to uniquely identify it. It is recommended to use an UUID v5 with the URL or DNS namespace.

31 |

32 | JSON data type: string, 33 | Format: uuid 34 |

35 |

Context: view, edit, embed

36 |
40 | name 41 | 43 |

The name of the application password.

44 |

45 | JSON data type: string

46 |

Context: view, edit, embed

47 |
51 | password 52 | 54 |

The generated password. Only available after adding an application.

55 |

56 | JSON data type: string

57 |

Read only

58 |

Context: edit

59 |
63 | created 64 | 66 |

The GMT date the application password was created.

67 |

68 | JSON data type: string, 69 | Format: datetime (details) 70 |

71 |

Read only

72 |

Context: view, edit

73 |
77 | last_used 78 | 80 |

The GMT date the application password was last used.

81 |

82 | JSON data type: string or null, 83 | Format: datetime (details) 84 |

85 |

Read only

86 |

Context: view, edit

87 |
91 | last_ip 92 | 94 |

The IP address the application password was last used by.

95 |

96 | JSON data type: string or null, 97 | Format: ip 98 |

99 |

Read only

100 |

Context: view, edit

101 |
104 | 105 |
106 |
107 | 108 |
109 |
110 |

Retrieve a Application Password

111 | 112 |

Definition & Example Request

113 | 114 | GET /wp/v2/users/<user_id>)/application-passwords 115 | 116 |

Query this endpoint to retrieve a specific application password record.

117 | 118 | $ curl https://example.com/wp-json/wp/v2/users/<user_id>)/application-passwords 119 |
120 |
121 |

Arguments

122 | 123 | 124 | 127 | 134 | 135 |
125 | context
126 |
128 |

Scope under which the request is made; determines fields present in response.

129 |

130 | Default: view 131 |

132 |

One of: view, embed, edit

133 |
136 | 137 |
138 |
139 |
140 |
141 |

Create a Application Password

142 |

Arguments

143 | 144 | 145 | 148 | 151 | 152 | 153 | 156 | 162 | 163 |
146 | app_id
147 |
149 |

A UUID provided by the application to uniquely identify it. It is recommended to use an UUID v5 with the URL or DNS namespace.

150 |
154 | name
155 |
157 |

The name of the application password.

158 |

159 | Required: 1 160 |

161 |
164 | 165 |
166 |
167 |

Definition

168 | 169 | POST /wp/v2/users/<user_id>)/application-passwords 170 |
171 |
172 |
173 |
174 |

Delete a Application Password

175 |

There are no arguments for this endpoint.

176 | 177 |
178 |
179 |

Definition

180 | 181 | DELETE /wp/v2/users/<user_id>)/application-passwords 182 | 183 |

Example Request

184 | 185 | $ curl -X DELETE https://example.com/wp-json/wp/v2/users/<user_id>)/application-passwords 186 |
187 |
188 |
189 |
190 |

Retrieve a Application Password

191 | 192 |

Definition & Example Request

193 | 194 | GET /wp/v2/users/<user_id>)/application-passwords/introspect 195 | 196 |

Query this endpoint to retrieve a specific application password record.

197 | 198 | $ curl https://example.com/wp-json/wp/v2/users/<user_id>)/application-passwords/introspect 199 |
200 |
201 |

Arguments

202 | 203 | 204 | 207 | 214 | 215 |
205 | context
206 |
208 |

Scope under which the request is made; determines fields present in response.

209 |

210 | Default: view 211 |

212 |

One of: view, embed, edit

213 |
216 | 217 |
218 |
219 |
220 |
221 |

Retrieve a Application Password

222 | 223 |

Definition & Example Request

224 | 225 | GET /wp/v2/users/<user_id>)/application-passwords/<uuid> 226 | 227 |

Query this endpoint to retrieve a specific application password record.

228 | 229 | $ curl https://example.com/wp-json/wp/v2/users/<user_id>)/application-passwords/<uuid> 230 |
231 |
232 |

Arguments

233 | 234 | 235 | 238 | 245 | 246 |
236 | context
237 |
239 |

Scope under which the request is made; determines fields present in response.

240 |

241 | Default: view 242 |

243 |

One of: view, embed, edit

244 |
247 | 248 |
249 |
250 |
251 |
252 |

Update a Application Password

253 |

Arguments

254 | 255 | 256 | 259 | 262 | 263 | 264 | 267 | 270 | 271 |
257 | app_id
258 |
260 |

A UUID provided by the application to uniquely identify it. It is recommended to use an UUID v5 with the URL or DNS namespace.

261 |
265 | name
266 |
268 |

The name of the application password.

269 |
272 | 273 |
274 |
275 |

Definition

276 | 277 | POST /wp/v2/users/<user_id>)/application-passwords/<uuid> 278 | 279 |

Example Request

280 | 281 | 282 |
283 |
284 |
285 |
286 |

Delete a Application Password

287 |

There are no arguments for this endpoint.

288 | 289 |
290 |
291 |

Definition

292 | 293 | DELETE /wp/v2/users/<user_id>)/application-passwords/<uuid> 294 | 295 |

Example Request

296 | 297 | $ curl -X DELETE https://example.com/wp-json/wp/v2/users/<user_id>)/application-passwords/<uuid> 298 |
299 |
300 |
301 | -------------------------------------------------------------------------------- /reference/plugins.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Plugins 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a plugin record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 22 | 23 | 24 | 27 | 34 | 35 | 36 | 39 | 46 | 47 | 48 | 51 | 60 | 61 | 62 | 65 | 72 | 73 | 74 | 77 | 86 | 87 | 88 | 91 | 98 | 99 | 100 | 103 | 110 | 111 | 112 | 115 | 122 | 123 | 124 | 127 | 134 | 135 | 136 | 139 | 146 | 147 | 148 | 151 | 158 | 159 |
13 | plugin 14 | 16 |

The plugin file.

17 |

18 | JSON data type: string

19 |

Read only

20 |

Context: view, edit, embed

21 |
25 | status 26 | 28 |

The plugin activation status.

29 |

30 | JSON data type: string

31 |

Context: view, edit, embed

32 |

One of: inactive, active

33 |
37 | name 38 | 40 |

The plugin name.

41 |

42 | JSON data type: string

43 |

Read only

44 |

Context: view, edit, embed

45 |
49 | plugin_uri 50 | 52 |

The plugin's website address.

53 |

54 | JSON data type: string, 55 | Format: uri 56 |

57 |

Read only

58 |

Context: view, edit

59 |
63 | author 64 | 66 |

The plugin author.

67 |

68 | JSON data type: object

69 |

Read only

70 |

Context: view, edit

71 |
75 | author_uri 76 | 78 |

Plugin author's website address.

79 |

80 | JSON data type: string, 81 | Format: uri 82 |

83 |

Read only

84 |

Context: view, edit

85 |
89 | description 90 | 92 |

The plugin description.

93 |

94 | JSON data type: object

95 |

Read only

96 |

Context: view, edit

97 |
101 | version 102 | 104 |

The plugin version number.

105 |

106 | JSON data type: string

107 |

Read only

108 |

Context: view, edit

109 |
113 | network_only 114 | 116 |

Whether the plugin can only be activated network-wide.

117 |

118 | JSON data type: boolean

119 |

Read only

120 |

Context: view, edit, embed

121 |
125 | requires_wp 126 | 128 |

Minimum required version of WordPress.

129 |

130 | JSON data type: string

131 |

Read only

132 |

Context: view, edit, embed

133 |
137 | requires_php 138 | 140 |

Minimum required version of PHP.

141 |

142 | JSON data type: string

143 |

Read only

144 |

Context: view, edit, embed

145 |
149 | textdomain 150 | 152 |

The plugin's text domain.

153 |

154 | JSON data type: string

155 |

Read only

156 |

Context: view, edit

157 |
160 | 161 |
162 |
163 | 164 |
165 |
166 |

Retrieve a Plugin

167 | 168 |

Definition & Example Request

169 | 170 | GET /wp/v2/plugins 171 | 172 |

Query this endpoint to retrieve a specific plugin record.

173 | 174 | $ curl https://example.com/wp-json/wp/v2/plugins 175 |
176 |
177 |

Arguments

178 | 179 | 180 | 183 | 190 | 191 | 192 | 195 | 198 | 199 | 200 | 203 | 206 | 207 |
181 | context
182 |
184 |

Scope under which the request is made; determines fields present in response.

185 |

186 | Default: view 187 |

188 |

One of: view, embed, edit

189 |
193 | search
194 |
196 |

Limit results to those matching a string.

197 |
201 | status
202 |
204 |

Limits results to plugins with the given status.

205 |
208 | 209 |
210 |
211 |
212 |
213 |

Create a Plugin

214 |

Arguments

215 | 216 | 217 | 220 | 226 | 227 | 228 | 231 | 238 | 239 |
218 | slug
219 |
221 |

WordPress.org plugin directory slug.

222 |

223 | Required: 1 224 |

225 |
229 | status
230 |
232 |

The plugin activation status.

233 |

234 | Default: inactive 235 |

236 |

One of: inactive, active

237 |
240 | 241 |
242 |
243 |

Definition

244 | 245 | POST /wp/v2/plugins 246 |
247 |
248 |
249 |
250 |

Retrieve a Plugin

251 | 252 |

Definition & Example Request

253 | 254 | GET /wp/v2/plugins/<plugin>?) 255 | 256 |

Query this endpoint to retrieve a specific plugin record.

257 | 258 | $ curl https://example.com/wp-json/wp/v2/plugins/<plugin>?) 259 |
260 |
261 |

Arguments

262 | 263 | 264 | 267 | 274 | 275 | 276 | 279 | 281 | 282 |
265 | context
266 |
268 |

Scope under which the request is made; determines fields present in response.

269 |

270 | Default: view 271 |

272 |

One of: view, embed, edit

273 |
277 | plugin
278 |
280 |
283 | 284 |
285 |
286 |
287 |
288 |

Update a Plugin

289 |

Arguments

290 | 291 | 292 | 295 | 302 | 303 | 304 | 307 | 309 | 310 | 311 | 314 | 318 | 319 |
293 | context
294 |
296 |

Scope under which the request is made; determines fields present in response.

297 |

298 | Default: view 299 |

300 |

One of: view, embed, edit

301 |
305 | plugin
306 |
308 |
312 | status
313 |
315 |

The plugin activation status.

316 |

One of: inactive, active

317 |
320 | 321 |
322 |
323 |

Definition

324 | 325 | POST /wp/v2/plugins/<plugin>?) 326 | 327 |

Example Request

328 | 329 | 330 |
331 |
332 |
333 |
334 |

Delete a Plugin

335 |

Arguments

336 | 337 | 338 | 341 | 348 | 349 | 350 | 353 | 355 | 356 |
339 | context
340 |
342 |

Scope under which the request is made; determines fields present in response.

343 |

344 | Default: view 345 |

346 |

One of: view, embed, edit

347 |
351 | plugin
352 |
354 |
357 | 358 |
359 |
360 |

Definition

361 | 362 | DELETE /wp/v2/plugins/<plugin>?) 363 | 364 |

Example Request

365 | 366 | $ curl -X DELETE https://example.com/wp-json/wp/v2/plugins/<plugin>?) 367 |
368 |
369 |
370 | -------------------------------------------------------------------------------- /reference/nav_menu_item-revisions.md: -------------------------------------------------------------------------------- 1 | --- 2 | --- 3 | 4 | # Nav_Menu_Item Revisions 5 | 6 |
7 |
8 |

Schema

9 |

The schema defines all the fields that exist within a nav_menu_item revision record. Any response from these endpoints can be expected to contain the fields below unless the `_filter` query parameter is used or the schema field only appears in a specific context.

10 | 11 | 12 | 15 | 21 | 22 | 23 | 26 | 34 | 35 | 36 | 39 | 47 | 48 | 49 | 52 | 58 | 59 | 60 | 63 | 69 | 70 | 71 | 74 | 82 | 83 | 84 | 87 | 95 | 96 | 97 | 100 | 106 | 107 | 108 | 111 | 117 | 118 | 119 | 122 | 128 | 129 | 130 | 133 | 142 | 143 |
13 | author 14 | 16 |

The ID for the author of the revision.

17 |

18 | JSON data type: integer

19 |

Context: view, edit, embed

20 |
24 | date 25 | 27 |

The date the revision was published, in the site's timezone.

28 |

29 | JSON data type: string, 30 | Format: datetime (details) 31 |

32 |

Context: view, edit, embed

33 |
37 | date_gmt 38 | 40 |

The date the revision was published, as GMT.

41 |

42 | JSON data type: string, 43 | Format: datetime (details) 44 |

45 |

Context: view, edit

46 |
50 | guid 51 | 53 |

GUID for the revision, as it exists in the database.

54 |

55 | JSON data type: string

56 |

Context: view, edit

57 |
61 | id 62 | 64 |

Unique identifier for the revision.

65 |

66 | JSON data type: integer

67 |

Context: view, edit, embed

68 |
72 | modified 73 | 75 |

The date the revision was last modified, in the site's timezone.

76 |

77 | JSON data type: string, 78 | Format: datetime (details) 79 |

80 |

Context: view, edit

81 |
85 | modified_gmt 86 | 88 |

The date the revision was last modified, as GMT.

89 |

90 | JSON data type: string, 91 | Format: datetime (details) 92 |

93 |

Context: view, edit

94 |
98 | parent 99 | 101 |

The ID for the parent of the revision.

102 |

103 | JSON data type: integer

104 |

Context: view, edit, embed

105 |
109 | slug 110 | 112 |

An alphanumeric identifier for the revision unique to its type.

113 |

114 | JSON data type: string

115 |

Context: view, edit, embed

116 |
120 | title 121 | 123 |

The title for the object.

124 |

125 | JSON data type: string or object

126 |

Context: view, edit, embed

127 |
144 | 145 |
146 |
147 | 148 |
149 |
150 |

Retrieve a Nav_Menu_Item Revision

151 | 152 |

Definition & Example Request

153 | 154 | GET /wp/v2/menu-items/<id>/autosaves 155 | 156 |

Query this endpoint to retrieve a specific nav_menu_item revision record.

157 | 158 | $ curl https://example.com/wp-json/wp/v2/menu-items/<id>/autosaves 159 |
160 |
161 |

Arguments

162 | 163 | 164 | 167 | 170 | 171 | 172 | 175 | 182 | 183 |
165 | parent
166 |
168 |

The ID for the parent of the autosave.

169 |
173 | context
174 |
176 |

Scope under which the request is made; determines fields present in response.

177 |

178 | Default: view 179 |

180 |

One of: view, embed, edit

181 |
184 | 185 |
186 |
187 |
188 |
189 |

Create a Nav_Menu_Item Revision

190 |

Arguments

191 | 192 | 193 | 196 | 199 | 200 | 201 | 204 | 207 | 208 | 209 | 212 | 216 | 217 | 218 | 221 | 225 | 226 | 227 | 230 | 233 | 234 | 235 | 238 | 241 | 242 | 243 | 246 | 249 | 250 | 251 | 254 | 257 | 258 | 259 | 262 | 265 | 266 | 267 | 270 | 273 | 274 | 275 | 278 | 282 | 283 | 284 | 287 | 290 | 291 | 292 | 295 | 298 | 299 | 300 | 303 | 306 | 307 | 308 | 311 | 314 | 315 |
194 | parent
195 |
197 |

The ID for the parent of the object.

198 |
202 | title
203 |
205 |

The title for the object.

206 |
210 | type
211 |
213 |

The family of objects originally represented, such as "post_type" or "taxonomy".

214 |

One of: taxonomy, post_type, post_type_archive, custom

215 |
219 | status
220 |
222 |

A named status for the object.

223 |

One of: publish, future, draft, pending, private

224 |
228 | attr_title
229 |
231 |

Text for the title attribute of the link element for this menu item.

232 |
236 | classes
237 |
239 |

Class names for the link element of this menu item.

240 |
244 | description
245 |
247 |

The description of this menu item.

248 |
252 | menu_order
253 |
255 |

The DB ID of the nav_menu_item that is this item's menu parent, if any, otherwise 0.

256 |
260 | object
261 |
263 |

The type of object originally represented, such as "category", "post", or "attachment".

264 |
268 | object_id
269 |
271 |

The database ID of the original object this menu item represents, for example the ID for posts or the term_id for categories.

272 |
276 | target
277 |
279 |

The target attribute of the link element for this menu item.

280 |

One of: _blank,

281 |
285 | url
286 |
288 |

The URL to which this menu item points.

289 |
293 | xfn
294 |
296 |

The XFN relationship expressed in the link of this menu item.

297 |
301 | menus
302 |
304 |

The terms assigned to the object in the nav_menu taxonomy.

305 |
309 | meta
310 |
312 |

Meta fields.

313 |
316 | 317 |
318 |
319 |

Definition

320 | 321 | POST /wp/v2/menu-items/<id>/autosaves 322 |
323 |
324 |
325 |
326 |

Retrieve a Nav_Menu_Item Revision

327 | 328 |

Definition & Example Request

329 | 330 | GET /wp/v2/menu-items/<parent>/autosaves/<id> 331 | 332 |

Query this endpoint to retrieve a specific nav_menu_item revision record.

333 | 334 | $ curl https://example.com/wp-json/wp/v2/menu-items/<parent>/autosaves/<id> 335 |
336 |
337 |

Arguments

338 | 339 | 340 | 343 | 346 | 347 | 348 | 351 | 354 | 355 | 356 | 359 | 366 | 367 |
341 | parent
342 |
344 |

The ID for the parent of the autosave.

345 |
349 | id
350 |
352 |

The ID for the autosave.

353 |
357 | context
358 |
360 |

Scope under which the request is made; determines fields present in response.

361 |

362 | Default: view 363 |

364 |

One of: view, embed, edit

365 |
368 | 369 |
370 |
371 |
372 | --------------------------------------------------------------------------------