API reference · Client Portal

Clients

client_portal · clients · 6 operations

GET/v1/client-portal/clientsList the workspace's portal clients GET/v1/client-portal/clients/{client_id}Get a portal client PATCH/v1/client-portal/clients/{client_id}Edit a portal client's name, accounts and visible sections POST/v1/client-portal/clients/{client_id}/deactivateDeactivate a portal client (blocks portal access)POST/v1/client-portal/clients/{client_id}/reactivateReactivate a deactivated portal client GET/v1/client-portal/clients/{client_id}/activityGet a portal client's activity

GET/v1/client-portal/clients

List the workspace's portal clients

client_portal.clients.list

ReadIdempotentSince 2026-11-01

Lists the people outside the agency who sign in to this workspace's white-label client portal, ordered by client id and paginated by cursor (limit up to 200). Each client: email, display_name, status (active can sign in; inactive was deactivated), assigned_child_org_ids (the accounts they see), enabled_modules (the 14 portal sections, with defaults applied), auth_method (direct: created in the app with a password; invitation: registered from an invitation), auth_provider (password or google; null while they never signed in), created_at, created_by with created_by_name (who created them), registered_at and last_accessed_at (heartbeat while the portal is open). Filters: status, account_id (clients that see that account) and email (exact, case-insensitive); with filters a page can hold fewer than limit items, keep paging while has_more. Pending invitations are not clients: see client_portal.invitations.list. Never returns passwords. Only owners and admins.

Scope: client_portal:read
Permission: View the module · Only owner, admin
MCP tool: client_portal_clients_listOn the full surface; on the compact one, mb_execute_operation with id: "client_portal.clients.list".

Declared cost: up to 502 reads and 0 writes per call (they count against the daily quota).

Parameters

limitintegerqueryoptional

How many items this page brings at most (see the maximum and the default in the schema).

Default: 50

cursorstringqueryoptional

The next_cursor of the previous page, exactly as it came (only for the same list and filters); without it, the first page.

statusenumqueryoptional

Only active clients (can sign in) or inactive ones (deactivated). Default: both.

Values: active, inactive

account_idstringqueryoptional

Only clients that see this account in the portal.

emailstringqueryoptional

Only the client with this exact email (case-insensitive).

Response

dataarray<object>

has_moreboolean

next_cursorstring

Errors

role_required invalid_input unknown_field authentication_required scope_insufficient module_access_denied operation_not_found rate_limited quota_exceeded

Example

curl "https://api.mb-suite.com/v1/client-portal/clients" \
  -H "Authorization: Bearer $MB_API_KEY"

Try it with your test API key

With a test API key the request always goes to your practice organization: example data you can reset.

curl "https://api.mb-suite.com/v1/client-portal/clients" \
  -H "Authorization: Bearer $MB_TEST_KEY"

GET/v1/client-portal/clients/{client_id}

Get a portal client

client_portal.clients.get

ReadIdempotentSince 2026-11-01

Returns one portal client of this workspace by id (the client's login user id): email, display_name, status, the accounts they see (assigned_child_org_ids), the 14 portal sections with their effective value (enabled_modules), how they got access (auth_method, auth_provider, invitation_id), created_at, registered_at and last_accessed_at. Not found (portal_client_not_found) if the id is not a client of this workspace. Never returns passwords. Only owners and admins.

Scope: client_portal:read
Permission: View the module · Only owner, admin
MCP tool: client_portal_clients_getOn the full surface; on the compact one, mb_execute_operation with id: "client_portal.clients.get".

Declared cost: up to 1 reads and 0 writes per call (they count against the daily quota).

Parameters

client_idstringpathrequired

Portal client id (the client's login user id), from client_portal.clients.list.

Response

idstring

The client id (their MB Suite user id).

emailstring

Their email.

display_namestring

Their name (the email when they have none).

statusenum

active, or inactive (cannot sign in).

Values: active, inactive

assigned_child_org_idsarray<string>

The Accounts they see in the portal.

enabled_modulesobject

auth_methodenum

direct (created with a password from the app) or invitation (signed up from an invitation).

Values: direct, invitation

auth_providerenum | null

How they sign in: password or google; null while they never signed in.

Values: password, google

invitation_idstring | null

The invitation they came from, if any.

created_atnumber | null

When they were created (epoch ms).

created_bystring | null

The user id of who created them.

registered_atnumber | null

When they created their account (epoch ms).

last_accessed_atnumber | null

Their last access (epoch ms).

created_by_namestring | null

Their name, as the team shows it.

Errors

portal_client_not_found role_required invalid_input unknown_field authentication_required scope_insufficient module_access_denied operation_not_found rate_limited quota_exceeded

Example

curl "https://api.mb-suite.com/v1/client-portal/clients/{client_id}" \
  -H "Authorization: Bearer $MB_API_KEY"

Try it with your test API key

With a test API key the request always goes to your practice organization: example data you can reset.

curl "https://api.mb-suite.com/v1/client-portal/clients/{client_id}" \
  -H "Authorization: Bearer $MB_TEST_KEY"

PATCH/v1/client-portal/clients/{client_id}

Edit a portal client's name, accounts and visible sections

client_portal.clients.update

WriteIdempotentSince 2026-11-01

Edits what the app's client dialog edits: updates.display_name, updates.assigned_child_org_ids (replaces the whole list; at least one; each must be an account of this workspace, from platform.orgs.list, or it fails with portal_account_invalid; accounts the client already had are kept even if no longer valid) and the portal sections: updates.module_preset (complete, reports_only or default) as the starting point and updates.enabled_modules to turn individual sections on or off (keys: monitors, dashboards, reports, paid_insights, paid_media, social_insights, social_media, social_competitors, seo, seo_rankings, seo_site_auditor, ai_chat, apps_ads_visualizer, apps_utm_builder). Sections are always stored complete. Changes apply on the client's next page load. Returns the client and changed_fields (empty when nothing changed). It does not change the email, the password or the status (use client_portal.clients.deactivate / reactivate). Only owners and admins.

Scope: client_portal:write
Permission: Edit in the module · Only owner, admin
MCP tool: client_portal_clients_updateOn the full surface; on the compact one, mb_execute_operation with id: "client_portal.clients.update".

Declared cost: up to 501 reads and 1 writes per call (they count against the daily quota).

Parameters

client_idstringpathrequired

Portal client id (the client's login user id), from client_portal.clients.list.

updatesobjectbodyrequired

What changes (display_name, assigned_child_org_ids, module_preset, enabled_modules): only the fields sent.

Response

clientobject

changed_fieldsarray<string>

Errors

portal_client_not_found role_required invalid_input unknown_field authentication_required scope_insufficient crm_action_denied idempotency_key_reused rate_limited quota_exceeded

Example

curl -X PATCH "https://api.mb-suite.com/v1/client-portal/clients/{client_id}" \
  -H "Authorization: Bearer $MB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "updates": {}
}'

Try it with your test API key

With a test API key the request always goes to your practice organization: example data you can reset.

curl -X PATCH "https://api.mb-suite.com/v1/client-portal/clients/{client_id}" \
  -H "Authorization: Bearer $MB_TEST_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "updates": {}
}'

POST/v1/client-portal/clients/{client_id}/deactivate

Deactivate a portal client (blocks portal access)

client_portal.clients.deactivate

WriteIdempotentSince 2026-11-01

Turns off a client's access to the portal: their status becomes inactive, the portal login rejects them at once and, through this operation, their open portal sessions end too (sessions_ended tells whether there were sessions to close). Nothing is deleted: the client keeps their accounts and sections and client_portal.clients.reactivate gives access back. Idempotent: on an inactive client nothing changes (changed=false). Fires client_portal.client.deactivated. Deleting a client is only done in the app. Only owners and admins.

Scope: client_portal:write
Permission: Edit in the module · Only owner, admin
MCP tool: client_portal_clients_deactivateOn the full surface; on the compact one, mb_execute_operation with id: "client_portal.clients.deactivate".
Events it can emit: client_portal.client.deactivated

Declared cost: up to 1 reads and 1 writes per call (they count against the daily quota).

Parameters

client_idstringpathrequired

Portal client id (the client's login user id), from client_portal.clients.list.

Response

clientobject

changedboolean

sessions_endedboolean

Errors

portal_client_not_found role_required invalid_input unknown_field authentication_required scope_insufficient crm_action_denied idempotency_key_reused rate_limited quota_exceeded

Example

curl -X POST "https://api.mb-suite.com/v1/client-portal/clients/{client_id}/deactivate" \
  -H "Authorization: Bearer $MB_API_KEY"

Try it with your test API key

With a test API key the request always goes to your practice organization: example data you can reset.

curl -X POST "https://api.mb-suite.com/v1/client-portal/clients/{client_id}/deactivate" \
  -H "Authorization: Bearer $MB_TEST_KEY"

POST/v1/client-portal/clients/{client_id}/reactivate

Reactivate a deactivated portal client

client_portal.clients.reactivate

WriteIdempotentSince 2026-11-01

Gives portal access back to a deactivated client: their status becomes active and they can sign in again with the same login (email and password or Google), seeing the accounts and sections they had. Idempotent: on an active client nothing changes (changed=false). Fires client_portal.client.reactivated. Only owners and admins.

Scope: client_portal:write
Permission: Edit in the module · Only owner, admin
MCP tool: client_portal_clients_reactivateOn the full surface; on the compact one, mb_execute_operation with id: "client_portal.clients.reactivate".
Events it can emit: client_portal.client.reactivated

Declared cost: up to 1 reads and 1 writes per call (they count against the daily quota).

Parameters

client_idstringpathrequired

Portal client id (the client's login user id), from client_portal.clients.list.

Response

clientobject

changedboolean

Errors

portal_client_not_found role_required invalid_input unknown_field authentication_required scope_insufficient crm_action_denied idempotency_key_reused rate_limited quota_exceeded

Example

curl -X POST "https://api.mb-suite.com/v1/client-portal/clients/{client_id}/reactivate" \
  -H "Authorization: Bearer $MB_API_KEY"

Try it with your test API key

With a test API key the request always goes to your practice organization: example data you can reset.

curl -X POST "https://api.mb-suite.com/v1/client-portal/clients/{client_id}/reactivate" \
  -H "Authorization: Bearer $MB_TEST_KEY"

GET/v1/client-portal/clients/{client_id}/activity

Get a portal client's activity

client_portal.clients.activity

ReadIdempotentSince 2026-11-01

Returns how a portal client used the portal in a window of 1 to 366 days (since/until in epoch ms; default the last 30 days): total_logins, total_sessions (a session ends after 30 minutes without navigation), total_page_views, total_ms in the portal, days_active, first and last activity, top_paths (the 10 most viewed portal pages), the most recent sessions (up to 200, with their pages and accounts; sessions_truncated says when there were more) and a daily_timeline (days in the server's timezone) with each day's sessions, logins and page_views, which add up to the totals (a day can have a sign-in and no session). Reads up to 1000 page views and 500 logins of the window from the navigation and login logs (not Firestore: it costs one read). Use client_portal.clients.list (last_accessed_at) to spot clients who stopped coming. Only owners and admins.

Scope: client_portal:read
Permission: View the module · Only owner, admin
MCP tool: client_portal_clients_activityOn the full surface; on the compact one, mb_execute_operation with id: "client_portal.clients.activity".

Declared cost: up to 1 reads and 0 writes per call (they count against the daily quota).

Parameters

client_idstringpathrequired

Portal client id (the client's login user id), from client_portal.clients.list.

sinceintegerqueryoptional

Start of the window (epoch ms). Default: 30 days before until.

untilintegerqueryoptional

End of the window (epoch ms). Default: now.

Response

client_idstring

sincenumber

untilnumber

total_loginsnumber

total_sessionsnumber

total_msnumber

total_page_viewsnumber

first_activity_atnumber | null

last_activity_atnumber | null

days_activenumber

top_pathsarray<object>

sessionsarray<object>

sessions_truncatedboolean

daily_timelinearray<object>

By day, for the days with any activity.

Errors

portal_client_not_found role_required invalid_input unknown_field authentication_required scope_insufficient module_access_denied operation_not_found rate_limited quota_exceeded

Example

curl "https://api.mb-suite.com/v1/client-portal/clients/{client_id}/activity" \
  -H "Authorization: Bearer $MB_API_KEY"

Try it with your test API key

With a test API key the request always goes to your practice organization: example data you can reset.

curl "https://api.mb-suite.com/v1/client-portal/clients/{client_id}/activity" \
  -H "Authorization: Bearer $MB_TEST_KEY"