Using the interactive API reference

The K12Panel API interactive reference lives at:

https://my.k12panel.com/api/public/v1/docs

(If your panel is on a different domain, substitute it: https://<your-panel-domain>/api/public/v1/docs.)

The reference is generated directly from the running code, so it is never out of date. When an endpoint gains a field, the reference shows it the same day. This KB teaches the concepts and workflows; the reference is the authoritative field-by-field detail.

Reading the page

You do not need to sign in to read the reference — it describes what the API can do, not your data.

Endpoints are grouped by the record they act on (assets, people, sites, and so on). Click any endpoint to expand it. Each one shows:

• Parameters — what you can send in the URL (for example, serial on GET /assets), which are required, and what each one means.
• Request body — the exact JSON shape for POST and PATCH calls, with every field, its type, and whether it's optional.
• Responses — the shape of a successful response, plus the errors the endpoint can return (401, 403, 404, 409, 422 — see Handling errors).

At the bottom of the page, the Schemas section lists each record type in full — this is the quickest way to see every field an asset or a person has.

Making a real call from the browser

The reference can act as a working API client. This is the fastest way to see an actual response before you write a line of code.

1. Click Authorize at the top right.
2. Paste your API key — just the key itself, starting with k12_live_. Don't type the word Bearer; the page adds it for you.
3. Click Authorize, then Close.
4. Open any endpoint, click Try it out, fill in the parameters, and click Execute.

You'll see the real response body, the status code, and — useful for your own code — the exact curl command the page built, which you can copy and paste straight into a terminal.

These are real calls against your live organization. A GET is harmless, but a checkout, check-in, or PATCH executed from this page changes your data exactly as if a staff member had done it in the app. When exploring, authorize with a key that only has read permissions (see Getting started).

If a call returns 401, the key is missing, wrong, revoked, or expired. If it returns 403, the key is valid but lacks the permission that endpoint needs — the reference lists the required permission on each endpoint.

The raw OpenAPI schema

The same reference is available as a machine-readable OpenAPI document:

# YAML (default)
curl https://my.k12panel.com/api/public/v1/schema

# JSON
curl "https://my.k12panel.com/api/public/v1/schema?format=json"

Most API tooling understands this format directly. Two common uses:

• Import it into Postman or Insomnia to get a ready-made collection of every endpoint.
• Generate a client library for your language with a tool such as OpenAPI Generator, so you call the API through typed functions instead of building requests by hand.

Because the schema is generated from the code, regenerating your client after an upgrade picks up any new fields automatically.

What the reference doesn't cover

The reference documents what each endpoint accepts and returns. It doesn't explain the ideas behind them — read these first:

• Key concepts — IDs, looking records up by serial or email, and how check-in/out works.
• Common workflows — copy-paste examples for the usual tasks.
• Handling errors — including the "more than one match" case, where the API hands you the candidates to choose from.