Identity for Embedded Partners (3PI)¶
Third-party integration (3PI) partners embed Vellocity capabilities inside their own platforms. There are two distinct identity questions for a 3PI, and it's important not to conflate them. This page keeps them separate.
The two lanes at a glance
| Lane | Who signs in | Status |
|---|---|---|
| A — Workforce SSO | Your team, into Vellocity | Available now |
| B — Embedded end-user identity | Your customers, inside your product | Roadmap |
Lane A — Workforce SSO (available now)¶
This is your own team — the people at your company who operate the Vellocity integration, manage listings, or build with the API — signing in to Vellocity with your identity provider.
It is exactly the standard Enterprise SSO onboarding flow. You register a SAML or OIDC application in your IdP, we scope a federation to your organization, and your staff sign in with their work email. Everything on the overview page applies: JIT provisioning, verified domains, per-organization scoping, and organization seat plans.
If your team already uses Microsoft Entra ID, Okta, or AWS IAM Identity Center, follow the matching per-IdP walkthrough. There is nothing 3PI-specific to configure for this lane — your integration's API keys and partner access are managed separately from how your staff log in.
Lane B — Embedded end-user identity (roadmap)¶
This is a different problem: your own customers, using your product, encountering a Vellocity-powered surface embedded inside it — and arriving there pre-authenticated, without a second login.
The planned approach is to let a 3PI federate its own platform as an OIDC identity provider into Vellocity, so that a user already signed in to your product is recognized on the embedded Vellocity surface without re-authenticating. This keeps the experience seamless and keeps you as the identity authority for your users.
This lane fits the broader agent-ready direction of the Embedded Partner Pilot: as buyers increasingly arrive through agents and embedded experiences rather than a standalone login page, identity has to travel with the request. Federating your platform's identity is how an embedded Vellocity capability knows who it's acting for.
Not yet available
Embedded end-user identity federation is on the roadmap and is not available today. If it's important to your integration, tell your Vellocity contact so we can factor your requirements into the design. In the meantime, embedded capability calls are authenticated with your partner API keys — see the Embedded Partner Pilot documentation.
Which lane do you need?¶
- "I want my staff to log in to Vellocity with our company IdP." → Lane A. Start with the onboarding guide.
- "I want my customers to use an embedded Vellocity feature without a separate login." → Lane B (roadmap). Talk to your Vellocity contact.
- "I want my application to call Vellocity capabilities programmatically." → Neither — that's partner API-key authentication. See the Embedded Partner Pilot docs.