Authorization

Overview

The Hosted Plugins API is simpler than the broader SSO group, but it still has connector-specific differences. Most routes are API-key-driven, with selected endpoints using X-LoginRadius-ApiKey, and one BigCommerce route is modeled as unauthenticated in the current public spec.

This group should be documented carefully because it is easy to overgeneralize its auth behavior.

Primary authentication models

The most common patterns in this group are:

• apikey
• X-LoginRadius-ApiKey

Unlike the Management or Partner IAM groups, this group is not primarily driven by tenant secret plus client secret combinations.

Required credentials

Depending on the route, you may need:

• apikey
• X-LoginRadius-ApiKey

And in at least one case, the current public spec shows no security requirement at all.

Security schemes used in this group

The current public spec uses these schemes in the Hosted Plugins API group:

• APIKey
• XLoginRadiusAPIKey

The spec also includes at least one BigCommerce SSO route with no declared security requirement.

Headers and query parameters

Common auth inputs include:

• query apikey
• header X-LoginRadius-ApiKey

Check the generated operation page for the exact connector route before implementation.

Token usage guidance

Use platform-specific route expectations

These endpoints are connector-specific. Do not assume BigCommerce, Shopify, and PerfectMind all use identical request patterns.

Treat unauthenticated routes as explicit exceptions

If the spec shows a route with no declared security requirement, document and implement it as an exception for that specific route only, not as the default security model of the whole group.

Examples and common patterns

Typical patterns include:

• generating a Shopify login URL from a LoginRadius-authenticated context
• generating or validating BigCommerce SSO artifacts
• retrieving PerfectMind session or contact data for an integrated flow

Common auth errors and pitfalls

• assuming all hosted plugin routes use exactly the same auth inputs
• treating an unauthenticated connector route as proof that the whole group is public
• mixing query API key usage with header-based X-LoginRadius-ApiKey usage
• assuming these routes behave like general-purpose OAuth or SAML endpoints

Use the generated operation page for each connector route as the final authority.