Documentation/Developers
Back
  • Getting started
    • Frontends and app types
    • Environments and endpoints
  • OAuth clients
    • Client ID and secret
    • Redirect URIs and start URL
    • Secret rotation
  • Login with appsolut
    • Authorization code flow
    • Tokens and claims
    • Frontend role
    • Sign-out
    • Revocation and issued tokens
    • Token endpoint errors
  • Frontend keys
    • Issue and store a key
    • Send a key
    • Rotate and revoke
  • Members API
    • Eligibility from a backend
    • The signed-in member
    • Results, rate limits and errors
    • Is an applicant an eligible member?
    • The signed-in frontend user's membership
  • appsolut register API
    • Implement the API
    • Connect and test
    • Verify a member with their challenge code
    • List every member
    • The status of several members
    • The status of one member
    • The person data of several members
    • The person data of one member
    • The claims of several members
    • The claims of one member
    • Health check

Results, rate limits and errors

Every status and error the Members API answers, and the limits behind them.

Results

A membership check answers one of three statuses. The Members API passes on the status, never the reason.

statusEligibilitySigned-in member
validThe applicant passes and lands in your frontend's communityA valid membership, also under the grace rule
not_validNot, for whatever reasonA register refused it at the last check
unavailableA register could not answer; ask again laterThe register has not answered for 7 days since the last valid check
null–No organisation membership

The grace rule: while a register is unavailable, a member whose last valid check is less than 7 days old keeps their last result. That is why the signed-in member stays valid while an external register is down, and unavailable only after 7 days.

Errors

Every error has the same body, {"error": "<code>"}:

StatuserrorWhenWhat to do
400invalid_requestEligibility: a body that is not JSON or misses or breaks a field, or a missing or bad X-Applicant-IPFix the request
401unauthenticatedThe key, or for the signed-in member the token, is refused; with WWW-Authenticate: BearerCheck the key; treat a user as signed out
413too_largeEligibility: a body over 4 KBSend only the four fields
429rate_limitedA rate limit is reached; there is no Retry-AfterTell the applicant to try later
503unavailableThe Studio itself failedRetry later; the key and token are fine

Rate limits for eligibility

The Studio counts failed checks from its check log: a not_valid answer, including an applicant outside your frontend's community.

Counted perLimit
Member code5 in 15 minutes
Applicant network: the IPv4 address, or the /64 an IPv6 address is in20 in 15 minutes
Frontend500 in an hour
  • The ways one member code can be typed count as one code: variants that differ only in a leading plus sign or zeros, case, spaces, invisible characters or compatibility forms (such as fullwidth digits) share one budget. A separator such as - still makes a different code.
  • An unavailable answer and a request already refused as rate limited are not failed checks.
  • A check that is still running counts as failed until it is logged, so simultaneous requests cannot all pass before any of them is counted.
  • A refused request asks no register.

Rate limit for the signed-in member

600 requests per frontend user in an hour that starts with their first counted request. Refused requests are not counted.