Vendor onboarding & credentials

This page is about the step BEFORE anything on this site: how a vendor relationship starts, how you get your first login, and how your first API credential comes to exist. Everything past that point — using a credential to call this API — is covered in Getting started and Authentication & capabilities.

1. Linra invites you

There’s no public sign-up. A Linra admin creates your dashboard user (on the Linra Omni Portal, the internal admin dashboard — a separate property from this API) with UserType: Vendor, tied to your vendor record. That action sends you an invitation email with a single-use activation link — no password is set for you, and no credential is issued yet at this point.

2. You activate your account

Following the emailed link takes you to an activation page that calls the activation endpoint with the token from that link plus a password you choose. That single call both sets your password and logs you in — there’s nothing else to do first. The activation link/token is single-use and expires after a fixed window; if it lapses, a Linra admin can resend it.

3. Your FIRST API credential is Linra-issued

This is the rule that matters most: a vendor with zero active API credentials cannot self-mint its first one. Your first clientId/clientSecret pair is generated for you by Linra staff (via the same Portal dashboard) as part of onboarding, scoped to whatever capabilities (Offers/Stock/Cost/Orders/Account) your integration was agreed to need. If you (or your integration) call the self-service generate endpoint before you hold any active credential at all, it fails outright:

// 422
{
  "state": "BUSINESS_VENDOR_FIRST_CREDENTIAL_REQUIRES_ONBOARDING",
  "payload": null,
  "details": { "vendorId": "..." }
}

There is no way around this from the API side — contact your Linra account manager.

4. After that, you self-service — but only within what you already hold

Once you hold at least one active credential, you (as a Vendor-typed dashboard user — on https://omni-portal.linra.net, sidebar Administration → API Credentials, environment chosen with the Environment selector — or directly on this API via POST /api/v1/credentials with the Account capability) can generate further credentials yourself — a second environment, a replacement after rotating a compromised secret, and so on. Self-service can only MATCH OR NARROW the capabilities you already hold across every environment — never widen them. The check is a union across ALL your active credentials, in every environment, not just the one you’re currently generating for:

// 403 — you asked for a capability none of your active credentials have
{
  "state": "FORBIDDEN_CAPABILITY_NOT_GRANTED_TO_VENDOR",
  "payload": null,
  "details": {
    "vendorId": "...",
    "requestedCapabilities": "Offers, Orders",
    "disallowedCapabilities": "Orders"
  }
}

If your integration needs a genuinely new capability, that’s a Linra-side grant — contact your onboarding representative, the same as step 3. Self-service exists to let you reproduce/reissue access you were already given, not to expand it.

The raw secret is shown exactly once

Whether it’s your Linra-issued first credential or one you self-generate later, the response to a generate call is the ONLY time the raw clientSecret is ever returned:

// 201
{
  "state": "CREATED",
  "payload": {
    "id": "cred-guid",
    "environment": "Staging",
    "clientId": "vnd_9f8c2a1b4e6d4a7c9b0e3f2d1c8a5b6e",
    "clientSecret": "•••••••••••••••••••••••••••••••••••••",
    "capabilities": "Offers, Stock",
    "createdAt": "2026-08-02T10:00:00Z"
  }
}

Copy it immediately — every later read (list, get) omits clientSecret entirely. If you lose it, the fix is to rotate/regenerate, not to “reveal” it — there is no reveal endpoint.

Where to go next

• Getting started — your first authenticated call, once you hold a credential.
• Authentication & capabilities — the token model and how capabilities are enforced per request.
• Integration journey — the full path from credential to your first fulfilled order.