Troubleshoot Request Limit or Entitlement Errors at Send Now

Send Now can stop for several different policy reasons. Separate the central Basic/Pro monthly allowance, optional Max/All Access Joomla-group limits, entitlement health, Identity Verification eligibility, and temporary authorization-service failures before changing the Request.

Start with the Exact Send Now Message

Do not recreate the Request or change unrelated fields first. Record the exact message, then check QCDS Status for the current Base/Effective tier, Authorized Domain state, and Entitlement Revalidation integrity.

Monthly Plan Allowance Exhausted

The QuantaCade request-authorization service is authoritative for plan volume. Basic normally allows 5 and Pro 25 new Requests per UTC month. Max and All Access do not have a QuantaCade plan-level numeric monthly ceiling.

If the central service reports that the monthly Request limit is reached, QCDS blocks Send Now before the immutable Request is created. The message can include the current allowance and its UTC reset time. Waiting for the reset or moving to an eligible higher entitlement resolves this class of error; editing the PDF or signer list does not.

Max/All Access Joomla-Group Limit Reached

Max and All Access can optionally enable local monthly limits by Joomla user group. These are separate from the QuantaCade plan allowance. When enabled, QCDS evaluates the sender's authorized/inherited groups; Unlimited wins, otherwise the highest saved numeric limit applies. A sender with no applicable saved allowance can resolve to zero.

If this local limit is already reached, QCDS stops before the central authorization call is made for that send, so the rejected attempt does not consume central usage.

Paid Entitlement or Entitlement-Task Health Problem

Current premium proof sent to the Request authorization service depends on healthy Entitlement Revalidation structure and a locally resolved paid entitlement. If Status shows an entitlement-task integrity problem or the Authorized Domain has fallen back to Basic, correct that entitlement layer first and refresh the entitlement before retrying Send Now.

Identity Verification Is Not Authorized or Available

If any signer requires Identity Verification, QCDS must have an effective Pro, Max, or All Access entitlement and a ready enabled provider profile. The local send validation checks provider availability, and the central authorization receipt must also authorize Identity Verification. A failure in either layer blocks the send before the immutable Request is created.

QuantaCade Authorization Is Temporarily Unavailable

If QCDS cannot contact or verify the central request-authorization service, the safe behavior is fail-closed: no Request is sent. Retry the same prepared send after connectivity/service health returns. Do not repeatedly create new Requests to work around a temporary authorization error.

Do Not Confuse Authorization with Email Delivery

If authorization succeeded and QCDS already created the immutable Request, a later Joomla mail failure is a delivery problem, not a Request-limit problem. Preserve the Request and use its delivery correction/retry tools so successful invitation links and history remain intact.

A Practical Recovery Order

  1. Read the exact Send Now message.
  2. Check QCDS Status and Entitlement Revalidation integrity.
  3. If Max/All Access group limits are enabled, check the sender's effective local allowance.
  4. If Identity Verification is required, confirm the active provider profile is enabled and tested.
  5. Retry the same send after the failing policy/service layer is corrected.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDS feature? Visit the QC Digital Signature Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.