A more secure REST API

Because privacy and security are important to users across the internet, many services have begun to encrypt the connection between a user’s browser and their servers. The use of SSL (or TLS) largely eliminates the likelihood that a “man-in-the-middle” is able to monitor a user’s activities on the web. To this end, WordPress.com is joining the likes of Google and Facebook in encrypting all of the traffic sent across our network. We are currently in the process of forcing many of our services to be accessible through HTTPS exclusively.

It was previously possible to access the WordPress.com/Jetpack JSON API through HTTP only for unauthenticated requests. As part of the SSL transition, all public-api.wordpress.com endpoints are now accessible via HTTPS only. Any requests made to the HTTP version of the URL will now 301 redirect to the HTTPS version.

What does this mean for you?

For the majority of our API consumers, this won’t require any change as you are likely already using the HTTPS URLs with authenticated endpoints. If you are not, now is the time to update your API calls to the secure URLs.

By making this change, we’re helping make the web a more secure place for our users.

As always, If you have any questions about the API, don’t hesitate to comment below or reach out to us via our developer contact form.

Authentication improvements for testing your apps

We’ve just made it easier for developers to authenticate and test API calls with their own applications.

As the client owner, you can now authenticate with the password grant_type, allowing you to skip the authorization step of authenticating, and logging in with your WordPress.com username and password. You can also gain the global scope so that you no longer need to request authentication for each blog you wish to test your code with.

This is especially useful to contributors of the WordPress Android and iOS apps, which previously required special whitelisting on our part.

Here’s an example of how you can get started with using both these features:

Note that if you are using 2-step authentication (highly recommended) you will need to create an application password to be able to use the password grant_type.

$curl = curl_init( "https://public-api.wordpress.com/oauth2/token" );
curl_setopt( $curl, CURLOPT_POST, true );
curl_setopt( $curl, CURLOPT_POSTFIELDS, array(
    'client_id' => your_client_id,
    'client_secret' => your_client_secret_key,
    'grant_type' => 'password'
    'username' => your_wpcom_username,
    'password' => your_wpcom_password,
) );
curl_setopt( $curl, CURLOPT_RETURNTRANSFER, 1);
$auth = curl_exec( $curl );
$auth = json_decode($auth);
$access_key = $auth->access_token;

As noted above, these are only available to you as the owner of the application, and not to any other user. This is meant for testing purposes only.

You can review existing authentication methods here.

If you have any questions, please drop them in the comments or use our contact form to reach us.

A brand new Developer Site

As you may have noticed, we’ve just relaunched the WordPress.com Developer site (the very one you’re reading right now!) with a brand new look and feel!

We’ve rebranded the site to match the overall WordPress.com aesthetic as well as to align with the new user management and insights sections we launched just a few weeks ago.

The goal of the redesign was not only to modernize the site but make it easier for you, our partners and third-party developers to find the information you are looking for. In addition, we’ve reviewed all of our existing documentation and past blog posts to make sure the information is accurate and relevant.

Over the next few months, you’ll see more updates to the site and more frequent blog posts from our team.

I’d personally like to thank the team that worked on the relaunch with me: Raanan, Kelly, Kat, Justin, and Stephane.

If you’d like to let us know what you think of the new site, report a bug, or have suggestions for future improvements, please comment below, tweet at us @AutomatticEng or contact us privately.

Custom post type and metadata support in the REST API

We’ve recently made some updates to the REST API which is available here on WordPress.com and for any Jetpack-enabled site that has the REST API module activated. The API now has full read and write support for custom post types and post metadata.

You can specify a post’s post type when you create or edit it. If you’re fetching a single post, you will receive its post type in the response. Of course, you can also specify a post type when fetching a series of posts. In all cases the parameter to use or look out for is type.

You can also query posts by metadata using the new meta_key and meta_value parameters. You can add, update, delete or retrieve a post’s metadata when creating, editing or getting a single post, using the new metadata parameter which accepts an array of metadata keys, ids, previous_values, values and operations, based on the operation you are trying to perform.

In order to enable your custom post types to work with the REST API on your Jetpack enabled sites, you will need to whitelist them using the new rest_api_allowed_post_types filter available in Jetpack, which is a simple array of the post type names that should be allowed to work with the API.

All metadata keys can be accessed and edited by users with the edit_post_meta (used for editing and viewing), add_post_meta and delete_post_meta capabilities as appropriate for each operation. We’ve also added a filter rest_api_allowed_public_metadata that allows you to specifically whitelist certain metadata keys to be accessed (but not modified) by any user (even anonymous).

Here’s a quick rundown. If the user performing the request is unauthenticated, they will not be able to add, edit or delete any metadata; they will only be able to read specifically whitelisted metadata keys.

If the user performing the request is authenticated and has the above listed capabilities, they will be able to read, add, edit or delete any metadata, even if it is not whitelisted.

In order to make it easier for you to add support for custom post types and metadata in your own plugins and themes, we’ve also added a third filter jetpack_rest_api_compat in the main Jetpack file, which allows you to load additional files where you can then add all of your REST API compatibility code, using the filters above.

Because we love bbPress, we’ve bundled support for bbPress and the REST API directly into Jetpack, so that you can read, write and edit bbPress forums, topics and replies right out of the box. You can also use this file as an example on how to bundle support in your own plugins or themes.

Check out our documentation, create an app, and get started today!

Let us know if you have any questions in the comments below.