REST API Reference
Conventions and Authentication
Shared conventions for `curl` examples, environment variables, auth patterns, and capability gates used across every /mltk/** endpoint.
Conventions for curl examples Permalink to this section
Examples assume the following environment variables:
export SPLUNK_HOST=https://splunk.example.com:8089
export SPLUNK_USER=admin
export SPLUNK_PASSWORD='changeme'
# OR use a session token / bearer token:
export SPLUNK_TOKEN='eyJraWQ...'
Two equivalent auth patterns are shown:
| Pattern | curl flag | Notes |
|---|---|---|
| Basic auth | -u "$SPLUNK_USER:$SPLUNK_PASSWORD" |
Easiest for ad-hoc testing |
| Bearer token | -H "Authorization: Bearer $SPLUNK_TOKEN" |
Requires a Splunk authentication token |
All responses default to output_mode=json. Append ?output_mode=json to GETs if your client defaults to XML.
-k is shown for self-signed cert dev environments — drop it in production.
Authentication Permalink to this section
Every endpoint requires an authenticated Splunk session. Endpoints that touch shared configuration or KV collections additionally check capabilities and per-record ACLs (see Appendix B).
Common capability gates:
| Capability constant | Used by |
|---|---|
edit_ai_commander_config, list_ai_commander_config |
aicommander, aicommander_metadata |
AGENT_RUN_CAPABILITIES |
agents POST / PUT / DELETE |
AGENT_CONNECTION_CAPABILITIES |
mcp_connection, vector_stores write paths |
SAGEMAKER_REGISTER_MODEL_CAPABILITIES |
register_model |
upload_lookup_files, upload_onnx_model_file |
upload_model |
LLM_CAPABILITIES, DOCKER_DSDL_CAPABILITIES, KUBERNETES_DSDL_CAPABILITIES |
list_connections |
A 403 response with {"status": "fail", "message": "User is not eligible…"} signals a capability failure. A 403 with an ACL message indicates the record exists but the caller cannot read or write it.