Dokumentation/Entwickler
Zurück
  • Erste Schritte
    • Frontends und App-Typen
    • Umgebungen und Endpunkte
  • OAuth-Clients
    • Client-ID und Client-Secret
    • Redirect-URIs und Start-URL
    • Secret erneuern
  • Login with appsolut
    • Authorization-Code-Flow
    • Tokens und Claims
    • Frontend-Rolle
    • Abmeldung
    • Widerruf und ausgestellte Tokens
    • Fehler des Token-Endpunkts
  • Frontend-Schlüssel
    • Einen Schlüssel ausstellen und aufbewahren
    • Einen Schlüssel senden
    • Wechseln und widerrufen
  • Mitglieder-API
    • Berechtigung aus einem Backend
    • Das angemeldete Mitglied
    • Ergebnisse, Ratenlimits und Fehler
    • Ist ein Antragsteller ein berechtigtes Mitglied?
    • Die Mitgliedschaft des angemeldeten Frontend-Benutzers
  • appsolut Register-API
    • Die API umsetzen
    • Anbinden und testen
    • Ein Mitglied mit seinem Prüfcode verifizieren
    • Alle Mitglieder auflisten
    • Der Status mehrerer Mitglieder
    • Der Status eines Mitglieds
    • Die Personendaten mehrerer Mitglieder
    • Die Personendaten eines Mitglieds
    • Die Claims mehrerer Mitglieder
    • Die Claims eines Mitglieds
    • Health-Check

Ein Mitglied mit seinem Prüfcode verifizieren

POST /members/verify

Das Studio ruft ihn beim Onboarding auf, wenn in der Anbindung des Registers „Prüfcode erforderlich“ eingeschaltet ist, mit der Mitgliedsnummer, wie die Person sie eingegeben hat, dem eingegebenen Geburtsdatum und ihrem Prüfcode (memberSecret).

Antworten Sie mit verified: true samt Status und Personendaten des Mitglieds, wenn die drei zusammengehören, und sonst mit verified: false, auch bei einer unbekannten Mitgliedsnummer: Diese Operation antwortet nie mit 404. Das Studio vergleicht danach Vorname, Nachname und Geburtsdatum in params mit den Eingaben der Person, daher muss ein verifiziertes Mitglied alle drei enthalten; fehlen sie, behandelt das Studio das Register als nicht erreichbar.

Authentifizierung

  • appsolut_m2m (im Header x-api-key gesendet): Der „API-Schlüssel“, der in der Anbindung des Registers im Studio eingetragen ist, bei jedem Aufruf gesendet. Das Studio speichert ihn verschlüsselt und zeigt ihn nie wieder an. Antworten Sie auf einen falschen Schlüssel mit 401 oder 403.

Parameter

NameOrtPflichtTypBeschreibung
x-tenant-idHeaderJastringDie „Mandanten-ID“, die in der Anbindung des Registers im Studio eingetragen ist, bei jedem Aufruf unverändert gesendet. Ihr Register kann damit die Organisationen unterscheiden, die es bedient. Beispiel: pannoniqa.
x-custom-scopeHeaderJastringDer „Scope“, der in der Anbindung des Registers im Studio eingetragen ist, bei jedem Aufruf unverändert gesendet. Ihr Register kann damit den Datenbestand wählen, aus dem es antwortet. Beispiel: employees.

Request-Body

Inhaltstyp: application/json, erforderlich

FeldTypPflichtBeschreibung
memberCodestringJaDie Mitgliedsnummer, wie die Person sie eingegeben hat.
birthDatestring (date)JaDas Geburtsdatum, das die Person eingegeben hat, JJJJ-MM-TT.
memberSecretstringJaDer Prüfcode, den die Person eingegeben hat: das persönliche Geheimnis, das ihr die Organisation über einen zweiten Kanal geschickt hat.

Beispiel

{
  "memberCode": "100001",
  "birthDate": "1979-02-02",
  "memberSecret": "K7MQ-2Z9P"
}

Antworten

200

Verifiziert oder nicht. verified: false braucht außer source kein weiteres Feld.

Inhaltstyp: application/json

FeldTypPflichtBeschreibung
sourcestringJaDer Name Ihrer Datenquelle, etwa „SAP HR“.
verifiedbooleanJaOb Mitgliedsnummer, Geburtsdatum und Prüfcode zu einem Mitglied gehören.
statusobjectNeinDer Status des Mitglieds. Erforderlich, wenn verified true ist.
status.statusCodestringJaDer Status des Mitglieds im Register. Filter in der Mitgliedschaftsdefinition und in Communities können ihn prüfen. Erlaubte Werte: active, inactive, pending.
paramsobjectNeinDie Personendaten des Mitglieds. Erforderlich, wenn verified true ist.
params.firstNamestringNeinVorname.
params.lastNamestringNeinNachname.
params.memberCodestringNeinDie Mitgliedsnummer, wie das Register sie führt.
params.birthDatestring (date)NeinGeburtsdatum, JJJJ-MM-TT.
params.zipstringNeinPostleitzahl.
params.citystringNeinOrt.
params.streetstringNeinStraße und Hausnummer.
params.countrystringNeinLändercode, etwa AT.

Beispiel: Eine aktive Mitarbeiterin

{
  "source": "SAP HR",
  "verified": true,
  "status": {
    "statusCode": "active"
  },
  "params": {
    "firstName": "Anna",
    "lastName": "Berger",
    "memberCode": "100001",
    "birthDate": "1979-02-02",
    "zip": "7100",
    "city": "Neusiedl am See",
    "street": "Musterweg 3",
    "country": "AT"
  }
}

Beispiel: Ein Mitarbeiter im Ruhestand

{
  "source": "SAP HR",
  "verified": true,
  "status": {
    "statusCode": "inactive"
  },
  "params": {
    "firstName": "Johann",
    "lastName": "Novak",
    "memberCode": "100009",
    "birthDate": "1952-07-07",
    "zip": "7000",
    "city": "Eisenstadt",
    "street": "Beispielgasse 7",
    "country": "AT"
  }
}

Beispiel: Nicht verifiziert

{
  "source": "SAP HR",
  "verified": false
}

400

Das Register konnte die Anfrage nicht verarbeiten. Das Studio behandelt das Register dann als nicht erreichbar und liest den Inhalt nicht.

Inhaltstyp: text/plain

Typ: string

Beispiel

Bad request

401

Der API-Schlüssel ist falsch. Das Studio meldet die Zugangsdaten als abgelehnt (ebenso bei 403) und behandelt das Register als nicht erreichbar.

Inhaltstyp: text/plain

Typ: string

Beispiel

Unauthorized

429

Zu viele Anfragen. Das Studio behandelt das Register dann als nicht erreichbar.

Inhaltstyp: text/plain

Typ: string

Beispiel

Too many requests