---
title: "Call the getAccountLimits MCP tool"
method: POST
path: "/api/v1/actions/getAccountLimits"
tags: ["Actions"]
---

# Call the getAccountLimits MCP tool

`POST /api/v1/actions/getAccountLimits`

## Request

- Base URL: `https://app.reachium.io`
- URL: `https://app.reachium.io/api/v1/actions/getAccountLimits`
- Auth: HTTP bearer

Read a LinkedIn account’s daily sending limits (connection requests, messages, reply-agent cap) AND its working-hours ENFORCEMENT state (timezone, per-weekday schedule, enabled flag) in one call. working_hours is the truth every send path actually gates on: if the account has no working-hours row yet, timezone and schedule are null and is_enabled is false, meaning the account is UNRESTRICTED (sends at any hour) - the workers skip the hours gate entirely when there is no row, they do NOT fall back to a 9-5 default. working_hours_source is "configured" when a row exists, "default" when it does not (that "default" behavior IS unrestricted, not a placeholder schedule). When there is no row, working_hours_unset_default separately reports the reference window the UI would create on a first edit (9am-5pm America/New_York) - that window is NOT enforced; use it only as a starting point if you are about to turn working hours ON, never report it as the account’s current hours. limit_source mirrors this for the limits block. Call this before updateAccountLimits’s working_hours_schedule (it requires the full week; read the current schedule here first so you send back all 7 days, not just the one you are changing - or, if working_hours_source is "default", compose any full week yourself, e.g. from working_hours_unset_default). Pass account_id from getLinkedInAccounts.

Called through the Actions bridge: the response is that tool's own result, wrapped as `{ data: <tool result> }` under HTTP 200. Billing, daily-cap, and confirm-step outcomes are embedded INSIDE `data`, never remapped to an HTTP status (see the templated `/api/v1/actions/{toolName}` operation above for the full protocol, and `x-mcp-actions` for this tool's machine-readable scope/cap/confirm_behavior fields). Authentication, request-shape, and optional idempotency-protocol failures still use their documented non-200 statuses.

## Headers

- `Idempotency-Key` string

## Request body

- object
  - `account_id` string, uuid, required: The LinkedIn account (from getLinkedInAccounts).

## Response `200`

The result of calling this tool.

- object
  - `data` unknown, required
  - `error` unknown, required

## Other responses

- `400`: The request body was not a JSON object (code invalid_request), or Idempotency-Key is malformed (code invalid_idempotency_key).
- `401`: Missing or invalid API key. Send `Authorization: Bearer rmcp_...` (code unauthorized).
- `403`: This tool is out of the key’s granted scope (code insufficient_scope).
- `409`: This Idempotency-Key has an unresolved in-flight or ambiguous result (code request_in_flight). Reconcile before using a new key.
- `422`: This Idempotency-Key was already used with a different request body (code idempotency_key_reuse).
- `429`: Rate limited: shared `mcp:ip:{ip}` (600/60s) or `mcp:key:{keyId}` (120/60s) bucket, the SAME buckets the MCP endpoint uses (code rate_limited).
- `500`: Unhandled server error (code internal_error).

---

[API](https://skmtc.dev/reachium/apis/reachium-api.md) · [All operations](https://skmtc.dev/reachium/apis/reachium-api/llms.txt) · [OpenAPI document](https://skmtc.dev/reachium/apis/reachium-api/revisions/11682826692b?raw)