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

Is an applicant an eligible member?

POST /api/v1/members/eligibility

Asks whether an applicant, who need not be signed in, is an eligible member of the calling frontend's community, by member code and the facts they entered. Every call is a membership check in eligibility mode, written to the Studio's check log with the applicant's IP.

The answer is the status alone, never why: an unknown member code and a known one with other facts get the same status, headers and body. Too many failed checks for one member code, from one applicant network (an IPv4 address, or an IPv6 /64) or at one frontend are refused with 429.

Authentication

  • frontendKey (HTTP bearer token, format ofk_<prefix>_<secret>): The frontend's frontend key, issued in the Studio on the frontend's page and shown once: Authorization: Bearer ofk_…. Up to two are active at a time, so a key can be rotated without downtime.

Parameters

NameInRequiredTypeDescription
X-Applicant-IPheaderYesstring (ipv4) or string (ipv6)The IP address of the applicant whose details the frontend's backend forwards: one IPv4 or IPv6 address. The rate limits count failed checks by the IPv4 address (an IPv4-mapped IPv6 address counts as that IPv4 address), or by the /64 an IPv6 address is in, which one subscriber is often given whole. A header of its own, because a proxy in front of the Studio may overwrite X-Forwarded-For with the address of the frontend's backend. Examples: 203.0.113.7, 2001:db8::7.

Request body

JSON, at most 4 KB. Other fields are ignored.

Content type: application/json, required

FieldTypeRequiredDescription
memberCodestringYesAs the applicant typed it; not blank, and without control characters (U+0000 to U+001F, U+007F) or unpaired surrogates. At most 255 characters.
firstNamestringYesThe applicant's first name, as they typed it. At most 255 characters.
lastNamestringYesThe applicant's last name, as they typed it. At most 255 characters.
birthDatestring (date)YesYYYY-MM-DD

Example: An applicant

{
  "memberCode": "108900",
  "firstName": "Jürgen",
  "lastName": "Weiß",
  "birthDate": "1962-07-07"
}

Responses

200

Checked. valid: an eligible member of the frontend's community. not_valid: not, for whatever reason. unavailable: a register could not answer; ask again later.

Content type: application/json

FieldTypeRequiredDescription
statusstringYesAllowed values: valid, not_valid, unavailable.

Example: An eligible member

{
  "status": "valid"
}

Example: Not an eligible member

{
  "status": "not_valid"
}

Example: A register could not answer

{
  "status": "unavailable"
}

400

A body that is not JSON or misses or breaks a field, or a missing or bad X-Applicant-IP. Which one is not said.

Content type: application/json

FieldTypeRequiredDescription
errorstringYesAllowed values: invalid_request, unauthenticated, too_large, rate_limited, unavailable.

Example: An invalid request

{
  "error": "invalid_request"
}

401

No frontend key, or one that is malformed, unknown or revoked, or the key of a disconnected frontend. Every case gets the same answer.

Headers

NameTypeDescription
WWW-Authenticate"Bearer"

Content type: application/json

FieldTypeRequiredDescription
errorstringYesAllowed values: invalid_request, unauthenticated, too_large, rate_limited, unavailable.

Example: Not authenticated

{
  "error": "unauthenticated"
}

413

A body over 4 KB.

Content type: application/json

FieldTypeRequiredDescription
errorstringYesAllowed values: invalid_request, unauthenticated, too_large, rate_limited, unavailable.

Example: Too large

{
  "error": "too_large"
}

429

Too many failed checks for this member code, from this applicant's network (the IPv4 address, or the /64 an IPv6 address is in) or at this frontend. No register was asked. There is no Retry-After.

Content type: application/json

FieldTypeRequiredDescription
errorstringYesAllowed values: invalid_request, unauthenticated, too_large, rate_limited, unavailable.

Example: Rate limited

{
  "error": "rate_limited"
}

503

The Studio itself failed, not a register (that is a 200 with unavailable). Retry later; the key is fine.

Content type: application/json

FieldTypeRequiredDescription
errorstringYesAllowed values: invalid_request, unauthenticated, too_large, rate_limited, unavailable.

Example: The Studio is unavailable

{
  "error": "unavailable"
}