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

The status of one member

GET /members/status/{memberCode}

The Studio calls it at every login check of a member whose membership is linked to this register, with the stored member code, unless the membership definition or a community filters on a claim (then it calls "The claims of one member" instead). Answer 404 for a member code the register does not hold.

Authentication

  • appsolut_m2m (sent in the header x-api-key): The "API key" entered in the register's connection in the Studio, sent with every call. The Studio keeps it encrypted and never shows it again. Answer 401 or 403 to a wrong key.

Parameters

NameInRequiredTypeDescription
memberCodepathYesstringThe member code, URL-encoded as one path segment. Example: 100001.
x-tenant-idheaderYesstringThe "Tenant ID" entered in the register's connection in the Studio, sent unchanged with every call. Your register can use it to tell apart the organisations it serves. Example: pannoniqa.
x-custom-scopeheaderYesstringThe "Scope" entered in the register's connection in the Studio, sent unchanged with every call. Your register can use it to choose the data set it answers from. Example: employees.

Responses

200

The member's status.

Content type: application/json

FieldTypeRequiredDescription
sourcestringYesThe name of your data source, such as "SAP HR".
statusobjectYes
status.statusCodestringYesThe member's status in the register. Filters in the membership definition and in communities can check it. Allowed values: active, inactive, pending.

Example: An active employee

{
  "source": "SAP HR",
  "status": {
    "statusCode": "active"
  }
}

Example: A retired employee

{
  "source": "SAP HR",
  "status": {
    "statusCode": "inactive"
  }
}

400

The register could not process the request. The Studio treats it as the register being unavailable and does not read the body.

Content type: text/plain

Type: string

Example

Bad request

401

The API key is wrong. The Studio reports the credentials as rejected (it does the same for 403) and treats the register as unavailable.

Content type: text/plain

Type: string

Example

Unauthorized

404

The register holds no member with this member code. The Studio treats the person as not found in this register.

Content type: text/plain

Type: string

Example

Not found