Registering Endpoints

Add-ons register their own REST routes exactly the way core does — by declaring them on the $router inside their own app/Http/Routes/api.php, which is required when the add-on boots off wp_social_reviews_loaded_v2. See Core ↔ Pro Coupling for the boot sequence.

Declaring routes

Inside your add-on's route file, $router is the same WPSocialReviews\Framework\Http\Router instance. Declare a group with a prefix and a policy:

<?php
defined('ABSPATH') or die;

/** @var $router \WPSocialReviews\Framework\Http\Router */

use MyPlugin\App\Http\Controllers\MyController;

$router->prefix('my-addon')->withPolicy('SettingsPolicy')->group(function ($router) {
    $router->get('/things',      [MyController::class, 'index']);
    $router->post('/things',     [MyController::class, 'store']);
    $router->put('/things/{id}', [MyController::class, 'update']);
    $router->delete('/things',   [MyController::class, 'delete']);
});

This registers, for example:

GET /wp-json/wpsocialreviews/v2/my-addon/things

Choosing a policy

• Reuse a core policy (like SettingsPolicy) when your endpoints should be limited to the same admins who manage WP Social Ninja. This is exactly what Pro does.
• Ship your own policy (extending BasePolicy) when you need a different capability check. Implement verifyRequest() and gate on the capability you need.

class MyAddonPolicy extends \WPSocialReviews\App\Http\Policies\BasePolicy
{
    public function verifyRequest($request)
    {
        return $this->currentUserCan('manage_options');
    }
}

Controllers

Controllers extend the framework Controller. Read input from the injected request, call models/services, and return a response:

namespace MyPlugin\App\Http\Controllers;

use WPSocialReviews\Framework\Http\Controller;

class MyController extends Controller
{
    public function index($request)
    {
        return $this->sendSuccess([
            'things' => [/* ... */],
        ]);
    }
}

Nonce & namespace

Your routes live under the shared wpsocialreviews/v2 namespace, so front-end callers should use the same X-WP-Nonce flow the admin SPA already uses. If you call from the admin app, the global $get/$post/$put/$del/$patch helpers handle the nonce for you.

Reacting instead of registering

If you only need to run logic when core data changes — not a new endpoint — prefer a hook. See the Hook Reference; for example wpsocialreviews/custom_review_created or wpsocialreviews/template_deleted.