REST API Reference

Base Configuration

Base URL: {site_url}/wp-json/wu/v2/ Authentication: API Key & Secret (HTTP Basic Auth or URL Parameters)

Authentication

Enable API

// Enable API in Ultimate Multisite settings or programmatically
wu_save_setting('enable_api', true);

Get API Credentials

$api_key = wu_get_setting('api_key');
$api_secret = wu_get_setting('api_secret');

Authentication Methods

HTTP Basic Auth (Recommended):

curl -u "api_key:api_secret" https://yoursite.com/wp-json/wu/v2/customers

URL Parameters:

curl "https://yoursite.com/wp-json/wu/v2/customers?api_key=your_key&api_secret=your_secret"

Core Endpoints

1. Customers API

Base Route: /customers

Get All Customers

GET /wu/v2/customers

Get Single Customer

GET /wu/v2/customers/{id}

Create Customer

POST /wu/v2/customers
Content-Type: application/json

{
    "user_id": 123,
    "email_verification": "verified",
    "type": "customer",
    "has_trialed": false,
    "vip": false
}

Update Customer

PUT /wu/v2/customers/{id}
Content-Type: application/json

{
    "vip": true,
    "extra_information": "VIP customer notes"
}

Delete Customer

DELETE /wu/v2/customers/{id}

2. Sites API

Base Route: /sites

Create Site

POST /wu/v2/sites
Content-Type: application/json

{
    "customer_id": 5,
    "membership_id": 10,
    "domain": "example.com",
    "path": "/",
    "title": "My New Site",
    "template_id": 1,
    "type": "customer_owned"
}

3. Memberships API

Base Route: /memberships

Create Membership

POST /wu/v2/memberships
Content-Type: application/json

{
    "customer_id": 5,
    "plan_id": 3,
    "status": "active",
    "gateway": "stripe",
    "gateway_subscription_id": "sub_1234567890",
    "auto_renew": true
}

4. Products API

Base Route: /products

Get All Products

GET /wu/v2/products

5. Payments API

Base Route: /payments

Create Payment

POST /wu/v2/payments
Content-Type: application/json

{
    "customer_id": 5,
    "membership_id": 10,
    "status": "completed",
    "gateway": "stripe",
    "gateway_payment_id": "pi_1234567890",
    "total": 29.99,
    "currency": "USD"
}

6. Domains API

Base Route: /domains

Map Domain

POST /wu/v2/domains
Content-Type: application/json

{
    "domain": "custom-domain.com",
    "customer_id": 5,
    "primary_domain": 1,
    "stage": "domain-mapping"
}

Registration Endpoint

The /register endpoint provides a complete checkout/registration flow:

POST /wu/v2/register
Content-Type: application/json

{
    "customer": {
        "username": "newuser",
        "password": "securepass123",
        "email": "[email protected]"
    },
    "products": ["basic-plan"],
    "duration": 1,
    "duration_unit": "month",
    "auto_renew": true,
    "site": {
        "site_url": "mynewsite",
        "site_title": "My New Site",
        "template_id": 1
    },
    "payment": {
        "status": "completed"
    },
    "membership": {
        "status": "active"
    }
}

Response:

{
    "customer": { ... },
    "membership": { ... },
    "payment": { ... },
    "site": { "id": 123 }
}

Sovereign Tenant Endpoints

Ultimate Multisite: Multi-Tenancy 1.2.0 adds sovereign tenant REST coverage for integrations that provision, inspect, or verify isolated tenants.

The exact request payload depends on the enabled host capability, but integrations should expect these endpoint groups:

POST /wu/v2/tenants/{site_id}/bootstrap
GET /wu/v2/tenants/{site_id}/migration-status
POST /wu/v2/tenants/{site_id}/verify
DELETE /wu/v2/tenants/{site_id}

Use the bootstrap endpoint to prepare tenant registry, database, filesystem, and routing state. Use migration status and verification endpoints before switching production traffic. Use the deletion endpoint for sovereign teardown so database credentials are removed through the addon cleanup flow.

Typical migration status responses include:

{
    "site_id": 123,
    "isolation_model": "sovereign",
    "database_host": "localhost",
    "verification": {
        "no_legacy": "passed",
        "sovereign_push": "passed",
        "tenant_users": "passed"
    },
    "ready": true
}

Treat ready: false as a pre-launch blocker. Check the verification details, fix the database host binding, queue, user provisioning, or routing issue, then retry verification.

Translation Status Endpoints

<<<<<<< HEAD Gratis AI Translations Server 1.3.0 adds status endpoints for client sites that request server-built language packages backed by GlotPress and the Superdav AI Service.

Use the status endpoints before attempting a package download. A client should expect the server to import human translations first, queue AI gap-filling for untranslated strings, wait for manual approval, and then mark the package ready when generation finishes.

Check a single translation package

GET /wu/v2/translations/check?slug={plugin_or_theme_slug}&type={plugin|theme}&locale={locale}

Typical responses report the package identity, current status, remaining strings, total strings, and download information when the package is ready:

{
    "slug": "example-plugin",
    "type": "plugin",
    "locale": "fr_FR",
    "status": "ready",
    "source": "wp.org",
    "remaining_strings": 0,
    "total_strings": 342,
    "download_url": "https://example.com/path/to/package.zip"
}

Check multiple translation packages

Use the batch translation-check endpoint when a client needs status for several plugins, themes, or locales in one request.

POST /wu/v2/translations/check/batch
Content-Type: application/json

{
    "packages": [
        {
            "slug": "example-plugin",
            "type": "plugin",
            "locale": "fr_FR"
        },
        {
            "slug": "example-theme",
            "type": "theme",
            "locale": "de_DE"
        }
    ]
}

The response returns one status object per requested package. Clients should handle mixed results because one package can be ready while another is still pending approval or processing.

Expected status flow

Status	Meaning
missing	The server has not seen this package/locale request yet, or the request could not be matched to a GlotPress project.
pending_approval	Human translations and source strings have been prepared, but an administrator must approve the job before processing.
importing	The server is importing available human translations, including translate.wordpress.org translations for WordPress.org packages.
processing	Remaining untranslated strings are being translated through the Superdav AI Service.
packaging	Translations are complete and the server is building the downloadable package.
ready	The translated package is available for download.
failed	The job failed validation, translation, or package generation. Inspect server logs and queue details before retrying.

Superdav-backed jobs should not be treated as failed while they are pending approval, importing, processing, or packaging. Poll with backoff and download only when the endpoint reports ready with a download_url.

Support Tickets Chat Endpoints

Ultimate Multisite: Support Tickets 1.1.0 adds REST coverage for the live chat widget and agent console under the ultimate-multisite-support-tickets/v1 namespace. These routes are primarily used by the addon UI, but custom integrations can use them when building external support dashboards or chat widgets.

The endpoint group covers chat session lifecycle, message exchange, attachments, availability checks, agent reports, canned replies, satisfaction ratings, ticket conversion, and agent time logs:

GET /ultimate-multisite-support-tickets/v1/chat/availability
POST /ultimate-multisite-support-tickets/v1/chat/sessions
GET /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/messages
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/messages
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/attachments
GET /ultimate-multisite-support-tickets/v1/chat/attachments/{attachment_id}/download
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/context
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/token
GET /ultimate-multisite-support-tickets/v1/chat/agent/sessions
GET /ultimate-multisite-support-tickets/v1/chat/agent/availability
POST /ultimate-multisite-support-tickets/v1/chat/agent/availability
GET /ultimate-multisite-support-tickets/v1/chat/agent/reports
GET /ultimate-multisite-support-tickets/v1/chat/agent/canned-replies
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/assign
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/metadata
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/link-ticket
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/agent-time
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/convert-ticket
POST /ultimate-multisite-support-tickets/v1/chat/sessions/{session_id}/satisfaction

Use the public availability endpoint before showing an online launcher state. Create a session with the customer, site, and page context, then post messages against that session. If realtime sidecar transport is unavailable or business-hours rules mark support as offline, integrations should create or preserve the related ticket fallback so follow-up is not lost.

Agent-console integrations should filter sessions by assignment, status, customer, site, and date range where supported. Treat attachment responses as metadata references and render thumbnails defensively instead of trusting arbitrary uploaded content.

Error Responses

{
    "code": "wu_rest_invalid_parameter",
    "message": "Invalid parameter value",
    "data": {
        "status": 400,
        "params": {
            "email": "Invalid email format"
        }
    }
}

Pagination and Filtering

Query Parameters:

GET /wu/v2/customers?per_page=20&page=2&search=john&status=active

Common parameters:

• per_page - Items per page (default: 20, max: 100)
• page - Page number
• search - Search term
• orderby - Sort field
• order - Sort direction (asc/desc)
• status - Filter by status
• date_created - Filter by date range