Issue Management API Reference

This document provides the technical specification for programmatically managing issues and error logs on the GIIP platform.

🔌 Go to Issue Management Feature →

📋 Overview

The Issue Management API is used by automation scripts or AI agents to retrieve and process server failures, error logs, and task statuses. It provides two primary methods of invocation.

---

🔐 Authentication

This section explains the types of keys this API accepts, how to pass them, and why you get a 401, all grounded in the actual server code (giipfaw/giipIssues/run.ps1, giipfaw/giipIssueComments/run.ps1, the corresponding pApiGiipIssue*byAK stored procedures) and live testing against giipfaw production (2026-08-20). For the shared AK/SK vocabulary, see API Reference Overview → Authentication.

x-api-key is the HTTP header NAME, not a separate credential type. Put a valid Project SK, user-level static key, or login-session AK directly as this header's value. If you use a Project SK, you do NOT need to issue any separate "API key".

How to pass the key — headers only (verified live)

Method	Supported?
x-api-key: <key> header	✅ Supported (recommended)
Authorization: Bearer <key> header	✅ Supported (alternative)
JSON body { "token": "<key>" }	❌ Not supported — the server code never reads it; sending it returns 401 Auth required
Query string ?token=<key>	❌ Not supported / deprecated — same as above. Putting a key in a query string is also a security anti-pattern regardless: it gets logged in server logs, browser history, and proxy logs.

An earlier version of this doc claimed the body/query methods worked. In reality, the run.ps1 for both giipIssues and giipIssueComments only reads $Request.Headers["x-api-key"], falling back to the Authorization header — nothing else. Confirmed by source review and live testing, 2026-08-20; the incorrect claim has been removed. Always pass the key via a header.

Key types (three kinds, different authorization scope)

Type	Backing store	Issued per	Scope	Issued/checked at	How to verify
Project SK (recommended for agents)	tSecretKey.SKey	One per project (csn)	That csn only. The caller is not individually identifiable — it's a shared key (confirmed live: the client-supplied author on a comment is used verbatim when a project SK is used, because the SP cannot resolve a personal identity from it)	/svclist (Service List) screen	See "Verifying auth before writing" below
User-level static key (tCorpUser.uSecretKey)	Same table	One per user (usn)	That user's own csn memberships (tUserPerCorp/tCorpUserRel); every csn if the user has admin level (uLevel ≥ 99)	Issued by an admin (giipv3 user management screen)	Same as above
Login session AK	tUserLogin.AccToken	Freshly issued on each login, expires after 24 hours	Same permissions as the logged-in user	Auto-issued on browser login (sessionStorage)	Same as above

All three are passed the same way — in the x-api-key header — and the server auto-detects which one it is (lwGetUSNbyat, falling back to lwGetUSNbysk on failure). The response alone can't tell you which type the caller used (success/failure behavior is identical), but authorization scope differs by type.

Live testing in this session mainly used a project SK (the production SK registered in giip-accounts.json). The user-level static key and login-session AK could not be freshly issued in this session (no browser login available), so those two are confirmed only by source code review (the 3-step fallback in lwGetUSNbyat.sql — not live-tested; stated here honestly).

SK requirements (all verified live + in code)

• Where it's issued: giipv3's /svclist (Service List) screen, one per project (csn).
• Active check: only valid while tSecretKey.SKStatus = 1. Re-issuing/rotating a key immediately sets the old one's SKStatus = 0, and it starts returning 401 Invalid session (verified for giip #1265: both the active-SK-succeeds and deactivated-SK-fails cases were reproduced live).
• Bound csn: fixed 1:1 to tSecretKey.CSn. It cannot access another csn unless the caller is sysadmin (see "CSN mismatch behavior" below).
• Required permissions: none beyond the key itself — the SK is the csn grant.
• Expiry: no time-based expiry (unlike the 24-hour login-session AK). It only becomes invalid when re-issued/rotated.
• Allowed endpoints: works on all of GET/POST/PUT /api/giipIssues and GET/POST /api/giipIssueComments (verified live). It must not be used for writes via the Sk2 GiipIssuePut command, which is a different, full-overwrite SP (see Method 2 below).
• Read API to verify the key: before calling a write endpoint (POST/PUT), you can safely check whether a key is valid using the side-effect-free GET /api/giipIssues (see next section).
• How to re-issue: regenerate the SK for the target csn on /svclist. The old value is invalidated immediately, so update any automation that depends on it at the same time.

Verifying auth before writing

Before calling a write endpoint (POST/PUT), verify the key with a side-effect-free GET first.

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://giipfaw.azurewebsites.net/api/giipIssues?csn=47" \
  -H "x-api-key: ${GIIP_API_KEY}"

• On success (200): {"issues":[...]} — this key is safe to use for the create/update endpoints too.
• On failure (401): either {"error":"Auth required"} (the header itself is missing/unread) or {"error":"Invalid session"} (the key is present but invalid — see "Root causes of 401 Invalid session" below). Do not proceed to call the create endpoint in this case.

---

Both paths below are fully functional. Use the dedicated REST endpoints (the path the giipv3 admin UI actually uses) for CRUD such as creating issues and comments; use the giipApiSk2 wrapper for direct SP calls.

🚀 Method 1: Dedicated Endpoint (REST API)

The most intuitive way to interact with issues. Auth via the x-api-key header, Content-Type application/json. Pass the key via an environment variable — never hardcode it.

1. Create Issue (New)

• URL: POST /api/giipIssues — omit isn (or send 0) to INSERT a new issue; the new isn is returned.

curl -s -X POST "https://giipfaw.azurewebsites.net/api/giipIssues" \
  -H "x-api-key: ${GIIP_API_KEY}" -H "Content-Type: application/json" \
  -d '{ "title": "Title (required)", "content": "Body", "status": "PENDING",
        "csn": 47, "target_lssn": null, "agent_workflow": null }'

• Success: { "isn": 577, "message": "Issue created", "success": true } (verified live 2026-08-20, isn 1282, deleted after the test)

2. List Issues

• URL: GET /api/giipIssues
• Query Parameters:
  • status: (Optional) Issue status (READY, PENDING, DONE, etc.)
  • isn: (Optional) Specific issue serial number
  • csn: (Optional, but recommended) Project number to fetch. Omitting it returns every csn within the key's scope.
• Response: { "issues": [...] }

3. Update Issue Status

• URL: PUT /api/giipIssues (POST also accepted)
• Body (JSON): { "isn": 7890, "status": "DONE" } → { "success": true }

4. Add Comment

• URL: POST /api/giipIssueComments
• Body (JSON): { "isn": 7890, "content": "Closed.", "author": "api-tester", "issuetype": "comment" } → { "success": true }
• Fetch comments: GET /api/giipIssueComments?isn=7890 → { "comments": [...] }

Delivery method summary (verified live, 2026-08-20)

Endpoint	x-api-key header	Authorization: Bearer header	JSON body token	Query ?token=
GET /api/giipIssues	✅ verified 200	✅ verified 200	❌ not read (401)	❌ verified 401
POST /api/giipIssues (create)	✅ verified 200	same code path (not separately tested, high confidence)	❌ verified 401	❌ verified 401
PUT /api/giipIssues (status)	✅ verified 200	same code path (not separately tested, high confidence)	❌ verified 401	same code path (not separately tested, high confidence)
POST /api/giipIssueComments	✅ verified 200	same code path (not separately tested, high confidence)	❌ verified 401	❌ verified 401
GET /api/giipIssueComments	✅ verified 200	same code path (not separately tested, high confidence)	❌ not read	❌ not read (not separately tested, high confidence)

"Same code path (high confidence)" means: the auth-extraction code ($Request.Headers["x-api-key"], falling back to the Authorization header — nothing else) is byte-for-byte identical across all four endpoints in giipfaw/giipIssues/run.ps1 and giipIssueComments/run.ps1, confirmed by source review. We did not execute all 20 cells of this matrix live; we tested the primary ones and relied on code review for the rest.

Auth-error behavior (verified live 2026-08-24): Earlier versions of this doc described a known bug where GET /api/giipIssueComments returned HTTP 200 for an invalid key. This is now FIXED (giip #1285). It now behaves like GET /api/giipIssues: an invalid key returns HTTP 401 {"error":"Invalid session"} (verified live against the giipfaw API on 2026-08-24). You can rely on the HTTP status to determine auth success/failure.

CSN mismatch behavior (not a 401)

When the key is valid but lacks access to the target csn, the result is not a 401 (verified live, 2026-08-20).

Call	Result verified live
GET /api/giipIssues?csn=<no access>	200 {"issues":[]} (empty array, not an error)
POST /api/giipIssues with a csn the key has no access to	Returns 200 success, but the requested csn is ignored — the issue is silently created under the key's own home csn instead (verified: a csn-70335 project SK given csn:47 in the body created the issue under cSn:70335)
GET/PUT/comment-add on a specific isn whose csn the key can't access	404 {"error":"Issue not found or no permission"}

---

Supported status values and the multi-status query pattern

Supported status values (live-verified, 2026-08-27):

Status	Meaning
PENDING	Registered, not yet processed
READY	Ready to be processed
IN_PROGRESS	Being processed
REVIEW	Awaiting human review
TESTED	Tested, awaiting final acceptance review
WARN	Warning / conditional completion
DONE	Completed

Multi-status query — only single exact-match filters are supported (important):

OR-style queries such as GET /api/giipIssues?status=TESTED,REVIEW or status=TESTED|REVIEW are not supported. Commas, pipes, and repeated parameters are all treated as a single exact-match string and will not behave as intended.

When a bulk-processing workflow (e.g. /gissue-final-review) needs to handle both TESTED and REVIEW, query each status separately and combine them in order on the client side:

# 1. Query TESTED first
TESTED_ISSUES=$(curl -s "https://giipfaw.azurewebsites.net/api/giipIssues?status=TESTED&csn=47" \
  -H "x-api-key: ${GIIP_API_KEY}")

# 2. Query REVIEW
REVIEW_ISSUES=$(curl -s "https://giipfaw.azurewebsites.net/api/giipIssues?status=REVIEW&csn=47" \
  -H "x-api-key: ${GIIP_API_KEY}")

# 3. Combine on the client in TESTED → REVIEW order
# (jq, Python, JS, etc.)

Note: This is a queue snapshot as of query time, so new REVIEW issues may arrive while TESTED issues are still being processed. To honor the workflow's "initial snapshot" rule, run both queries at the same time and leave any issues added afterward for the next execution cycle.

Full comment retrieval:

GET /api/giipIssueComments?isn=<isn> returns all comments of the target issue in chronological order. In the AI agent's final acceptance review workflow (/gissue-final-review), a worker's completion report or an Actionflow SUCCESS comment is a claim to be verified, not proof of passing — you must obtain independent evidence by directly cross-checking the repo, PR, screen, and DB.

---

🤖 Full procedure for AI agents (create → verify → partial update → comment)

A complete sequence for AI agents (ChatGPT/Codex, etc.) to safely create, partially update, and comment on issues. Verify with GET before and after every write. Put secrets only in the x-api-key header — never in the body/query.

Partial update (title/content/status) — not a full overwrite

The dedicated REST PUT /api/giipIssues is a partial update. Its internal SP pApiGiipIssuePutbyAK updates each field with ISNULL(@value, existing), so any field you omit from the JSON keeps its existing value (verified against SP source, 2026-08-24). Updatable fields: title / content / status / target_lssn / agent_workflow (and csn if you have permission).

# Update only title and content (status and other fields stay as-is)
curl -sS -X PUT "https://giipfaw.azurewebsites.net/api/giipIssues" \
  -H "x-api-key: ${GIIP_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"isn":1474,"title":"Revised title","content":"Revised body"}'

• Do not include fields you don't want to change (including them overwrites them).
• An empty string is NOT "unspecified." Sending "title":"" overwrites the title with an empty value. Don't send it unless you intend to clear the field.
• Sk2's GiipIssuePut is a full-overwrite SP (pApiGiipIssuePutbySK), so it is forbidden for edits (it destroys the title/body — see Method 2). Use the dedicated REST PUT.

Long content (over 4,000 characters is fine)

content is read by the SP as OPENJSON ... NVARCHAR(MAX), so you can create and update Markdown bodies longer than 4,000 characters (verified against SP source, 2026-08-24). You can turn a long work order directly into an issue.

• Send it as UTF-8 JSON.
• Rather than embedding long text directly in the shell, it is safer to build the JSON from a file and send that:

# Prepare body.json with {"isn":1474,"content":"...(long text)..."}
curl -sS -X PUT "https://giipfaw.azurewebsites.net/api/giipIssues" \
  -H "x-api-key: ${GIIP_API_KEY}" -H "Content-Type: application/json" \
  --data-binary @body.json

• After posting, confirm the full body was stored by comparing the body length or a hash (e.g. sha256) via GET /api/giipIssues?isn=<isn>.

Adding a comment (required fields and post-save verification)

{ "isn": 1474, "content": "Comment body", "author": "ChatGPT Work", "issuetype": "comment" }

• Required: isn, content.
• Defaults: author=Agent, issuetype=comment.
• Beware saved-author normalization: depending on the credential type and server-side identity resolution, the author you send may be normalized to a username on save (verified live 2026-08-24: a comment sent with author="ChatGPT Work" was stored as author="Lowy Shin"). Do not assume the sent author is stored verbatim — after adding, verify the content and the actual stored author via GET /api/giipIssueComments?isn=<isn>.
• Before commenting, also confirm the target CSN via GET /api/giipIssues?isn=<isn>.

End-to-end example (create → verify → partial update → re-verify → comment → verify)

# 1. Verify auth + CSN scope (read-only preflight)
curl -sS "https://giipfaw.azurewebsites.net/api/giipIssues?csn=47" -H "x-api-key: ${GIIP_API_KEY}"

# 2. Create (capture the returned isn)
curl -sS -X POST "https://giipfaw.azurewebsites.net/api/giipIssues" \
  -H "x-api-key: ${GIIP_API_KEY}" -H "Content-Type: application/json" \
  -d '{"title":"AI test issue","content":"initial body","csn":47}'

# 3. Confirm the actual cSn (mandatory — a CSN mismatch is silently clamped to the home CSN)
curl -sS "https://giipfaw.azurewebsites.net/api/giipIssues?isn=<isn>" -H "x-api-key: ${GIIP_API_KEY}"

# 4. Partial update (title only; content is preserved via ISNULL)
curl -sS -X PUT "https://giipfaw.azurewebsites.net/api/giipIssues" \
  -H "x-api-key: ${GIIP_API_KEY}" -H "Content-Type: application/json" \
  -d '{"isn":<isn>,"title":"AI test issue (edited)"}'

# 5. Re-GET to confirm the unspecified field (content) was preserved
curl -sS "https://giipfaw.azurewebsites.net/api/giipIssues?isn=<isn>" -H "x-api-key: ${GIIP_API_KEY}"

# 6. Add comment
curl -sS -X POST "https://giipfaw.azurewebsites.net/api/giipIssueComments" \
  -H "x-api-key: ${GIIP_API_KEY}" -H "Content-Type: application/json" \
  -d '{"isn":<isn>,"content":"done","author":"ChatGPT Work","issuetype":"comment"}'

# 7. Verify the comment (compare stored author and content via GET)
curl -sS "https://giipfaw.azurewebsites.net/api/giipIssueComments?isn=<isn>" -H "x-api-key: ${GIIP_API_KEY}"

Detecting the CSN silent clamp: if the csn you specify on POST is outside your permissions, it does not error — it is silently clamped to the key's home CSN. Always confirm cSn is what you intended via the re-GET in step 3.

---

🚀 Method 2: Universal API Wrapper (giipApiSk2)

A powerful SK-based method that directly calls GIIP Stored Procedures. Highly recommended for AI agents. Listing, fetching, and status updates all work through this path.

• URL: POST /api/giipApiSk2
• Content-Type: application/x-www-form-urlencoded
• Fields:
  • token: [Your_SK] — pass the SK only in this field (never in text/jsondata)
  • text: [Command] [Params...]
  • jsondata: (Optional) JSON for value mapping, e.g. {} or {"isn":7890,"status":"DONE"}

⚠️ text rule (strict): List in text only the exact parameters the SP accepts, in order. The engine (run.ps1) handles auth (@sk) and jsondata automatically, so never list them. Over-listing exceeds the SP's argument count and triggers has too many arguments specified.

Common Command Examples (safe)

Feature	SP params (list in text)	text Example	Success
List Issues	status	GiipIssueList READY	data (issue array)
Get Details	isn	GiipIssueGet 7890	data[0] (one issue)
Dispatch (remote run)	isn	GiipIssueDispatch 7890	data[0].RstVal = 200

🚫 Do NOT use GiipIssuePut via Sk2 to change status (data-destruction risk). Sk2 GiipIssuePut maps to pApiGiipIssuePutbySK(@sk, @isn, @title, @content, @status, @csn) — a full overwrite (no coalesce). Calling GiipIssuePut 7890 DONE puts the 2nd value DONE into @title and the 3rd (jsondata) into @content, destroying the title and body. The response still shows RstVal:200 (a false success) even though the record is corrupted (verified 2026-07-09, task 20260708183049). To change only the status safely, use the dedicated REST PUT /api/giipIssues {isn, status}. Its pApiGiipIssuePutbyAK uses ISNULL(@title, title) to preserve the existing title/body — this is the path the giipv3 front end actually uses.

---

🔍 Response Standard

giipApiSk2 (SP wrapper) response — reads return records in data; SP actions (e.g. Dispatch) return RstVal = 200 on success:

{ "data": [ { "RstVal": 200, "Proc_MSG": "Dispatched", "isn": 7890 } ] }

List/Get commands return the issue records in the data array.

Dedicated REST endpoint response — success is success: true (no RstVal in the body):

{ "isn": 7890, "message": "Issue updated", "success": true }

ℹ️ Success check: The SP success code is RstVal = 200, not 0; failures return 400/401/403/404 (K-Layer CLAIM-006). Dedicated endpoints return a success boolean instead of RstVal.

---

⚠️ Important Notes

• 500 Internal Server Error: If you encounter "The term 'if' is not recognized", it is a PowerShell compatibility issue on the server. Ensure the latest patch (v1.0.1+) is applied.
• CSN Restriction: To access issues belonging to specific project groups, the API key must have the appropriate permissions for those projects (actual behavior is in "CSN mismatch behavior" above — not a 401, but an empty result / 404 / silent clamp).

Root causes of "401 Invalid session"

There are two distinct 401 error messages, and they mean different things (verified live, 2026-08-20).

Response	Cause
{"error":"Auth required"}	The key never reached the server — no x-api-key/Authorization header, or an unsupported delivery method was used (JSON body token, query ?token=, a misnamed header, etc.)
{"error":"Invalid session"}	The key arrived but is invalid — one of the causes below

Specific causes of Invalid session:

1. The key value is a typo or doesn't exist (matches no AK/SK table at all)
2. A previously-valid project SK was deactivated by re-issuing/rotating it (SKStatus=0) — verified live for giip #1265
3. A login-session AK exceeded its 24-hour lifetime (tUserLogin.AccToken; confirmed by code only, not live-tested)

Cases this does NOT cover (common misconceptions):

• Using an SK where only an AK is expected, or vice versa → does not apply. giipIssues/giipIssueComments accept either AK or SK interchangeably; there is no separate endpoint per key type (verified live + in code).
• Lacking permission for the target csn → not a 401 — see "CSN mismatch behavior" above (empty result / silent clamp / 404, depending on the call).

Troubleshooting

Symptom	Cause	Solution
{"error":"Auth required"} (401)	No key in a header, or it was sent via body/query (unsupported)	Pass it as x-api-key: <key> (or Authorization: Bearer <key>). Body token / query ?token= don't work
{"error":"Invalid session"} (401)	Typo, deactivated (re-issued/rotated) key, or expired session	Re-verify with the GET from "Verifying auth before writing" above. Check the currently active SK for the target csn on /svclist
Project's issues come back as [] (empty)	Key is valid but lacks access to that csn (this is not a 401)	Use a key scoped to that csn, or ask an admin to grant access
POST with a csn created the issue under a different csn	Requesting a csn the key can't access silently clamps to the key's home csn (verified, see above)	After creating, check the actual cSn via GET /api/giipIssues?isn=<isn>. If you need to create under a different csn, ask an admin to grant tUserPerCorp membership
Command ignored or empty result (Sk2)	Malformed text parameter (command and params not separated)	Follow the [Command] [Params] format, e.g. GiipIssueList READY
... has too many arguments specified (Sk2)	Too many params listed in text	List only the SP's exact params. @sk and jsondata are handled by the engine — never list them
Title/body destroyed (became DONE/{}) after a status change (Sk2)	Used Sk2 GiipIssuePut (a full-overwrite SP) to change status	Change status via the dedicated REST PUT /api/giipIssues {isn,status} (Method 1). Never use Sk2 GiipIssuePut for writes
Response data[0].RstVal is not 200 (Sk2)	SP execution error or invalid isn	Check Proc_MSG, then see the API Result Codes guide. Success is 200, not 0

---

Version: 1.7 Last Updated: 2026-08-27 (Tested against: giipfaw production, pApiGiipIssue*byAK SP family — every live-verified result above was captured against production on this date) Source File: giipv3/public/help/giip-issue-api.en.md

v1.7 changelog (2026-08-27, giip #1484): Added the following to complete the issue-processing workflow (/gissue-final-review): ① a supported-status-values table (7 statuses including TESTED/WARN); ② the multi-status query pattern — the operational API only supports single exact-match filters (TESTED,REVIEW / TESTED|REVIEW forms do not work), so query each status separately and combine on the client; ③ chronological full-comment retrieval, plus the verification principle that in the FINAL-REVIEW workflow a worker's completion report is a "claim" and only independent evidence from directly cross-checking repo/PR/screen/DB counts as passing.

v1.6 changelog (2026-08-24, giip #1475): Added an end-to-end procedure section for AI agents (partial update / long content / comment author-normalization / a full create→verify→partial-update→comment CRUD example). Clarified that x-api-key is a header name, not a separate credential type. Removed the outdated "known bug" note that GET /api/giipIssueComments returns HTTP 200 for an invalid key — it is now fixed (giip #1285; HTTP 401 confirmed by live testing 2026-08-24).

v1.5 changelog (2026-08-20, giip #1280): Substantially expanded authentication coverage. ① Confirmed by source review + live testing (4 endpoints) that JSON body token and query ?token= never actually work on giipIssues/giipIssueComments, and removed the incorrect claims that they did (query-string auth is also flagged as a security anti-pattern and formally deprecated in this doc). ② Organized the three key types (project SK / user-level static key / login-session AK) by their backing table (tSecretKey/tCorpUser.uSecretKey/tUserLogin.AccToken). ③ Added a safe pre-write key verification step. ④ Split 401 into "Auth required" (key never arrived) vs. "Invalid session" (key arrived but invalid), and documented — with live verification — that a csn permission mismatch is never a 401 (it's an empty result, a silent clamp, or a 404). ⑤ Found and documented a bug where GET /api/giipIssueComments returns HTTP 200 even for an invalid key (filed as a follow-up issue). ⑥ Switched the create-issue example from a hardcoded key to an environment variable (${GIIP_API_KEY}).

v1.4 changelog (2026-08-20, giip #1265): Verified a report of 401 Invalid session when calling POST /api/giipIssues with an SK. The live Azure SQL definition of pApiGiipIssuePutbyAK is byte-for-byte consistent with the repo source and already has the SK fallback (lwGetUSNbyat failure → lwGetUSNbysk) deployed correctly (not a deployment gap). Live reproduction confirmed: an active SK returns 200 Issue created; a deactivated (rotated/re-issued) SK returns 401 Invalid session (both tested directly against the live giipfaw API, 2026-08-20). So this was not a code defect — it was the docs not explaining which SK is valid. Added the active-SK requirement and the /svclist re-check path to Authentication and Troubleshooting.

v1.3 changelog (2026-07-09, task 20260708183049): Reconciled against the live production API (giipv3 front · giipApiSk2 · SP sources). ① Added a Sk2 write-path danger warning: Sk2 GiipIssuePut maps to the full-overwrite SP pApiGiipIssuePutbySK(@sk,@isn,@title,@content,@status,@csn), so GiipIssuePut 7890 DONE destroys the title/body (returning a false RstVal:200). Verified live (issues 577/578 corrupted, then restored). Writes (create/status/comment) now steer to the dedicated REST endpoints; Sk2 is documented for reads and actions only. (The old report's "too many arguments / incompatible" note was a partial observation; the real hazard is that the SP is a full overwrite.) ② Success code is RstVal = 200 (not 0) — corrected response example and troubleshooting table. ③ Added the issue-creation procedure (POST /api/giipIssues, omit isn) and safe status change (PUT /api/giipIssues {isn,status}, ISNULL-preserving).

---

Related Documents:

• API Reference Overview (shared AK/SK definitions)
• CatQuest Data API (this API's read-only sibling doc)
• API Result Codes Guide (RstVal)