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-IPis 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 overwriteX-Forwarded-Forwith 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" }
status | Meaning |
|---|---|
valid | The applicant passes the membership check and lands in your frontend's community. |
not_valid | Not, for whatever reason: unknown member code, other facts, refused by the membership definition, or a member outside your community. |
unavailable | A 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.