Update LinkedIn account smart limit
Patch the operator-tunable policy of one limit row (daily_limit / target_limit / delay_in_seconds / smart_limits_enabled; at least one field OR reset_hold:true required). status is recomputed atomically. A spent daily budget shows as status “held” (there is no “saturated” status). Raising daily_limit does NOT by itself clear that hold. Pass reset_hold:true IN THE SAME CALL to raise the cap AND resume now (the atomic “raise + resume”). The hold only actually clears if the new daily_limit is above done_today_count; otherwise the saturation-latch immediately re-holds it. On a smart-managed row the persistent lever is target_limit (a manual daily_limit below smart_limit is only transient until the next snapshot). System-managed fields (done_today_count, smart_limit, hold_till, linkedin_quota_hit_till, status, …) are rejected as fields. Use reset_hold to clear the hold. A LinkedIn-side lock (linkedin_quota_hit_till) is never resettable.
Contract:
- MCP tool
update_linkedin_account_smart_limit, registry packagemcp.linkedin/linkedin_account_smart_limits, mountlinkedin.accounts. - Operation
update, response envelopeupdate. - Flags: dangerous: the MCP layer gates it behind a preview/commit token, and the effect cannot be undone through this API.
Authorizations
Access token issued by gtm.service.id. Its access_identity claim carries team_sid, actor_sid and actor_type, and that team scope is authoritative.
Team scope for tokens that do not carry one. Ignored when the token already names a team.
Path Parameters
Smart-limit row sid (ln_sm_…).
18^ln_sm_Body
Request body of update_linkedin_account_smart_limit.
Active cap (1..1000).
1 <= x <= 1000Warm-up ceiling; null clears it.
0 <= x <= 1000Batch-boundary cooldown (1..3600).
1 <= x <= 3600Clear the daily-saturation hold in the same call (the atomic "raise the limit AND resume now"). Only resumes if the new daily_limit > done_today_count; otherwise the row re-holds. Never touches a LinkedIn-side lock.