coding-os 0.3.2__py3-none-any.whl

core/skills/api-design/references/error-envelope.md

@@ -0,0 +1,381 @@
+# Error Envelope — RFC 9457 Problem Details
+
+The contract for every non-2xx response. Updated to RFC 9457 (March 2024, replaces RFC 7807). Used by the project's Go backend, FastAPI AI adapter, and surfaces straight into the React Native client's error handling.
+
+## The Envelope
+
+```http
+HTTP/1.1 422 Unprocessable Entity
+Content-Type: application/problem+json
+Content-Language: en
+
+{
+  "type": "https://api.app.com/problems/validation-failed",
+  "title": "Validation failed",
+  "status": 422,
+  "detail": "The 'email' field must be a valid email address.",
+  "instance": "/users",
+  "code": "validation_failed",
+  "errors": [
+    {
+      "field": "email",
+      "code": "invalid_email",
+      "message": "must contain '@' and a domain"
+    },
+    {
+      "field": "age",
+      "code": "out_of_range",
+      "message": "must be between 13 and 120"
+    }
+  ],
+  "request_id": "req_8h2k4n9d3p7q",
+  "documentation_url": "https://docs.app.com/errors/validation-failed"
+}
+```
+
+## Field Definitions
+
+| Field | Required | Stable across calls? | Description |
+|---|---|---|---|
+| `type` | yes | yes (per error class) | URI identifying the problem type. Treat as primary key. |
+| `title` | yes | yes (per type) | Short human description. Frozen for a given `type`. |
+| `status` | yes | yes (per type) | The HTTP status, repeated in body for client convenience. |
+| `detail` | no | no (varies per occurrence) | Specific human explanation. Safe to render to users. |
+| `instance` | no | no | URI of the specific occurrence (typically the request path). |
+| `code` | yes (project convention) | yes (per type) | Short machine token. Snake_case. Stable across versions. |
+| `errors[]` | conditional | structure stable | Field-level validation breakdown. Required for 422 validation failures. |
+| `request_id` | yes (project convention) | no | Correlation id; matches `X-Request-Id` header. |
+| `documentation_url` | no | yes | Optional link to docs page for this error class. |
+
+### `type` URI Convention
+
+```
+https://api.app.com/problems/<problem-slug>
+```
+
+The URI does NOT need to dereference (RFC 9457 explicitly allows non-resolving URIs). But if you do publish docs there, use `documentation_url` to point to them so clients can deep-link without ambiguity.
+
+### `code` vs `type` — Why Both?
+
+- `type` is the wire format for machines that route on URLs / categorize problems.
+- `code` is the project's snake_case shorthand. Easier to switch on in client code:
+
+```typescript
+switch (error.code) {
+  case 'insufficient_funds': return showTopUpFlow();
+  case 'rate_limited':       return scheduleRetry(error.retry_after);
+  case 'validation_failed':  return highlightFields(error.errors);
+}
+```
+
+Pick `code` first for client logic; `type` is the formal identifier.
+
+## Error Catalogue
+
+Maintain a **single source of truth** of error codes per service. New errors require a PR review like any other contract change.
+
+```yaml
+# docs/errors/catalogue.yaml — checked into the repo
+errors:
+  - code: validation_failed
+    type: https://api.app.com/problems/validation-failed
+    title: Validation failed
+    status: 422
+    notes: Use when request is well-formed but business rules reject it.
+
+  - code: insufficient_funds
+    type: https://api.app.com/problems/insufficient-funds
+    title: Insufficient funds
+    status: 402
+    notes: Account balance below required amount.
+
+  - code: rate_limited
+    type: https://api.app.com/problems/rate-limited
+    title: Too many requests
+    status: 429
+    extra_fields:
+      - retry_after_seconds
+    notes: Always include retry_after_seconds and Retry-After header.
+
+  - code: unauthenticated
+    type: https://api.app.com/problems/unauthenticated
+    title: Authentication required
+    status: 401
+
+  - code: forbidden
+    type: https://api.app.com/problems/forbidden
+    title: Access denied
+    status: 403
+
+  - code: not_found
+    type: https://api.app.com/problems/not-found
+    title: Resource not found
+    status: 404
+
+  - code: conflict
+    type: https://api.app.com/problems/conflict
+    title: Conflict with current state
+    status: 409
+    notes: Lost updates, duplicate creates, state-machine violations.
+
+  - code: idempotency_key_collision
+    type: https://api.app.com/problems/idempotency-key-collision
+    title: Idempotency key reused with different request
+    status: 409
+    notes: Same key, different body → reject not replay.
+
+  - code: dependency_unavailable
+    type: https://api.app.com/problems/dependency-unavailable
+    title: Upstream service unavailable
+    status: 503
+    extra_fields:
+      - retry_after_seconds
+      - dependency_name
+
+  - code: internal_error
+    type: https://api.app.com/problems/internal-error
+    title: Unexpected server error
+    status: 500
+    notes: Last-resort. detail must NOT leak stack/SQL/path info.
+```
+
+CI rule: any 4xx/5xx response in production logs whose `code` is not in the catalogue → fail the build / page on-call. Forces the catalogue to stay in sync with reality.
+
+## Domain Error → HTTP Status Mapping
+
+The hexagonal application layer raises domain errors; the inbound HTTP adapter maps them. Centralize the mapping in one helper.
+
+```go
+// pkg/apperr/from_domain.go
+package apperr
+
+import (
+    "errors"
+
+    "github.com/gofiber/fiber/v3"
+    "myapp/internal/domain/order"
+    "myapp/internal/domain/user"
+)
+
+func FromDomainError(c fiber.Ctx, err error) error {
+    var (
+        notFoundErr   *user.NotFoundError
+        inactiveErr   *user.InactiveError
+        invalidStateErr *order.InvalidStateError
+        balanceErr    *order.InsufficientBalanceError
+    )
+
+    switch {
+    case errors.As(err, &notFoundErr):
+        return Problem(c, 404, "not_found", err.Error())
+    case errors.As(err, &inactiveErr):
+        return Problem(c, 403, "forbidden", "account is inactive")
+    case errors.As(err, &invalidStateErr):
+        return Problem(c, 409, "conflict", err.Error())
+    case errors.As(err, &balanceErr):
+        return Problem(c, 402, "insufficient_funds", err.Error())
+    default:
+        // Unknown domain error → log full, return generic to client.
+        c.Locals("internal_error", err)
+        return Problem(c, 500, "internal_error", "unexpected error")
+    }
+}
+```
+
+```python
+# src/ai_adapter/delivery/http/error_handlers.py
+from fastapi import FastAPI, Request
+from fastapi.responses import JSONResponse
+
+from ai_adapter.application.usecase.send_message import (
+    ConversationNotFound,
+    MessageTooLong,
+)
+
+
+def install(app: FastAPI) -> None:
+    @app.exception_handler(ConversationNotFound)
+    async def conv_not_found(request: Request, exc: ConversationNotFound):
+        return _problem(request, 404, "conversation_not_found", str(exc))
+
+    @app.exception_handler(MessageTooLong)
+    async def msg_too_long(request: Request, exc: MessageTooLong):
+        return _problem(request, 422, "validation_failed", str(exc),
+                        errors=[{"field": "user_text", "code": "too_long",
+                                 "message": str(exc)}])
+
+
+def _problem(request: Request, status: int, code: str, detail: str, **extra) -> JSONResponse:
+    body = {
+        "type": f"https://api.app.com/problems/{code.replace('_', '-')}",
+        "title": _TITLE_BY_CODE[code],
+        "status": status,
+        "detail": detail,
+        "instance": str(request.url.path),
+        "code": code,
+        "request_id": request.headers.get("X-Request-Id", ""),
+        **extra,
+    }
+    return JSONResponse(
+        body,
+        status_code=status,
+        headers={"Content-Type": "application/problem+json"},
+    )
+```
+
+## Validation Errors — `errors[]` Shape
+
+For 422 (and sometimes 400) where multiple field problems exist:
+
+```json
+{
+  "type": "https://api.app.com/problems/validation-failed",
+  "title": "Validation failed",
+  "status": 422,
+  "code": "validation_failed",
+  "detail": "2 fields failed validation",
+  "errors": [
+    {
+      "field": "items[0].quantity",
+      "code": "min_value",
+      "message": "must be at least 1",
+      "constraint": { "min": 1 }
+    },
+    {
+      "field": "promo_code",
+      "code": "expired",
+      "message": "promo code WELCOME10 expired on 2026-04-01"
+    }
+  ]
+}
+```
+
+Per-error fields:
+
+- `field` — JSON pointer or dotted path. Arrays use `[N]`.
+- `code` — short token, e.g. `required`, `min_value`, `max_length`, `invalid_format`, `not_in_enum`.
+- `message` — human-readable, safe to render.
+- `constraint` (optional) — machine-readable bounds for client highlighting.
+
+Always include the FULL list, not just the first failure. UX wants to highlight all bad fields at once.
+
+## Status Code Decision Tree (for raisers)
+
+```
+Did the request fail before hitting business logic?
+├─ Yes → 4xx
+│   ├─ Auth missing → 401
+│   ├─ Auth present but no permission → 403
+│   ├─ Resource doesn't exist (or hide existence) → 404
+│   ├─ HTTP method wrong for URL → 405
+│   ├─ Body unparseable / type wrong → 400
+│   └─ Body parsed but semantically invalid → 422
+│
+└─ No, it failed during business logic
+    ├─ State conflict (lost update, duplicate) → 409
+    ├─ Insufficient resource (balance, quota) → 402 (payment) | 403 (perm) | 422 (rule)
+    ├─ Concurrent modification (ETag mismatch) → 412
+    ├─ Rate limit hit → 429 (with Retry-After)
+    ├─ Upstream service down → 502/503/504
+    └─ Truly unexpected → 500
+```
+
+## What NEVER Goes in `detail`
+
+- Stack traces.
+- File paths (`/var/app/src/handlers/foo.py:142`).
+- SQL fragments.
+- Internal table or column names.
+- Class names of internal exceptions.
+- Information that would help an attacker (which user exists, which permission is missing).
+
+The right way: log the full error server-side with `request_id` + payload, then return generic `detail` to the client. Support reads logs by `request_id`.
+
+```python
+# CORRECT
+logger.error("DB integrity error on user create", extra={
+    "request_id": req_id, "email_hash": h(email), "error": str(exc),
+})
+raise ConflictError("an account with this email already exists")
+
+# WRONG
+return JSONResponse({"detail": str(exc)}, status_code=409)
+# detail = 'duplicate key value violates unique constraint "users_email_key"'
+```
+
+## RN Client Side — Consuming the Envelope
+
+```typescript
+// src/infrastructure/http/apiClient.ts
+import axios, { AxiosError } from 'axios';
+
+export interface ApiProblem {
+  type: string;
+  title: string;
+  status: number;
+  detail?: string;
+  code: string;
+  errors?: Array<{ field: string; code: string; message: string }>;
+  request_id?: string;
+  retry_after_seconds?: number;
+}
+
+export class ApiError extends Error {
+  constructor(public problem: ApiProblem) {
+    super(problem.title);
+    this.name = 'ApiError';
+  }
+}
+
+export const api = axios.create({ baseURL: 'https://api.app.com' });
+
+api.interceptors.response.use(
+  (res) => res,
+  (err: AxiosError<ApiProblem>) => {
+    if (err.response?.data?.code) {
+      return Promise.reject(new ApiError(err.response.data));
+    }
+    // Network error, timeout, non-conforming server, etc.
+    return Promise.reject(new ApiError({
+      type: 'https://api.app.com/problems/network',
+      title: 'Network error',
+      status: 0,
+      code: 'network_error',
+      detail: err.message,
+    }));
+  },
+);
+```
+
+Then in screens / use cases, switch on `error.problem.code`:
+
+```typescript
+try {
+  await placeOrder.execute(input);
+} catch (e) {
+  if (e instanceof ApiError) {
+    switch (e.problem.code) {
+      case 'insufficient_funds': return navigation.navigate('TopUp');
+      case 'rate_limited':       return showToast('Too fast, retrying…');
+      case 'validation_failed':  return highlightFields(e.problem.errors);
+      default:                   return showToast(e.problem.title);
+    }
+  }
+  throw e;
+}
+```
+
+## CI Enforcement
+
+Three checks worth running:
+
+1. **Catalogue completeness**: scan source for `code: "..."` literals; assert every one is in the YAML catalogue.
+2. **Envelope shape**: every error response in integration tests is asserted against the JSON Schema for ProblemDetails.
+3. **No leaked detail**: regex any error response body for SQL keywords (`SELECT`, `INSERT`, `constraint`), file paths (`/var/`, `/app/`), Python tracebacks (`Traceback`, `File "/`).
+
+## References
+
+- [RFC 9457 — Problem Details for HTTP APIs](https://www.rfc-editor.org/rfc/rfc9457.html) (2024).
+- [RFC 9745 — The Deprecation HTTP Header Field](https://www.rfc-editor.org/rfc/rfc9745.html) (2024).
+- [JSON:API errors spec](https://jsonapi.org/format/#errors) — alternative envelope shape; useful comparison.
+- Stripe Errors guide — <https://stripe.com/docs/api/errors>.

core/skills/api-design/references/idempotency-pagination.md

@@ -0,0 +1,312 @@
+# Idempotency + Pagination — Implementation Patterns
+
+The two patterns most APIs get wrong. Both are simple in theory; both fail in subtle ways at scale.
+
+## Idempotency
+
+### Why It's Mandatory
+
+Networks drop responses. Mobile clients on bad LTE retry. Load balancers fail over mid-request. Without an idempotency contract, a single user tap can become two charges.
+
+The fix is a small protocol the client and server both follow:
+
+1. Client generates a random key per logical operation.
+2. Client sends the key on every retry of that operation.
+3. Server stores `(key, response)` after the first successful execution.
+4. On any retry with the same key, server returns the stored response without re-executing the side effect.
+
+### The Contract
+
+```http
+POST /payments
+Idempotency-Key: 8e0f7b1d-2a44-4c7f-9b2e-1c5d6e7f8a9b
+Content-Type: application/json
+
+{ "amount": 4200, "currency": "USD", "source": "card_xyz" }
+```
+
+Server responses:
+
+| Scenario | Status | Header |
+|---|---|---|
+| First call, success | 201 | normal |
+| First call, error | 4xx/5xx | normal |
+| Retry, original was success | 201 | `X-Idempotent-Replay: true` |
+| Retry, original was 5xx | re-execute | (stored 5xx is NOT a final result) |
+| Retry, different body, same key | 409 | `code: idempotency_key_collision` |
+
+**Key rules**:
+
+- Only store FINAL outcomes (2xx, 4xx). 5xx and timeouts → safe to re-execute on retry.
+- Compare body hash on retry — if body differs, refuse with 409 (don't silently return old response for new request).
+- TTL the stored entry. 24 hours is industry default. Long enough for legitimate retries, short enough to bound storage.
+- Return the SAME response on replay — same status, same headers (esp `Location`), same body.
+
+### Storage Schema (PostgreSQL)
+
+```sql
+CREATE TABLE idempotency_keys (
+    key                 TEXT        PRIMARY KEY,
+    user_id             TEXT        NOT NULL,            -- scope to caller
+    request_method      TEXT        NOT NULL,
+    request_path        TEXT        NOT NULL,
+    request_body_hash   TEXT        NOT NULL,            -- SHA-256 of canonicalized body
+    response_status     INT         NOT NULL,
+    response_headers    JSONB       NOT NULL,
+    response_body       BYTEA       NOT NULL,
+    created_at          TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    completed_at        TIMESTAMPTZ,                     -- NULL while in-flight
+    locked_until        TIMESTAMPTZ                      -- in-flight lock
+);
+
+CREATE INDEX idx_idempotency_keys_user_path
+    ON idempotency_keys (user_id, request_path);
+CREATE INDEX idx_idempotency_keys_created
+    ON idempotency_keys (created_at);
+
+-- Sweep job (cron, every hour) — drop entries older than 24h.
+DELETE FROM idempotency_keys WHERE created_at < NOW() - INTERVAL '24 hours';
+```
+
+### In-Flight Collision
+
+If two requests with the same key arrive simultaneously (genuinely; client retries the request before the first response):
+
+1. First request acquires the row lock (`INSERT … ON CONFLICT DO NOTHING`).
+2. Second request sees the row exists with `completed_at IS NULL`.
+3. Second request waits up to N seconds for `completed_at` to be set.
+4. If filled in time → return that response.
+5. If timeout → return 409 `idempotency_key_in_flight` (client retries shortly).
+
+```go
+// Pseudocode for the lock dance:
+func (s *Store) Begin(ctx context.Context, key, userID, method, path, bodyHash string) (existing *Stored, acquired bool, err error) {
+    // Try to insert a placeholder.
+    res, err := s.db.Exec(ctx, `
+        INSERT INTO idempotency_keys (key, user_id, request_method, request_path,
+                                      request_body_hash, response_status, response_headers,
+                                      response_body, locked_until)
+        VALUES ($1, $2, $3, $4, $5, 0, '{}', '\x00', NOW() + INTERVAL '30 seconds')
+        ON CONFLICT (key) DO NOTHING
+    `, key, userID, method, path, bodyHash)
+    if err != nil { return nil, false, err }
+    if res.RowsAffected() == 1 {
+        return nil, true, nil  // We acquired the lock; caller proceeds to execute.
+    }
+
+    // Someone else owns the key. Read what they have.
+    row := s.db.QueryRow(ctx, `
+        SELECT request_body_hash, completed_at, response_status,
+               response_headers, response_body
+        FROM idempotency_keys WHERE key = $1
+    `, key)
+    var stored Stored
+    var hash string
+    var completedAt sql.NullTime
+    if err := row.Scan(&hash, &completedAt, &stored.Status,
+                       &stored.Headers, &stored.Body); err != nil {
+        return nil, false, err
+    }
+    if hash != bodyHash {
+        return nil, false, ErrKeyCollision
+    }
+    if !completedAt.Valid {
+        return nil, false, ErrInFlight
+    }
+    return &stored, false, nil
+}
+```
+
+### Scoping Keys
+
+Idempotency keys are scoped to `(user_id, method, path)` — NOT global. Prevents:
+
+- A malicious caller from "claiming" a key another user is about to send.
+- The same key being legitimately reused for `POST /orders` and `POST /payments` by different consumers.
+
+## Pagination — Cursor Pattern (Default)
+
+### The Contract
+
+Request:
+
+```http
+GET /orders?limit=20&cursor=eyJpZCI6Im9yZF9hYmMiLCJjcmVhdGVkX2F0IjoiMjAyNi0wNC0yNlQxNDozMDowMFoifQ
+```
+
+Response:
+
+```json
+{
+  "data": [
+    { "id": "ord_b1", "created_at": "2026-04-26T14:25:00Z", ... },
+    { "id": "ord_b2", "created_at": "2026-04-26T14:24:00Z", ... },
+    ...
+  ],
+  "page": {
+    "next_cursor": "eyJpZCI6Im9yZF9iMjAiLCJjcmVhdGVkX2F0IjoiMjAyNi0wNC0yNlQxNDoxMDowMFoifQ",
+    "has_more": true
+  }
+}
+```
+
+Rules:
+
+- `limit`: integer, default 20, max 100. Reject larger values.
+- `cursor`: opaque base64 of internal state. Do NOT promise a parseable shape; it's a black box for clients.
+- `next_cursor: null` when no more results.
+- `has_more: false` is authoritative; clients should stop iterating.
+
+### Cursor Encoding
+
+The cursor encodes the SORT KEY of the last row returned. For "newest first":
+
+```python
+import base64
+import json
+from datetime import datetime
+
+def encode_cursor(last_id: str, last_created_at: datetime) -> str:
+    payload = json.dumps({
+        "id": last_id,
+        "created_at": last_created_at.isoformat() + "Z",
+    }, separators=(",", ":"))
+    return base64.urlsafe_b64encode(payload.encode()).decode()
+
+def decode_cursor(cursor: str | None) -> dict | None:
+    if not cursor:
+        return None
+    try:
+        data = json.loads(base64.urlsafe_b64decode(cursor.encode()))
+    except (ValueError, json.JSONDecodeError):
+        raise ValueError("invalid cursor")
+    if "id" not in data or "created_at" not in data:
+        raise ValueError("invalid cursor")
+    return data
+```
+
+### The SQL — Tuple Comparison Pattern
+
+For "ORDER BY created_at DESC, id DESC" (stable sort even when timestamps tie):
+
+```sql
+SELECT id, created_at, total, status
+FROM orders
+WHERE user_id = $1
+  AND ($2::TIMESTAMPTZ IS NULL OR (created_at, id) < ($2::TIMESTAMPTZ, $3::TEXT))
+ORDER BY created_at DESC, id DESC
+LIMIT $4 + 1;       -- fetch one extra to detect has_more
+```
+
+Wrapper code:
+
+```python
+async def list_orders(
+    user_id: str,
+    limit: int = 20,
+    cursor: str | None = None,
+) -> tuple[list[Order], str | None]:
+    cursor_data = decode_cursor(cursor)
+    after_created = cursor_data["created_at"] if cursor_data else None
+    after_id = cursor_data["id"] if cursor_data else None
+
+    rows = await db.fetch(
+        """
+        SELECT id, created_at, total, status
+        FROM orders
+        WHERE user_id = $1
+          AND ($2::TIMESTAMPTZ IS NULL OR (created_at, id) < ($2, $3))
+        ORDER BY created_at DESC, id DESC
+        LIMIT $4
+        """,
+        user_id, after_created, after_id, limit + 1,
+    )
+
+    has_more = len(rows) > limit
+    page = rows[:limit]
+    next_cursor = (
+        encode_cursor(page[-1]["id"], page[-1]["created_at"])
+        if has_more and page else None
+    )
+    return [Order.from_row(r) for r in page], next_cursor
+```
+
+### Why Cursor Beats Offset
+
+Offset (`?page=3&size=20`) suffers from:
+
+1. **Race conditions**: items inserted between page 2 and 3 → duplicates or skips.
+2. **Performance**: `OFFSET 50000` makes the DB skip 50000 rows every request.
+3. **Page-jump unreliability**: page numbers shift as data changes.
+
+Cursor is stable: each cursor encodes a precise position. Even if 1000 new rows arrive, your cursor still picks up exactly where you stopped.
+
+### When Offset Is OK
+
+Small (<10k row), fixed datasets where users genuinely want "go to page 7". Admin dashboards, audit log views with date filters that bound the set. Document the limit clearly.
+
+```http
+GET /admin/audit-events?page=7&size=50
+```
+
+### Backward Pagination
+
+If you need both directions (rare in mobile lists, common in chat):
+
+```json
+{
+  "data": [...],
+  "page": {
+    "next_cursor": "eyJ...",
+    "prev_cursor": "eyJ...",
+    "has_more": true
+  }
+}
+```
+
+Implement with the same tuple-comparison trick but reversed sort, then re-reverse the result list before returning.
+
+### Counts? No.
+
+Resist the urge to return `total: 12345` on paginated endpoints. `SELECT COUNT(*)` against a large table is expensive and gets stale immediately. If you genuinely need a count, expose it as a separate endpoint with explicit caching (`/orders/count`, cached 60s).
+
+If users want a sense of "how much is left", show "Loading more…" or "1–20 of many" instead of a precise count.
+
+### Pagination Anti-Patterns
+
+1. **No max limit** — `?limit=10000` ships 10k rows, OOMs the server.
+2. **Cursor that's actually an offset** — defeats the purpose; race conditions return.
+3. **Returning the last page as `cursor: null` and an empty `data`** — if there's nothing more, just say so on the prior page.
+4. **Cursor that includes user-modifiable fields** — clients tamper, break sort, get duplicate or missing rows.
+5. **Different pagination per endpoint** — pick cursor and use everywhere.
+6. **GraphQL `first/after` confusion** — if using Relay-style, follow the spec exactly.
+
+## Combined: Both at Once
+
+A single mutating list operation (rare, but exists — bulk import) needs both:
+
+```http
+POST /imports/orders
+Idempotency-Key: 8e0f7b1d-2a44-4c7f-9b2e-1c5d6e7f8a9b
+Content-Type: application/json
+
+{
+  "items": [...500 orders...],
+  "cursor_after_failure": null
+}
+```
+
+Server:
+
+1. Idempotency check at the top.
+2. Process items in chunks; if a chunk fails, return `cursor_after_failure: <token>` so client can resume from that point.
+3. On idempotent retry, return the original outcome including any `cursor_after_failure`.
+
+Most APIs don't need this complexity. But when you do, do it right.
+
+## References
+
+- Stripe API — Idempotent requests: <https://stripe.com/docs/api/idempotent_requests>
+- Stripe API — Pagination: <https://stripe.com/docs/api/pagination>
+- IETF draft — The Idempotency-Key HTTP Header Field: <https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/>
+- Slack Engineering — "Evolving API Pagination at Slack" (still current): <https://slack.engineering/evolving-api-pagination-at-slack/>