How K-Series custom integrations work, how they scale, and why the current pricing model leaves revenue on the table.
Lightspeed Commerce — K-Series Partnerships Team
Meet John — an admin user managing a multi-location hospitality business in the U.K. He oversees three K-Series locations: Manchester, London, and Liverpool.
John wants to connect third-party apps to his POS. Because these apps aren't Lightspeed Approved Integrations, he'll need custom API access — the pathway for merchant-initiated or developer-built integrations.
In K-Series, a businessId represents the merchant
account. Each physical location is a
businessLocationId. API access maps to both.
John wants to connect Acco Co., a business intelligence solution, to his K-Series POS. Since Acco Co. isn't an Approved Integration, he requests custom API access.
Lightspeed issues an API Client — a set of OAuth2 credentials unique to this integration. Once John authenticates, an access token is generated for secure data exchange.
Token inheritance rule: In K-Series, the access token follows the user, not the location. If John has access to multiple locations, the token automatically covers all of them.
John has user-level access to Manchester and London — so Acco Co.'s access token automatically covers both. No additional configuration needed.
However, John hasn't been granted access to Liverpool. The token reflects his permissions: Liverpool is excluded.
Grant John access to Liverpool in K-Series, or re-authenticate the integration with a user who already has that location assigned. The token will then cover all three.
Access tokens don't need per-location provisioning. They expand organically with the user's permission set — a design choice that simplifies onboarding but has pricing implications we'll address later.
John's Manchester location is already connected to Acco Co. Now he wants to add One Inc., an online ordering platform.
Each integration receives its own API Client with independent credentials and access tokens. They never share secrets — just like QuickBooks and Uber Eats wouldn't share API keys if both connected to the same POS.
Revoking one integration's access has zero impact on the other. Each client operates in its own security boundary.
Both integrations inherit John's full location access. Since he authenticated both Acco Co. and One Inc., each token automatically covers Manchester, London, and Liverpool.
Access tokens are user-scoped. As John gains access to new locations, every integration he's authenticated scales with him — no re-provisioning needed.
Custom API access has two distinct billable dimensions: the
API Client (one per integration, tied to the
businessId) and
Location Access (one per
businessLocationId the token covers).
From the technical architecture above, two billable components emerge. What follows is how the current pricing model handles them — and where it falls short.
The API architecture has two identifiable components that map to merchant scale. Today, neither is priced to reflect that.
| SKU | Scope | Billing Level |
|---|---|---|
| K-Series Custom Integration | 1× API Client per integration | businessId |
| K-Series API Access | 1× per location connected | businessLocationId |
API access is sold as a flat, bundled fee. The only trigger for an additional charge is a new custom API connection request. Additional locations, expanded user access, or new integrations authenticated under existing clients are effectively absorbed — zero incremental revenue.
businessId (account)
level — a merchant with five locations pays the same as one
with a single location
Net effect: As merchants grow — more locations, more integrations — the value they extract from API access increases linearly. Revenue stays flat.
The current model doesn't track with how merchants scale. As they add locations and integrations, API usage and value increase — revenue doesn't.
Every custom API connection introduces support overhead — OAuth troubleshooting, scope requests, credential recovery. None of it generates incremental revenue beyond the initial flat fee.
When custom API access is priced below its true cost, merchants bypass Approved Partners. Each custom connection potentially displaces an integration that would have driven partner revenue.
The architecture already isolates two growth vectors: the API Client (per integration) and Location Access (per site). Both map directly to how merchants scale — no new infrastructure needed.
Read-only scopes (financial-api,
items) carry lower risk and support cost.
Read-write scopes (orders-api,
staff-api) carry higher operational impact. This
creates a natural pricing tier.
When custom API access reflects its true cost, less committed or less technical merchants naturally default to Approved Partners. Support load stays aligned with higher-value use cases, and the partner channel remains protected.
A scenario-based view of how the two-component model would apply to a merchant as they scale.
Merchant requests access for their first custom integration.
Merchant adds a location that connects to their existing custom app.
Merchant connects a new third-party developer's custom app.
A merchant with 2 custom integrations and 3 business locations: