Multitenant Access

Operate across many client accounts from a single Mirra identity using raw, authenticated pass-through requests to a provider's full API.

Multitenant Access lets one Mirra identity operate across many separate accounts on the same external service — each with its own stored credentials — and reach the provider's entire API, not just Mirra's curated operations.

It is built on two pieces that work together:

1. Raw pass-through (request) — call the third-party API with the exact method, path, and body from the provider's own documentation. Mirra injects the stored credentials for you. There is no operation to look up and no field mapping in the way: if the provider documents an endpoint, you can call it.
2. Per-call account targeting (onBehalfOf) — choose which connected account a given request runs as, selecting the right stored credentials per call.

The use case

Many businesses operate as an agency, operator, or managed-service provider: a single team administers external accounts on behalf of many separate clients. Each client has their own login and their own data on the external service, but the work — and the automation — is centralized under one operator.

The canonical example is a Shopify agency that manages dozens of independent storefronts for its clients. Each store is a distinct Shopify account with its own products, orders, and API credentials, but the agency wants to run reporting, bulk edits, and automations across all of them from one place.

The same shape shows up well beyond commerce:

• A marketing agency running ad and analytics accounts for many brands.
• A bookkeeping firm reconciling many clients' separate finance accounts.
• A support vendor acting inside each customer's own helpdesk or CRM.

In every case the structure is the same: one operator, many tenants, one account per tenant. Multitenant Access models exactly this — your operator identity owns a set of sub-accounts, each holding the credentials for one tenant, and you pick which tenant to act as on a per-call basis.

How pass-through works

Each supported adapter exposes a generic request operation. You supply the request exactly as the provider's API docs describe it; Mirra attaches the stored credentials for the connected account and returns the upstream response verbatim.

import { MirraSDK } from '@mirra-messenger/sdk';
 
const mirra = new MirraSDK({ apiKey: process.env.MIRRA_API_KEY });
 
// Hit Shopify's REST Admin API exactly as documented at shopify.dev.
const res = await mirra.shopify.request({
  method: 'GET',
  path: '/admin/api/2025-10/products.json',
  query: { limit: 5 },
});
 
console.log(res.status); // 200
console.log(res.body);   // raw Shopify response payload

request accepts:

It returns the raw upstream response as { status, headers, body }. Non-2xx responses are returned faithfully rather than thrown — inspect status to branch on errors and read the provider's own error body from body.

Because the provider's API surface is reached directly, you also get endpoints Mirra doesn't model as first-class operations — for example, posting a GraphQL query:

const res = await mirra.shopify.request({
  method: 'POST',
  path: '/admin/api/2025-10/graphql.json',
  body: {
    query: `{
      products(first: 5) {
        edges { node { id title totalInventory } }
      }
    }`,
    variables: {},
  },
});

Inside a flow or script

The same call is available in flows and scripts via the injected mirra client:

export async function handler(event, context, mirra) {
  const res = await mirra.shopify.request({
    method: 'GET',
    path: '/admin/api/2025-10/orders.json',
    query: { status: 'open', limit: 50 },
  });
  return { openOrders: res.body.orders.length };
}

Targeting a specific account

By default, a request runs as the calling identity's own connected account. To act inside a tenant you manage, pass that sub-account's user ID as onBehalfOf:

// Run this request using a specific client's stored Shopify credentials.
const res = await mirra.shopify.request({
  method: 'GET',
  path: '/admin/api/2025-10/products.json',
  onBehalfOf: 'client-store-7',
});

This is what powers the agency pattern. Loop over the clients you manage and run the same automation against each tenant's own account:

const clientStores = ['client-store-7', 'client-store-9', 'client-store-12'];
 
for (const storeUserId of clientStores) {
  const res = await mirra.shopify.request({
    method: 'GET',
    path: '/admin/api/2025-10/products/count.json',
    onBehalfOf: storeUserId,
  });
  console.log(`${storeUserId}: ${res.body.count} products`);
}

Security model

Raw, authenticated access to a provider's full API is powerful, so it is deliberately constrained:

• Owner-only (standard execution mode). Pass-through is available when you run as yourself — through the SDK or your own flows and scripts. It is not available to public or shared agents acting on your behalf (delegated mode) or to background system jobs (service mode). Raw credential access stays with the account owner.
• Not an LLM chat tool. request is intentionally not exposed as a tool the assistant can call directly. It is reached only via the SDK and flows/scripts you author.
• Credentials can't be overridden. Mirra's injected authentication headers always win over any headers you pass, so a request can never present forged or substituted credentials.
• Host-locked. You control the path, not the host. Requests are always sent to the connected account's provider domain, so pass-through can't be redirected to an arbitrary destination.
• Ownership-checked targeting. As above, onBehalfOf is gated by a server-side ownership check.

Supported adapters

Multitenant Access is a reusable platform capability rather than a Shopify-specific feature — additional adapters can opt in over time. When an adapter supports pass-through, a request operation appears on it in the SDK and in the API reference, with the same shape and the same security model described here.

See also

• Shopify integration — the curated, first-class Shopify operations.
• Authentication — connecting accounts and managing sub-accounts.
• Scripts and Flows — where pass-through requests are most useful.