Before your portal shows a restricted page, it checks whether the signed-in visitor meets that page’s security policy. You can ask the same question through the integration interface, so your integration or support team gets a reliable yes-or-no answer and the reason behind it.
When to Use This
Use a direct eligibility check when you need to know why someone was refused, not just that they were refused. The portal refusal screen shows only the policy’s Access Denied message, which is the same sentence every refused visitor sees. A direct eligibility check also returns the specific condition the visitor did not meet. See Security Policies Explained for what makes up a policy and how Rhythm reaches an answer.
Prerequisites
- The caller must be signed in. Rhythm refuses unsigned requests.
- You need the identifiers for the contact, the security policy, and the site if event permissions matter.
Who May Ask About Whom
A portal visitor can check only their own contact’s eligibility. Rhythm refuses a request that asks about someone else. Staff and other Rhythm applications are not limited the same way, so they can check any contact in your Rhythm account. If you are building an integration, remember that a request made with a portal visitor’s session only answers for that visitor.
This also means a custom integration signed in as one visitor cannot act or ask on behalf of a different contact through this interface. If your integration needs to do something for a contact other than the signed-in visitor, give it its own staff or service credentials instead of relying on the visitor's session. Portals does not currently offer a way to customize this security model for each Rhythm account.
Check One Contact Against One Policy
| Operation | What it returns |
|---|---|
GET /securityPolicies/{tenantId}/portal/{contactId}/checkEligibility/{securityPolicyId} | Whether the named contact meets the named policy |
Add ?siteId= | Also applies that site’s event permissions when the site belongs to an event |
The answer includes:
meets_requirements—trueorfalse.message— the policy’s own Access Denied message, included only when the contact is refused. This is the same sentence a portal visitor sees.details— the specific reason for the refusal, such as a missing active registration or an unpaid balance. The portal’s own dialog does not show this reason.
Tip
If a member reports that a page refused them, run this check for their contact and the page’s policy. Read details for the specific reason, not just message.
A policy’s eligibility criteria can evaluate the contact’s organization instead of the contact directly, using the option to apply the rule to the organization the contact belongs to. If a check passes or fails unexpectedly, confirm whether that option is turned on because it changes what meets_requirements is evaluated against.
Belonging to a member organization does not automatically make an individual contact eligible. A policy can still evaluate the individual contact’s own status, so a contact can fail a check even when their organization qualifies.
Tip
A 403 from this endpoint does not always mean the caller’s credentials are invalid, especially when the same credentials work for other calls. Check the endpoint path first because an incorrect eligibility path can return a 403 by itself.
List a Contact's Standing Against Every Policy
To check a contact against every security policy in your Rhythm account at once, use the account-wide listing operation instead of checking one policy at a time. Add a site to apply that site’s event permissions across the list. The same self-access rule applies here: a portal visitor can ask only about their own contact, while staff and other applications can ask about any contact.
How the Answer Is Decided
Each check follows the same order your pages and menus use. Rhythm evaluates the policy’s eligibility criteria first, then event permissions if the page’s site has an event, and then the console-users-only option last. See Security Policies Explained for the full evaluation order and what each part of a policy means. Keep these points in mind when you read the result:
- Rhythm evaluates an inactive policy the same way it evaluates an active one. The check does not automatically pass or fail because of the policy’s status.
detailsreports only the first failing condition, even when the contact fails more than one.
Common Problems
| What you see | What it means |
|---|---|
| The portal's dialog shows only the policy's message, with no reason | Run the check directly and read details for the actual reason |
| The check fails with a server error mentioning the policy's criteria | The policy identifier does not match any policy, often because a page or menu item still points to a deleted policy |
| The check fails with an error about sponsors | A sponsor-only policy was checked against a contact with no organization, so Rhythm returns an error instead of a straightforward refusal |