Getting Started

The Komplett Public API gives partners a single, consistent way to integrate with Komplett. Everything is served through a single API gateway with a common authentication, authorization and error model; each capability (orders, checkout, customers) has its own reference document.

This is work in progress — anything not yet final is marked [TODO].

---

Base URL

Each store has its own base URL, written <store-url> throughout these docs. All API paths are relative to it:

https://<store-url>/public

Environments

Every store has two environments — a sandbox for integration and testing, and production. Both expose the same API surface; only the host differs (the sandbox host carries a test- prefix). Build and verify your integration against the sandbox, then switch to the production host.

Store	Environment	<store-url>
Komplett Bedrift	Sandbox	https://test-api.komplettbedrift.no
Komplett Bedrift	Production	https://api.komplettbedrift.no
Itegra	Sandbox	https://test-api.itegra.se
Itegra	Production	https://api.itegra.se

For example, the Komplett Bedrift sandbox token endpoint is https://test-api.komplettbedrift.no/public/accesscontrol/v1/token.

---

Authentication

Access uses the OAuth 2.0 Client Credentials flow. Every request is both:

• subscription-gated — via a subscription key, and
• token-protected — via a short-lived access token carrying the scopes you request.

Credentials you receive

We provision and hand over to you:

Credential	Header / usage	Purpose
Client ID	part of the Authorization: Basic header	identifies your application
Client Secret	part of the Authorization: Basic header	authenticates your application
Subscription Key	Ocp-Apim-Subscription-Key header	grants access through the API gateway
Store URL	base of every request URL (<store-url>)	unique to your store

Treat the Client Secret and Subscription Key as sensitive — store them securely and never embed them in client-side code or commit them to source control.

Step 1 — Request a token

POST /public/accesscontrol/v1/token

POST https://<store-url>/public/accesscontrol/v1/token
Content-Type: application/x-www-form-urlencoded
Ocp-Apim-Subscription-Key: {your_subscription_key}
Authorization: Basic base64({client_id}:{client_secret})

grant_type=client_credentials&scope={requested_scopes}

As curl:

curl -X POST \
  "https://<store-url>/public/accesscontrol/v1/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -H "Ocp-Apim-Subscription-Key: {your_subscription_key}" \
  -u "{client_id}:{client_secret}" \
  -d "grant_type=client_credentials" \
  --data-urlencode "scope=order:read"

Notes:

• grant_type is always client_credentials.
• Authorization: Basic is the standard base64 encoding of {client_id}:{client_secret} (curl -u builds this for you).
• scope declares the permissions the token should carry — request only what you need. For multiple scopes, separate them with spaces, e.g. scope=order:read customer:read.

Step 2 — Use the token

The response is 200 OK with a JSON body containing the access token and its lifetime. Send the token as a bearer token on every API call, alongside your subscription key:

GET https://<store-url>/public/orders/v1/{orderId}
Authorization: Bearer {access_token}
Ocp-Apim-Subscription-Key: {your_subscription_key}

Token lifetime & refresh

Tokens are short-lived — currently 30 minutes. Rather than requesting a token per call, request one and reuse it until it is close to expiry, then request a fresh one. Read the lifetime from the token response (expires_in) rather than hard-coding it. The token endpoint responds with Cache-Control: no-store, so tokens should not be cached by intermediaries.

---

Scopes

Scopes control which API areas a token can access. Request only the scopes your integration needs.

Scope	Grants	Protects
order:read	Read orders	GET /orders/v1/*
returns:read	Read returns	GET /returns/v1/*
customer:read	Read customer details	GET /customers/v1/*
komplettpc:read	Browse bundle structure, validate compatibility, check configuration availability	GET /komplettpc/v1/bundles/*, POST /komplettpc/v1/compatibility/*, POST /komplettpc/v1/configurations/check-availability
komplettpc:write	Save PC configurations	POST /komplettpc/v1/configurations
order:write	Place and modify orders	/checkout/v1/* (create, get, submit), PATCH /orders/v1/{orderId}/cancel

---

Access control

Authorization is layered:

1. Scope check — your token must carry the scope that protects the endpoint (e.g. order:read), otherwise the call is rejected with 403 Forbidden.
2. Per-resource entitlement — beyond scopes, you only see resources your account is entitled to (e.g. orders you own, placed, or have a relationship with). Requesting a resource you are not entitled to returns 403 Forbidden; in list responses, such items are silently omitted.

Entitlements are not self-service. Which customers/accounts you are entitled to act on is configured by Komplett — not something you set through the API. To request or change your entitlements, contact your Komplett Account Manager.

---

Conventions

Each API reference documents its own payloads, but these conventions are common:

• Format: JSON only (Accept: application/json). Field names are camelCase.
• Enums are serialized as strings, never numbers.
• Timestamps are ISO 8601 with an explicit UTC offset, e.g. 2026-05-01T09:32:00+02:00.
• Errors use the RFC 9457 Problem Details JSON format, with a stable machine-readable code and a traceId.
• Every response carries an X-Trace-Id header — quote it when contacting us so we can correlate the request with our logs.

More in Error Reference

---

API references

API	Scope	Reference
Orders (read)	order:read	Orders overview
Returns (read)	returns:read	Returns overview
Checkout (place orders)	order:write	Checkout overview
Customers (read)	customer:read	Customers overview
KomplettPC (configurator)	komplettpc:read, komplettpc:write	KomplettPC overview
Webhooks (notifications)	n/a	Webhooks overview

The APIs above are pull — you call us when you want data. Webhooks are push: we call you when something changes, so you do not have to poll. Webhooks need no scope of their own — a notification carries no business data, so the only scope that matters is the one required by the resource you fetch in response to it.