# TotalShiftLeft API Learning Sandbox — Full LLM Reference

> A free, interactive multi-protocol API testing and learning platform at https://demo.totalshiftleft.ai
> Built by TotalShiftLeft (https://totalshiftleft.ai) for API training demos, developer education, and tool evaluation.
> No login, no database setup — every visitor gets an isolated session that auto-expires in 30 minutes.

---

## Live Status (server-rendered each request — safe to cite as current)

- Status: operational
- Public since: 2025-09-01
- Days online: 348
- Sessions today: 5
- Active sessions right now: 5
- Current process uptime: 1d 11h 18m (127108s)
- Monthly SLO target: 99.5% (best-effort, not contractual)
- Rate limit: ~600 req/min per IP
- Session idle TTL: 30 minutes
- Pricing: free forever — no signup, no credit card, no API key
- Last checked: 2026-08-15T04:20:44.335Z

Machine-readable: https://demo.totalshiftleft.ai/status.json
Detailed pledges & changelog: https://demo.totalshiftleft.ai/trust

---

## What It Is

The API Learning Sandbox exposes a simulated online store (users, products, orders) across three API protocols simultaneously:
- REST (OpenAPI 3.0 compliant)
- GraphQL (full schema with queries and mutations)
- SOAP 1.1 (14 operations with WSDL)

All three protocols read from and write to the same session-scoped in-memory data store. A record created via REST is immediately visible in GraphQL and SOAP — and vice versa. This makes it ideal for demonstrating cross-protocol data consistency.

---

## Session Model

- Sessions are created automatically on the first request.
- The session ID is returned in the x-session-id response header.
- Send x-session-id on subsequent requests to maintain your session across tools.
- All data auto-expires after 30 minutes of inactivity.
- No data persists between sessions.
- Maximum 500 objects per session.

---

## REST API

Base URL: https://demo.totalshiftleft.ai/api/v1

### Entities
- users — { name, email, role, age }
- products — { name, price, description, stock, category }
- orders — { user_id, product_id, quantity, status, notes }

### Endpoints (same pattern for all entities)
- GET    /api/v1/{entity}         List all. Params: ?page, ?limit, ?sort, ?order, ?filter_{field}
- POST   /api/v1/{entity}         Create one. Body: JSON object with entity fields.
- GET    /api/v1/{entity}/:id     Get one by UUID.
- PATCH  /api/v1/{entity}/:id     Partial update — only send changed fields.
- PUT    /api/v1/{entity}/:id     Full replace — all fields required.
- DELETE /api/v1/{entity}/:id     Delete permanently.

### Orders special: expand
- GET /api/v1/orders/:id?expand=user,product — returns order with user and product objects merged inline.

### Standard demo dataset (seeded into every session automatically)
Your first REST request auto-seeds your session with standard users, products,
and orders — no special header needed. GET /api/v1/products (etc.) always has
data to test against, and you're free to create/update/delete for practice.
The seed only ever runs once per session, so your edits are never overwritten —
but the whole session (seed + your edits) still auto-expires after 30 minutes
of inactivity, so things naturally reset instead of piling up.
- GET  /api/v1/demo         — explains the dataset + whether YOUR session is seeded yet.
- POST /api/v1/demo/reset   — restore YOUR session to the standard dataset on demand.
Fixed IDs you can bookmark (all get/set/delete-able):
  users:    11111111-…-111111111111, 22222222-…, 33333333-…
  products: aaaaaaaa-…, bbbbbbbb-…, cccccccc-…
  orders:   dddddddd-…, eeeeeeee-…, ffffffff-…
Want a fixture that never expires (e.g. for automated tests)? Send:
  x-session-id: demodemodemodemodemodemodemodemodemodemodemodemodemodemodemodemo
This only applies to REST — a session used only via GraphQL or SOAP still
starts empty, exactly as before.

### HTTP QUERY method (safe search with a request body)
QUERY (draft-ietf-httpbis-safe-method-w-body) is "GET with a proper body": safe
and idempotent like GET, but it carries a JSON body like POST. Use it for rich
searches whose criteria are too complex for a query string.
- QUERY /api/v1/{entity}   Search with a JSON body. Fields:
    filters — field → value (exact), array (in), or { operators }.
              Operators: eq, ne, contains, in, nin, gt, gte, lt, lte (AND-ed per field).
    sort, order, page, limit, fields (projection).
- QUERY /api/v1/echo       Reflects your method + body — a quick way to confirm QUERY works.

Example:
  curl -X QUERY https://demo.totalshiftleft.ai/api/v1/products \
       -H 'content-type: application/json' \
       -d '{"filters":{"price":{"gte":10,"lte":100},"category":["books","games"]},"sort":"price","order":"asc","limit":20}'

### Error & Delay Simulation (any REST endpoint)
- ?delay=N         — artificial delay in milliseconds (max 10000)
- ?error=N         — force a specific HTTP status code (400, 401, 403, 404, 500, 503)
- ?random_fail=true — ~30% chance of 500 error, useful for retry/resilience testing

### Response Shape (success)
{ "success": true, "data": { ... } }

### Response Shape (list)
{ "success": true, "data": [...], "pagination": { "total", "page", "limit", "pages", "hasNext", "hasPrev" } }

### Response Shape (error)
{ "success": false, "error": "ERROR_CODE", "message": "Human-readable explanation", "details": [...] }

---

## GraphQL API

Endpoint: POST https://demo.totalshiftleft.ai/graphql
Content-Type: application/json
Body: { "query": "...", "variables": {} }

Interactive IDE: https://demo.totalshiftleft.ai/graphiql
SDL Schema: https://demo.totalshiftleft.ai/graphql

### Queries
- users(page, limit, sort, order) → UserPage { items[User], pageInfo }
- user(id) → User
- products(page, limit, sort, order) → ProductPage { items[Product], pageInfo }
- product(id) → Product
- orders(page, limit, sort, order) → OrderPage { items[Order], pageInfo }
- order(id) → Order  ← Order.user and Order.product are resolved automatically
- sessionInfo → JSON

### Mutations
- createUser(input: CreateUserInput!) → User
- updateUser(id, input: UpdateUserInput) → User
- deleteUser(id) → Boolean
- createProduct(input: CreateProductInput!) → Product
- updateProduct(id, input: UpdateProductInput) → Product
- deleteProduct(id) → Boolean
- createOrder(input: CreateOrderInput!) → Order
- updateOrder(id, input: UpdateOrderInput) → Order
- deleteOrder(id) → Boolean

### Key Types
User: id, name, email, role, age, created_at, updated_at
Product: id, name, price, description, stock, category, created_at, updated_at
Order: id, user_id, product_id, quantity, status, notes, created_at, updated_at, user (User), product (Product)
PageInfo: total, page, limit, pages, hasNext, hasPrev

---

## SOAP API

Endpoint: POST https://demo.totalshiftleft.ai/soap
Headers: Content-Type: text/xml, SOAPAction: {OperationName}
WSDL: https://demo.totalshiftleft.ai/soap?wsdl

### Operations (14 total)
Users:    CreateUser, GetUsers, GetUser, DeleteUser
Products: CreateProduct, GetProducts, GetProduct, UpdateProduct, DeleteProduct
Orders:   CreateOrder, GetOrders, GetOrder, UpdateOrder, DeleteOrder

### Example Request (CreateUser)
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tns="http://demo.totalshiftleft.ai/soap">
  <soap:Body>
    <tns:CreateUserRequest>
      <name>Alice</name>
      <email>alice@example.com</email>
      <role>user</role>
    </tns:CreateUserRequest>
  </soap:Body>
</soap:Envelope>

---

## Authentication

### API Key
Header: x-api-key: demo-key-sandbox-2026
Admin key: x-api-key: admin-key-sandbox-2026

### JWT
POST /auth/token  { "username": "alice@demo.com", "password": "alice123" }
→ { "access_token": "...", "token_type": "Bearer", "expires_in": 600 }
GET  /auth/me     Authorization: Bearer {token}
POST /auth/verify { "token": "..." }

### OAuth2 (client_credentials)
POST /auth/oauth  { "grant_type": "client_credentials", "client_id": "sandbox-client", "client_secret": "sandbox-secret" }

---

## Auth Testing — 17 schemes, one protected endpoint each

Practice configuring authentication in any API tool (Postman, RestAssured, Tricentis, APIDog, Bruno, Karate, SoapUI, Shift-Left) and verify it works. Each scheme has a diagnostic endpoint that returns 200 + the authenticated identity on success, or 401 + a specific reason (and the correct challenge header) on failure.

- Catalog (all schemes, demo credentials, per-tool notes): GET https://demo.totalshiftleft.ai/auth/methods
- Test one scheme: GET or POST https://demo.totalshiftleft.ai/auth/protected/{scheme}
- Human guide with per-tool setup: https://demo.totalshiftleft.ai/auth-testing

Schemes (id → how to send):
- none → no credentials
- apikey-header → x-api-key: demo-key-sandbox-2026
- apikey-query → ?api_key=demo-key-sandbox-2026
- bearer / jwt → Authorization: Bearer <token from POST /auth/token>
- apikey-bearer → both x-api-key AND Authorization: Bearer
- basic → Authorization: Basic base64(alice@demo.com:alice123)
- digest → HTTP Digest (alice@demo.com / alice123)
- oauth2 → Bearer access token from /auth/oauth/token (grants: client_credentials, password, authorization_code+PKCE, refresh_token)
- oauth1 → OAuth 1.0a HMAC-SHA1 (consumer sandbox-consumer / sandbox-consumer-secret)
- awssigv4 → AWS Signature v4 (AKIDEMO0000000000DEMO / demo-aws-secret-key-2026, us-east-1, execute-api)
- hawk → Hawk (id dh37fgj492je / key hawk-shared-secret-2026)
- hmac → HMAC-SHA256 over METHOD
PATH
TIMESTAMP
sha256hex(body); headers x-api-key-id, x-timestamp, x-signature (key demo-hmac-key / demo-hmac-secret-2026)
- custom-header → x-api-token: custom-token-sandbox-2026
- query-param → ?access_token=querytoken-sandbox-2026
- cookie-session → POST {username,password} sets sandbox_auth cookie, then GET with the cookie
- mtls → SIMULATED via X-SSL-Client-Verify: SUCCESS + X-SSL-Client-S-DN: CN=sandbox-client (proxy terminates TLS; not a real client-cert handshake)

OAuth2 flow endpoints:
- GET  /auth/oauth/authorize?response_type=code&client_id=sandbox-client&code_challenge=...&code_challenge_method=S256
- POST /auth/oauth/token  (grant_type=authorization_code|password|client_credentials|refresh_token; JSON or form-urlencoded)

---

## End-to-End Flows

POST /api/v1/flows/order-placement    — Create user + product + order in one call
POST /api/v1/flows/auth-and-data      — Issue JWT → create user → list users
POST /api/v1/flows/cross-protocol     — REST create → GraphQL read → REST delete
POST /api/v1/flows/seed-store         — Populate session with 4 realistic products
POST /api/v1/flows/customer-journey   — Full shopper story: register → browse → order → confirm
POST /api/v1/flows/process-order      — Order lifecycle: pending → processing → completed
GET  /api/v1/flows                    — List all available flows with descriptions

---

## Use Cases

1. API Testing Demos — live, interactive demos for sales and training presentations
2. Tool Evaluation — test Postman, SoapUI, no-code automation tools against real endpoints
3. Developer Training — hands-on REST, GraphQL, SOAP exercises with guided scenarios
4. Auth Pattern Learning — JWT, API Key, OAuth2 all in one sandbox
5. Resilience Testing — use ?delay and ?random_fail to test retry/timeout logic
6. Cross-Protocol Comparison — same data accessible via REST, GraphQL, and SOAP simultaneously

---

## Company

TotalShiftLeft
Website: https://totalshiftleft.ai
Demo: https://demo.totalshiftleft.ai
GitHub: https://github.com/Total-Shift-Left