{"id":5165,"date":"2026-09-10T13:27:49","date_gmt":"2026-09-10T10:27:49","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5165"},"modified":"2026-09-10T06:17:22","modified_gmt":"2026-09-10T03:17:22","slug":"wordpress-rest-api-uses-authentication-security","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/wordpress-rest-api-uses-authentication-security\/","title":{"rendered":"WordPress REST API Explained: Uses, Authentication and Security"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_is_the_WordPress_REST_API_used_for\"><span class=\"toc_number toc_depth_1\">1.<\/span> What is the WordPress REST API used for?<\/a><\/li><li><a href=\"#How_requests_and_responses_work\"><span class=\"toc_number toc_depth_1\">2.<\/span> How requests and responses work<\/a><\/li><li><a href=\"#What_people_build_with_the_API\"><span class=\"toc_number toc_depth_1\">3.<\/span> What people build with the API<\/a><\/li><li><a href=\"#Reading_data_with_the_WordPress_REST_API\"><span class=\"toc_number toc_depth_1\">4.<\/span> Reading data with the WordPress REST API<\/a><ul><li><a href=\"#Filtering_searching_and_pagination\"><span class=\"toc_number toc_depth_2\">4.1.<\/span> Filtering, searching, and pagination<\/a><\/li><li><a href=\"#Content_status_and_the_context_parameter\"><span class=\"toc_number toc_depth_2\">4.2.<\/span> Content status and the context parameter<\/a><\/li><\/ul><\/li><li><a href=\"#Authentication_methods\"><span class=\"toc_number toc_depth_1\">5.<\/span> Authentication methods<\/a><ul><li><a href=\"#Cookie_and_nonce_authentication_for_logged-in_sessions\"><span class=\"toc_number toc_depth_2\">5.1.<\/span> Cookie and nonce authentication for logged-in sessions<\/a><\/li><li><a href=\"#Application_Passwords\"><span class=\"toc_number toc_depth_2\">5.2.<\/span> Application Passwords<\/a><\/li><li><a href=\"#When_should_you_consider_JWT_or_OAuth\"><span class=\"toc_number toc_depth_2\">5.3.<\/span> When should you consider JWT or OAuth?<\/a><\/li><\/ul><\/li><li><a href=\"#Writing_a_custom_REST_endpoint_safely\"><span class=\"toc_number toc_depth_1\">6.<\/span> Writing a custom REST endpoint safely<\/a><ul><li><a href=\"#Input_validation_and_output_sanitization\"><span class=\"toc_number toc_depth_2\">6.1.<\/span> Input validation and output sanitization<\/a><\/li><li><a href=\"#Nonces_CORS_and_HTTPS\"><span class=\"toc_number toc_depth_2\">6.2.<\/span> Nonces, CORS, and HTTPS<\/a><\/li><\/ul><\/li><li><a href=\"#Should_you_disable_or_protect_the_REST_API\"><span class=\"toc_number toc_depth_1\">7.<\/span> Should you disable or protect the REST API?<\/a><\/li><li><a href=\"#Performance_and_operations\"><span class=\"toc_number toc_depth_1\">8.<\/span> Performance and operations<\/a><\/li><li><a href=\"#My_pre-launch_checklist\"><span class=\"toc_number toc_depth_1\">9.<\/span> My pre-launch checklist<\/a><\/li><li><a href=\"#Frequently_asked_questions\"><span class=\"toc_number toc_depth_1\">10.<\/span> Frequently asked questions<\/a><ul><li><a href=\"#Is_the_WordPress_REST_API_public\"><span class=\"toc_number toc_depth_2\">10.1.<\/span> Is the WordPress REST API public?<\/a><\/li><li><a href=\"#Should_the_WordPress_REST_API_be_disabled\"><span class=\"toc_number toc_depth_2\">10.2.<\/span> Should the WordPress REST API be disabled?<\/a><\/li><li><a href=\"#Do_you_need_a_plugin_to_use_the_REST_API\"><span class=\"toc_number toc_depth_2\">10.3.<\/span> Do you need a plugin to use the REST API?<\/a><\/li><li><a href=\"#Does_the_REST_API_slow_down_a_site\"><span class=\"toc_number toc_depth_2\">10.4.<\/span> Does the REST API slow down a site?<\/a><\/li><\/ul><\/li><\/ul><\/div>\n<h2><span id=\"What_is_the_WordPress_REST_API_used_for\">What is the WordPress REST API used for?<\/span><\/h2>\n<p>A support ticket that arrives late at night often starts with the same worry: &#8220;The REST API is visible. Has the site been hacked?&#8221; Most of the time, no. WordPress exposing public posts as JSON is expected behavior. The useful questions are which data is exposed and whether endpoints that change data are protected.<\/p>\n<p>I use the WordPress REST API as a way to access site data over HTTP without opening the WordPress dashboard. A client can read a post, create content, update a product, or send information to another application.<\/p>\n<p>Let me put it this way: the dashboard is the familiar interface for working with WordPress. The REST API is another controlled door into selected resources. The door exists, but it should not open every room for every visitor.<\/p>\n<p>A standard REST API URL usually looks like this:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">https:\/\/example.com\/wp-json\/wp\/v2\/posts<\/code><\/pre>\n<p>This endpoint returns the site&#8217;s posts. <code>\/wp\/v2\/pages<\/code> represents pages, <code>\/wp\/v2\/media<\/code> represents media files, and, when WooCommerce is installed, <code>\/wc\/v3\/products<\/code> represents products when the request is authenticated correctly.<\/p>\n<p>I once had a customer see this URL for the first time and assume the site had been compromised. Listing public posts as JSON is normal on most WordPress installations. The part that deserves investigation is an unauthorized response containing private data such as customer addresses, internal notes, or product costs.<\/p>\n<h2><span id=\"How_requests_and_responses_work\">How requests and responses work<\/span><\/h2>\n<p>The REST API works with resources. A post, page, user, or media file is a resource, while the HTTP method describes the operation. WordPress core commonly uses <code>POST<\/code> for both creating and updating resources, so the exact endpoint documentation matters.<\/p>\n<table>\n<thead>\n<tr>\n<th>HTTP method<\/th>\n<th>Typical use<\/th>\n<th>Authentication<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>GET<\/td>\n<td>Read and list data<\/td>\n<td>Usually not required for public content<\/td>\n<\/tr>\n<tr>\n<td>POST<\/td>\n<td>Create or update a resource<\/td>\n<td>Required for protected resources<\/td>\n<\/tr>\n<tr>\n<td>DELETE<\/td>\n<td>Delete a resource<\/td>\n<td>Required<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>For example, this request returns the latest posts:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl -s &#039;https:\/\/example.com\/wp-json\/wp\/v2\/posts?per_page=3&amp;_fields=id,date,link,title&#039;<\/code><\/pre>\n<p><code>per_page=3<\/code> asks for three records. <code>_fields<\/code> leaves unnecessary fields out of the response. Smaller responses help integrations that run frequently, although they do not remove the database work required to find the records.<\/p>\n<p>WordPress returns the total record count in HTTP headers. <code>X-WP-Total<\/code> shows the total number of records, while <code>X-WP-TotalPages<\/code> shows the number of result pages. When I move a large content archive, I do not inspect only the JSON body; I check these headers too.<\/p>\n<p>To request one post by its ID:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl -s &#039;https:\/\/example.com\/wp-json\/wp\/v2\/posts\/123&#039;<\/code><\/pre>\n<p><code>123<\/code> is the post ID. If the ID does not exist, or the resource is not published and the request is unauthenticated, you may receive a 404-style REST error. A failed REST API URL does not automatically mean the hosting service is down. Permalink rules, a security plugin, or a web server rule can affect the request.<\/p>\n<h2><span id=\"What_people_build_with_the_API\">What people build with the API<\/span><\/h2>\n<p>The WordPress REST API lets you separate the system that produces content from the interface that displays it. This is often called headless WordPress. Your whole site does not have to be headless because one integration uses the API.<\/p>\n<ul>\n<li>Providing posts, categories, and media information to a mobile application.<\/li>\n<li>Displaying WordPress content in a React, Vue, or another JavaScript interface.<\/li>\n<li>Synchronizing content and product data with an external CRM, ERP, or inventory system.<\/li>\n<li>Automating repetitive tasks for content editors.<\/li>\n<li>Collecting announcements from several WordPress sites in one shared interface.<\/li>\n<li>Listing or updating WooCommerce products in an authorized internal application.<\/li>\n<\/ul>\n<p>You can also feed content into SEO and measurement systems. Fetching data through an API does not mean Google will automatically use that data in search results. The integration and the search engine&#8217;s behavior are separate matters. For another way to verify a measurement setup, see <a href=\"https:\/\/www.dchost.com\/blog\/en\/ga4-setup-guide-track-website-data-step-by-step\/\">GA4 Setup Guide: Track Your Website Data Step by Step<\/a>.<\/p>\n<p>WooCommerce product and order endpoints need extra care. A product&#8217;s public name and price do not belong to the same security class as a customer&#8217;s address. I define the fields an integration needs instead of returning a complete object by default.<\/p>\n<h2><span id=\"Reading_data_with_the_WordPress_REST_API\">Reading data with the WordPress REST API<\/span><\/h2>\n<h3><span id=\"Filtering_searching_and_pagination\">Filtering, searching, and pagination<\/span><\/h3>\n<p>Query parameters let you narrow a response. This request asks for the second page of posts containing a search term and assigned to a particular category:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl -s &#039;https:\/\/example.com\/wp-json\/wp\/v2\/posts?search=linux&amp;categories=7&amp;per_page=10&amp;page=2&#039;<\/code><\/pre>\n<p>If <code>page<\/code> is higher than the available page count, the API can return an error. Automation needs to expect that response rather than treating every non-200 result as a server failure.<\/p>\n<p>Use <code>_fields<\/code> to select only what you need:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl -s &#039;https:\/\/example.com\/wp-json\/wp\/v2\/posts?per_page=5&amp;_fields=id,slug,title.rendered,excerpt.rendered&#039;<\/code><\/pre>\n<p>Fields containing HTML appear as <code>title.rendered<\/code> or <code>excerpt.rendered<\/code>. If another interface displays them, do not treat the raw response as trusted markup. Escape or sanitize it in the layer that renders it.<\/p>\n<h3><span id=\"Content_status_and_the_context_parameter\">Content status and the context parameter<\/span><\/h3>\n<p>Unauthenticated requests generally use the <code>view<\/code> context. Authorized users can request the <code>edit<\/code> context, which may return additional fields. Drafts, private fields, and editing information can appear there.<\/p>\n<p>Using <code>context=edit<\/code> does not grant permission by itself. WordPress still checks whether the requesting user can edit the resource. Hiding private fields only in the client is a mistake I see too often.<\/p>\n<h2><span id=\"Authentication_methods\">Authentication methods<\/span><\/h2>\n<h3><span id=\"Cookie_and_nonce_authentication_for_logged-in_sessions\">Cookie and nonce authentication for logged-in sessions<\/span><\/h3>\n<p>A user logged into the WordPress dashboard can send REST API requests from JavaScript running in the browser. WordPress uses the session cookie together with a <code>wp_rest<\/code> nonce. The nonce helps confirm that the request belongs to the expected WordPress session.<\/p>\n<p>This works well for screens inside the site. It is not the right way to build a long-running integration on an external server. I once found a test integration carrying a copied browser cookie long after the original debugging session had ended. We revoked the session immediately and replaced it with a dedicated credential.<\/p>\n<h3><span id=\"Application_Passwords\">Application Passwords<\/span><\/h3>\n<p>WordPress includes Application Passwords for connecting an application to a user account. Send the credential over HTTPS using Basic Authentication:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl --user &#039;api-user:application-password&#039; \\\n  -H &#039;Content-Type: application\/json&#039; \\\n  &#039;https:\/\/example.com\/wp-json\/wp\/v2\/users\/me&#039;<\/code><\/pre>\n<p>The response shows which user authenticated the request. Do not share an Application Password like a normal account password, commit it to a repository, or attach it to an administrator account when a less privileged user will do.<\/p>\n<p>A request to create a post might look like this:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl --user &#039;api-user:application-password&#039; \\\n  -X POST &#039;https:\/\/example.com\/wp-json\/wp\/v2\/posts&#039; \\\n  -H &#039;Content-Type: application\/json&#039; \\\n  -d &#039;{&quot;title&quot;:&quot;Draft created through the API&quot;,&quot;content&quot;:&quot;Content goes here&quot;,&quot;status&quot;:&quot;draft&quot;}&#039;<\/code><\/pre>\n<p>This creates a draft post. Before running it on a live site, check the target site, user, and <code>status<\/code> value. A POST sent to the wrong endpoint is not a reversible preview.<\/p>\n<h3><span id=\"When_should_you_consider_JWT_or_OAuth\">When should you consider JWT or OAuth?<\/span><\/h3>\n<p>JWT or OAuth may make sense for a custom mobile application or a separate service architecture. They are not identical authentication features provided by WordPress core on every installation. They usually require a plugin, reverse proxy, or separate identity service.<\/p>\n<p>A popular plugin is not automatically safe when its settings are left at their defaults. Review token lifetime, renewal, revocation, TLS, and whether tokens can appear in error logs. For a small integration, I usually start with built-in Application Passwords and a user with the minimum required permissions. I do not add JWT before there is a real need for it.<\/p>\n<h2><span id=\"Writing_a_custom_REST_endpoint_safely\">Writing a custom REST endpoint safely<\/span><\/h2>\n<p>A plugin or theme can register a custom endpoint:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">register_rest_route( &#039;store\/v1&#039;, &#039;\/stock\/(?P&lt;sku&gt;[A-Za-z0-9_-]+)&#039;, array(\n    &#039;methods&#039;             =&gt; WP_REST_Server::READABLE,\n    &#039;callback&#039;            =&gt; &#039;store_get_stock&#039;,\n    &#039;permission_callback&#039; =&gt; &#039;store_stock_permission&#039;,\n) );<\/code><\/pre>\n<p>The namespace is versioned and the SKU has a defined pattern. The security decision belongs in <code>permission_callback<\/code>. Leaving it empty, or copying an old <code>__return_true<\/code> example from a tutorial, is risky.<\/p>\n<p>You can connect the permission check to a user capability:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">function store_stock_permission( WP_REST_Request $request ) {\n    return current_user_can( &#039;manage_woocommerce&#039; );\n}<\/code><\/pre>\n<p>What did we do? The callback allows only users who can manage WooCommerce. Choose a capability that matches the site&#8217;s role structure. Using <code>manage_options<\/code> for every operation gives more access than many integrations need.<\/p>\n<h3><span id=\"Input_validation_and_output_sanitization\">Input validation and output sanitization<\/span><\/h3>\n<p>Data received through the REST API is untrusted. Check its type, allowed values, length, and business context. If a quantity should be an integer, validate it instead of silently accepting an arbitrary string. Use the appropriate WordPress sanitization functions for text fields.<\/p>\n<p>Returning every database field unchanged is another mistake. If an email address, physical address, internal note, customer ID, or private meta field is not needed, leave it out. Be especially careful with fields added through <code>register_rest_field<\/code>. Exposing a field is easy; discovering later that it was public is expensive.<\/p>\n<h3><span id=\"Nonces_CORS_and_HTTPS\">Nonces, CORS, and HTTPS<\/span><\/h3>\n<p>A nonce is not a replacement for authentication. CORS is not an authorization system either; it controls which browser origins may read a response. You still need to authenticate the request and check what the user is allowed to do.<\/p>\n<p>Credentials, Application Passwords, and content update requests must travel over HTTPS. Do not rely on an HTTP redirect and send a password to an HTTP URL first. The client should use the correct HTTPS address directly.<\/p>\n<h2><span id=\"Should_you_disable_or_protect_the_REST_API\">Should you disable or protect the REST API?<\/span><\/h2>\n<p>A response containing public posts is not, by itself, a security vulnerability. Disabling the entire API can break the block editor and modern plugins. I prefer to identify the endpoint that creates the risk.<\/p>\n<p>Restricting user enumeration, protecting sensitive custom endpoints, and removing unnecessary plugins is often healthier than shutting down the whole API. Test that a security plugin&#8217;s broad rule does not break the mobile application or editor connection you need.<\/p>\n<p>The checks described in <a href=\"https:\/\/www.dchost.com\/blog\/en\/how-to-read-and-fix-wordpress-site-health-report\/\">WordPress Site Health: How to Read and Fix the Report<\/a> are useful here too. When a REST API error appears, do not blame the security plugin immediately. Check the PHP version, permalink rules, the REST test, loopback requests, and server logs together.<\/p>\n<p>If custom endpoints perform administrative actions, leave an audit trail. You should later be able to answer who changed which record, when, and through which client. <a href=\"https:\/\/www.dchost.com\/blog\/en\/logging-and-audit-trail-architecture-for-gdpr-kvkk-compliant-admin-actions\/\">Logging and Audit Trail Architecture for GDPR\/KVKK\u2011Compliant Admin Actions<\/a> covers the personal-data side of these records separately.<\/p>\n<h2><span id=\"Performance_and_operations\">Performance and operations<\/span><\/h2>\n<p>If a client fetches thousands of posts on every page load, the API may be working correctly while the design is still wrong. Use pagination, <code>_fields<\/code>, suitable caching, and <code>ETag<\/code> or <code>Last-Modified<\/code> headers for data that does not change often.<\/p>\n<p>Keep authorized and unauthorized responses separate in the cache layer. A response requested with <code>context=edit<\/code>, or one containing user-specific data, must not land in a public cache. Check how your CDN handles requests carrying the <code>Authorization<\/code> header.<\/p>\n<p>Rate limiting is not only for attack traffic. A badly written synchronization job can send hundreds of requests per second to one endpoint and consume PHP workers. On the hosting side, I check access logs, application logs, and CPU and RAM monitoring. When a ticket says &#8220;the API is slow,&#8221; I first measure request volume, response size, and query parameters. More server capacity comes later.<\/p>\n<p>Do not log passwords or tokens while adding monitoring. For most troubleshooting, the endpoint, HTTP status, and, when appropriate, the user ID are enough. A useful audit trail does not require storing sensitive values.<\/p>\n<h2><span id=\"My_pre-launch_checklist\">My pre-launch checklist<\/span><\/h2>\n<p>Before I put a new WordPress REST API integration into production, I check the following:<\/p>\n<ol>\n<li>Is the endpoint namespace and version clearly defined?<\/li>\n<li>Is the data exposed through GET genuinely public?<\/li>\n<li>Do POST and DELETE requests check user capabilities?<\/li>\n<li>Do failed permission checks return the expected 401 or 403 response?<\/li>\n<li>Are input validation, type checks, and output sanitization in place?<\/li>\n<li>Are passwords, tokens, customer addresses, and unnecessary private fields absent from the response?<\/li>\n<li>Have HTTPS, CORS, rate limiting, and cache behavior been tested?<\/li>\n<li>Will the logs contain enough information to troubleshoot without exposing sensitive data?<\/li>\n<li>Is there a rollback plan and a database backup?<\/li>\n<\/ol>\n<p>Just as I do not run a WordPress update without first taking a <code>wp db export<\/code>, I finish staging tests before connecting a live integration. Testing an API call in staging is easy. Reversing an automation that accidentally emailed a real customer or changed a live product is not.<\/p>\n<p>Once, a security plugin caused the block editor&#8217;s REST request to return 403. The dashboard opened normally, but saving a post failed silently. I checked the response headers with <code>curl -i<\/code> and compared them with the web server log. The problem was not WordPress core; it was a broad REST rule in the security plugin. We narrowed the rule instead of disabling the entire API, then repeated tests for post creation, media uploads, and unauthorized requests in staging. I had assumed that a working dashboard meant the API was healthy. It was a useful correction.<\/p>\n<h2><span id=\"Frequently_asked_questions\">Frequently asked questions<\/span><\/h2>\n<h3><span id=\"Is_the_WordPress_REST_API_public\">Is the WordPress REST API public?<\/span><\/h3>\n<p>On most installations, some fields from public resources such as posts and pages can be read without authentication. Creating, updating, and deleting content, as well as accessing private data, requires authorization. Plugins can change this behavior on your site.<\/p>\n<h3><span id=\"Should_the_WordPress_REST_API_be_disabled\">Should the WordPress REST API be disabled?<\/span><\/h3>\n<p>Usually, it is better to restrict sensitive endpoints and user information than to disable the entire API. A complete shutdown can make the block editor, mobile applications, or some plugins stop working.<\/p>\n<h3><span id=\"Do_you_need_a_plugin_to_use_the_REST_API\">Do you need a plugin to use the REST API?<\/span><\/h3>\n<p>WordPress core provides built-in endpoints for many resources, including posts, pages, media, and users. A plugin or custom code may be needed for JWT authentication, special workflows, or custom business logic.<\/p>\n<h3><span id=\"Does_the_REST_API_slow_down_a_site\">Does the REST API slow down a site?<\/span><\/h3>\n<p>The API does not automatically make a site slow. Pulling too many records, expensive meta queries, and uncontrolled automation can create load. Pagination, <code>_fields<\/code>, caching, and rate limiting reduce that load in a measurable way.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>The WordPress REST API can power mobile apps, headless sites, and internal integrations, but public data and protected operations need different controls.<\/p>\n","protected":false},"author":4,"featured_media":5162,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[183],"tags":[484,486,485,483,480,482],"class_list":["post-5165","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-application-passwords","tag-rest-api-authentication","tag-woocommerce-api","tag-wordpress-development","tag-wordpress-rest-api","tag-wordpress-security"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5165","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5165"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5165\/revisions"}],"predecessor-version":[{"id":5167,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5165\/revisions\/5167"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5162"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5165"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5165"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5165"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}