Integration Overview

Purpose: Give an architect a single mental model of a Integration Lab integration before choosing protocols or writing code.
Prerequisites: A named system of record
A decision on where identity lives
A stable external identifier per candidate
Architecture: Every integration in this lab decomposes into five concerns: identity federation, candidate provisioning, entitlement, delivery, and outcome return. Different customers vary which system owns each concern — the protocol choices follow from that ownership, not the other way round.

Configuration

Correlation key	external_id supplied by the source system
Transport	HTTPS REST + outbound webhooks
Environment	Sandbox first, production credentials after a passing checklist

Implementation steps

01Map each of the five concerns to the system that owns it.
02Choose identity: portal session, OIDC, SAML or LTI context.
03Define the external identifier and prove it is stable and unique.
04Map source-system products/courses/stages to assessments.
05Decide whether outcomes are pulled (REST) or pushed (webhooks).
06Run the scenario in the sandbox end to end before scheduling production work.

Examples

Concern-to-system map

text

identity      -> Corporate IdP (OIDC)
provisioning  -> Integration layer (from commerce order)
entitlement   -> Integration Lab assignment
delivery      -> Integration Lab proctored assessment
outcome       -> Webhook to customer portal

Testing procedure

Run the E-commerce Certification scenario in the sandbox
Replay the same event twice and confirm no duplicates

Troubleshooting

Duplicate candidates

The external identifier is not stable. Re-key on an immutable id, not email.

Missing outcomes

Confirm whether the design is pull or push; do not mix both without deduplication.