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

appsolut register API

The API an external register exposes so the Studio can ask it about member codes.

An external register is a list of people who may qualify as members that stays in the organisation's own system, such as Pannoniqa's HR system "SAP HR". The Studio does not copy it: it asks it live, through the appsolut register API, whenever it needs to know about a member code. This section is for whoever builds that API in front of the organisation's system.

How the Studio uses it

WhenThe Studio callsWith
A person onboards and the connection has "Challenge code required" onVerify a member with their challenge codeThe member code as typed, the birth date entered and the challenge code
A person onboards without a challenge code, or a frontend asks about an applicant (eligibility)The person data of one memberThe member code as typed
A member signs in (login check)The status of one memberThe stored member code
Any of these, when the membership definition or a community filters on a claimThe claims of one member insteadThe same member code
A frontend reads the signed-in member's member dataThe person data of one member, with a deadline of 1.5 secondsThe stored member code
A Studio user tests the connectionHealth check, The person data of one member for a test member code, and List every member once–

Where the Studio compares facts (onboarding and eligibility), it compares the first name, last name and birth date in your answer with what the person entered. The register decides whether a person exists and what their status and claims are; the organisation's membership definition decides what that means.

The operations The status of several members, The person data of several members and The claims of several members belong to the standard, but the Studio does not call them at present.

What every call carries

HeaderValue
x-api-keyThe "API key" entered in the register's connection in the Studio
x-tenant-idThe "Tenant ID" entered there, so one register can serve several organisations
x-custom-scopeThe "Scope" entered there, to choose a data set
acceptapplication/json

In this section

  • Implement the API: the answers the Studio expects, and its network rules.
  • Connect and test: entering the connection in the Studio and testing it.
  • The reference: every operation, generated from the OpenAPI description, starting with Verify a member with their challenge code.