Problem Statement

Problem

The OpenClaw openviking plugin currently works with apiKey, but it does not properly
support multi-tenant production usage with explicit accountId and userId.

Before patching locally, the plugin always sent requests effectively as default/default,
because X-OpenViking-Account and X-OpenViking-User were not configurable through plugin
config and were hardcoded to empty values in the client setup.

This causes a problem when OpenViking is running in production mode with root_api_key:

• root_api_key can authenticate successfully
• but requests are still routed to the default tenant
• newly created real accounts/users are not actually used by the plugin

As a result, OpenClaw appears to work, but all memory/session/resource writes still go into
the default tenant instead of the intended production account.

Expected behavior

The plugin should support tenant-aware configuration, for example:

• accountId
• userId

and pass them through as:

• X-OpenViking-Account
• X-OpenViking-User

This is required when using root_api_key with a real OpenViking account/user in
production.

Additional issue

Even after adding accountId / userId support in code, Gateway config validation fails
unless the plugin schema also includes these fields.

So this needs to be fixed in both:

• runtime plugin config parsing
• plugin config schema / metadata

Proposed Solution

Proposal

Add first-class multi-tenant support to the OpenClaw openviking plugin.

Proposed changes

1. Extend plugin config with:

   • accountId
   • userId

2. Pass these values through on every OpenViking request as:

   • X-OpenViking-Account
   • X-OpenViking-User

3. Update the plugin config schema so Gateway accepts these fields.

4. Optionally allow env fallback, for example:

   • OPENVIKING_ACCOUNT_ID
   • OPENVIKING_USER_ID

Why

This makes the plugin work correctly with OpenViking production mode when using
root_api_key, and prevents requests from silently falling back to the default tenant.

Without this, OpenClaw may appear functional, but all data is written to the wrong tenant.

Alternatives Considered

No response

Feature Area

Core (Client/Engine)

Use Case

Openclaw

Example API (Optional)

Additional Context

No response

Contribution

• I am willing to contribute to implementing this feature