Skip to main content

Add a custom REST endpoint from your add-on

Premium Intermediate

Register the route with WordPress directly and use Benecaster’s permission callback, benecaster_rest_permission_admin(). No base class, no container, no benecaster_boot — the endpoint is a plain WordPress route that happens to borrow one function.

When to Use This

Whenever your add-on needs its own REST endpoints — settings writes from an admin screen, a status probe for a companion service, a data export. There is only one supported shape now: register_rest_route() on rest_api_init, with benecaster_rest_permission_admin as the permission_callback where the route needs a site admin.

Prerequisites

  • Benecaster installed and a valid license active

  • Nothing else. There is no boot ordering to get right and no container to resolve from — the
    function is a plain global, available as soon as Benecaster’s functions.php has loaded.

How It Works

benecaster_rest_permission_admin() checks manage_options and then a valid wp_rest nonce, exactly as core’s own admin endpoints do — the two call the same implementation, so they cannot drift apart. Pass the function name as a string and nothing else: WordPress hands the request to a permission_callback for you.

Notes

Use your own namespace, not benecaster/v1. Routes registered under core’s namespace look like ours to anyone reading the route list — including us, when we are deciding whether a path is safe to change. my-addon/v1 is the shape to copy.

This covers the admin check only. There is no public function for the editor (edit_posts) or subscriber (logged-in) callbacks. That is a deliberate narrowing — only the admin one had recipes pointing at it — but it does mean an add-on needing one of the other two currently has to extend the class. Raise it rather than working around it, and it gets its own function.

Return WP_Error, not false, from any permission callback of your own. WordPress turns a WP_Error into a 403 carrying a message that says which check failed, where a bare false gives a flat refusal that is far harder to debug from the browser console. benecaster_rest_permission_admin() already does this.

Related

Code

<?php
add_action( 'rest_api_init', function (): void {
    register_rest_route( 'my-addon/v1', '/my-resource', [
        'methods'             => 'GET',
        'callback'            => 'my_addon_get_resource',
        'permission_callback' => 'benecaster_rest_permission_admin',
    ] );
} );

function my_addon_get_resource( \WP_REST_Request $request ): \WP_REST_Response {
    return new \WP_REST_Response( [ 'data' => 'hello from my add-on' ], 200 );
}

View on GitHub →

Need this built rather than just documented? See our services →

Powered by