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

Eligibility from a backend

Asking whether an applicant is an eligible member of your frontend's community.

Some questions come before a sign-in, or without one: a booking form open to members only, a benefit someone applies for by phone, a check before an account is created. For these, your backend asks the Studio whether an applicant is an eligible member, by the member code and facts the applicant entered. The applicant need not be signed in, or be a frontend user at all.

The call

POST <studio>/api/v1/members/eligibility
Authorization: Bearer ofk_<prefix>_<secret>
X-Applicant-IP: 203.0.113.7
Content-Type: application/json

{
  "memberCode": "108900",
  "firstName": "Jürgen",
  "lastName": "Weiß",
  "birthDate": "1962-07-07"
}
  • The body is the member code as the applicant typed it, their first and last name and their birth date (YYYY-MM-DD): JSON, at most 4 KB. Other fields are ignored.
  • X-Applicant-IP is the IP address of the applicant whose details you forward, one IPv4 or IPv6 address. It is required, because the rate limits count failed checks per applicant network. It is a header of its own because a proxy in front of the Studio may overwrite X-Forwarded-For with your backend's address.
  • No challenge code. Eligibility never asks for one, and a challenge code in the body is ignored.

The answer

{ "status": "valid" }
statusMeaning
validThe applicant passes the membership check and lands in your frontend's community.
not_validNot, for whatever reason: unknown member code, other facts, refused by the membership definition, or a member outside your community.
unavailableA register could not answer. Ask again later.

The answer is the status alone. For Pannoniqa, a retiree who asks through the Pannoniqa App (community "Active employees") gets not_valid, and the same request through the Pannoniqa Portal (community "All staff") gets valid.

What happens in the Studio

Every call is a membership check in eligibility mode. The Studio walks the organisation's membership definition, asks its registers (an external register live, for up to 5 seconds), compares the facts and places the result in your frontend's community. The check is written to the check log with your frontend and the applicant's IP; the facts are never stored. Nothing else changes: no account, no organisation membership, no frontend activation.

Rate limits

Failed checks are limited, so the endpoint cannot be used to guess member codes:

  • 5 per member code, and 20 per applicant network (the IPv4 address, or the IPv6 /64), in 15 minutes;
  • 500 per frontend in an hour.

Beyond them the answer is 429 {"error": "rate_limited"}. See Results, rate limits and errors for what counts.

Reference

Is an applicant an eligible member?