Manager API

Manager endpoints live under /api/v1/manager-api. They support scoped manager API keys for server integrations. The TrustedStake manager UI uses a wallet-authenticated session under /api/v1/manager-auth.

Authentication choices

Server integration

Send the issued manager key in Authorization: Bearer <manager-key>. Never expose it to a browser, mobile bundle, log, or prompt. Keys are scope constrained and strategy-owner guarded. Request only the scopes your integration needs:

Scope	Enables
strategies:read	Read strategies, members and share-link metadata
strategies:write	Create/update strategies and manage their share links
rebalances:trigger	Request a manual rebalance
operations:read	Read rebalance status and strategy activity

Key lifecycle routes are /api/v1/manager-api-keys: generate with POST /generate, list metadata with GET, and revoke with DELETE /{id}. Generation and revocation require fresh wallet signatures (generate_api_key and revoke_api_key respectively), with the parameters in the signed message. The raw key appears once at creation; save it in server secret storage. To rotate, issue a new key, replace your server secret, verify a permitted read and revoke the old key. Listing keys never recovers the original secret.

Manager browser session

1. Sign a manager_login message.
2. POST /api/v1/manager-auth/login with x-signature, x-message, and x-wallet-address.
3. Send the CSRF header on mutations while the HttpOnly manager-session cookie is active.
4. End with POST /api/v1/manager-auth/logout.

When readable signatures are enabled, request POST /api/v1/wallet-signing/challenges before signing. It returns the exact action message, 0x-prefixed UTF-8 hex signingBytes, full request ID and expiry. Sign the returned bytes and send the exact signingBytes in x-message; this hex transport preserves the exact signed bytes for both current and previously issued readable messages. The maintained manager UI performs this step. Existing JSON messages and scoped manager server keys remain compatible. See Wallet signatures for the user-facing approval experience. This does not change your server key integration.

Core endpoints

Method	Path	Purpose
GET	/api/v1/manager-api/strategies	List strategies visible to the manager
GET	/api/v1/manager-api/strategies/{id}	Read one permitted strategy
POST	/api/v1/manager-api/strategies	Create a strategy
PATCH	/api/v1/manager-api/strategies/{id}	Update allowed strategy fields
PATCH	/api/v1/manager-api/strategies/{id}/active	Pause or resume a strategy
DELETE	/api/v1/manager-api/strategies/{id}	Permanently delete an owned strategy
POST	/api/v1/manager-api/strategies/{id}/rebalance	Queue one manual rebalance
GET	/api/v1/manager-api/strategies/{id}/rebalance-status	Read correlation-bound operation state
GET	/api/v1/manager-api/strategies/{id}/activity	Read manager activity
GET	/api/v1/manager-api/strategies/{id}/delegators	List strategy members
GET, POST	/api/v1/manager-api/strategies/{id}/share-links	List or create strategy invitations
PATCH, DELETE	/api/v1/manager-api/strategies/{id}/share-links/{linkId}	Edit or revoke an invitation

Manual rebalance semantics

A 202 trigger response means accepted for asynchronous processing, not executed on chain. The response envelope contains data.correlationId and data.statusLookup. The server generates this correlation ID; a caller-supplied x-correlation-id is not an idempotency key for this operation. Retain the returned values and use operations:read to read the corresponding status. Do not automatically repeat a trigger after a timeout.

data.state	Meaning
not_observed	No operation evidence yet; neither failure nor permission to retrigger
in_progress	Evidence exists without an established terminal outcome
executed	Recorded evidence reports execution; inspect operation evidence for details
no_effect	Terminal evidence without executed operations
partially_failed	Partial result or mixed execution/failure evidence; review before another action
failed	Recorded failure evidence; review the cause

These manager states differ from the initial-allocation job statuses used by the partner SDK. Activity history is useful context, but it does not replace the correlation-bound status lookup.

Strategy identity and boundaries

Use returned strategy IDs, proxy identities and authoritative table context. A custom label or an “own proxy” description does not identify the storage table. Manager API callers do not create another pure proxy or need controller secrets; TrustedStake owns that execution infrastructure.

Standard keys support DAILY and MANUAL_ONLY rebalance frequency in the reviewed implementation. Owner/strategy permission checks apply in addition to key scopes. Operational execution flags and privileged strategy flags are not manager-key configuration. Do not infer rights from a strategy appearing in a list.

Read the Scalar manager reference or OpenAPI document alongside this guide. The reference inventories the reviewed controller routes; response schemas are specified where verified and do not imply a fully generated description of every strategy DTO.

Activity and access

Strategy activity is an owner-scoped operational history. A successful request or accepted rebalance is not proof that trades finalized. Use the correlation-bound status response for that result. In Seer deployments with the admin operations API enabled, TrustedStake administrators can review manager API key metadata and request logs; those administrative logs do not grant managers access to another owner’s strategies.

An invitation controls admission; a partner key controls server API access. Revoking either does not automatically remove an existing member. Use the applicable membership/strategy controls for existing members. Hosted and embedded partner joins retain their originating partner attribution independently of ongoing wallet authorization.

Membership responsibility

Distribution partners should use TrustedStake Hosted Join or Embedded Join when enabled for their integration. Advanced integrations can register through the signed membership API. Managers should not manually reconcile routine joins. The worker starts from active API membership and verifies execution eligibility directly against chain state.