Iframe Integration

Setup

Setting up the iframe is a one-time exchange between your team and Osteocom. After that, you only deal with the embed snippet on your pages.

What we need from you

Three pieces of information, sent in once to your Osteocom contact:

1. The list of domains of your platform that will host the iframe — for example https://lms.partner.com or https://staging.partner.com. Subdomains and staging environments count: list each one you actually use. Without a domain in the whitelist, browsers will block the iframe via CSP frame-ancestors.

2. The list of Osteocom courses you want to resell. If you negotiated specific prices, send them too. We use this to configure your per-partner catalog: only the products in your catalog can be sold through your iframe.

3. The format of your partnerUserId — the identifier your platform will pass to Osteocom for each end user. It must be:

   • Unique per user inside your platform
   • Stable over time: the same user must always arrive with the same id, otherwise we cannot match their previous purchases
   • Opaque: don't put PII inside it. An internal user id, UUID or hashed identifier works best.

What we send back

After we configure your partner record, you'll receive:

• Your clientId — a unique identifier for your integration. You'll include it in every iframe URL.
• The product ids of the courses enabled in your catalog.
• The Osteocom zone to use in the iframe URL. For now we recommend en as the default unless otherwise agreed with our content team — the zone segment in the URL is under review and will be simplified in a future iteration, so sticking to en keeps integrations forward-compatible.

Keep your clientId safe but not secret

The clientId will appear in the HTML of your pages — it is not a secret. However, only requests coming from your whitelisted domains will be allowed to render the iframe, so a leaked clientId alone cannot be abused.

Test before go-live

Before publishing the iframe on production pages of your platform, we recommend this round of checks.

Run all tests against test.osteocom.me, never against production

During the requirements-gathering phase Osteocom provides a dedicated test product on the test.osteocom.me environment. All your integration tests must point to that environment, otherwise your activity ends up mixed with real customer data on production and pollutes Osteocom's records.

If you have a staging environment on your side, run the tests there first — and make sure the staging domain has been communicated to Osteocom for the CSP whitelist, otherwise the iframe will be blocked by the browser.

1. Available state: load the iframe with a partnerUserId that has never purchased — you should see the card with a "Buy" button and the correct price.
2. End-to-end purchase: click "Buy" and complete the checkout on Osteocom. We can provide test card numbers if you let us know in advance.
3. Already purchased state: reload the same page — the button should now read "Already purchased" and link to the Osteocom login.
4. Visual integration: check that the card visually fits your LMS — for example by switching ?theme=light and ?theme=dark and verifying how the card adapts. Use this round to validate any other style customization parameter you adopt.

If you see "Content unavailable" during testing, contact Osteocom Support with the iframe URL you used and we'll help you diagnose.

Adding more domains or products later

Anything that changes after onboarding — new domains to whitelist, new products to add to your catalog, prices to update — goes through your Osteocom contact. Send a short note and we'll apply the changes.