eLearning.edu.pl API
ENPL

Single sign-on and learning records

Two integrations are configured by your IT administrator in the IT administration panel rather than called through this API. This page summarises what your identity and analytics teams need to know.

Single sign-on (OpenID Connect)

People can sign in with any OpenID Connect identity provider (for example Microsoft Entra ID) using the authorization code flow with PKCE.

  • What the IT administrator enters: the issuer URL (discovery document), client id and client secret of an application registered in your provider, and optionally the claims that hold the e-mail address and the employee number. The panel tests discovery and the signing keys before saving.
  • Redirect URI to register in your provider: the address of your organisation's platform followed by /auth/sso/callback (the panel shows the exact value).
  • E-mail domains are verified with a DNS TXT record shown in the panel. The first sign-in links a person by a verified e-mail address or, if configured, by the employee number claim; after that only the provider's subject (iss + sub) is used. Accounts are not created at sign-in — create them with SCIM or the Users API.
  • Required mode can enforce single sign-on for selected departments or worker types. At least one administrator keeps a password as an emergency account.

ID tokens must be signed with an asymmetric algorithm; iss, aud, nonce and token lifetimes are checked.

User provisioning (SCIM 2.0)

Identity providers keep accounts and groups in sync through SCIM — see Authentication for the tenant URL and the token, and the SCIM section of the API reference for the supported resources. Accounts provisioned by SCIM belong to the identity provider; the Users API returns 409 MANAGED_ELSEWHERE when you try to change them.

Learning records (xAPI forwarding)

Learning activity (course launches, progress, completions) is recorded as xAPI statements. The platform can forward them to your own Learning Record Store:

  • What the IT administrator enters: the LRS base URL (ending with /), Basic authentication username and secret, and the xAPI version (1.0.3 or 2.0.0). The panel tests the connection with GET {endpoint}about and an authenticated GET {endpoint}statements?limit=1.
  • Statements are sent in batches of up to 100 with POST {endpoint}statements, in the order they were recorded. Failed batches are retried after 1 minute, 5 minutes, 30 minutes and then every 2 hours; nothing is skipped.
  • If your LRS rejects a batch with 400, it is resent one statement at a time; statements rejected individually are listed in the panel and the rest continue.
  • Learners' free-text answers (result.response) are removed unless the administrator enables sending them.
  • The LRS host must be a public host name on port 443. Requests come from a fixed platform address — ask your onboarding contact for it if your firewall uses an allowlist.

For course completions in your HR system, webhooks are usually simpler than reading the LRS.