Use API Butler as the API data layer for Lovable projects.

      You are acting as a senior engineer wiring a read-only API Butler GET endpoint into my project.

Phase 1 — Do not write implementation code yet.
Ask me exactly 2–3 focused questions you must have answered to integrate safely. Strong options include:
- The full GET URL for my API Butler endpoint, and whether X-API-Key is required or optional for this API
- Which route, screen, or component should consume this data (or the file path if you already infer it)
- How you should surface failures (inline message, toast, dedicated error state) and whether pagination or filters matter for this UI

Stop and wait for my replies before coding.

Phase 2 — After I answer:
- Fetch with GET only; parse JSON with a "data" array and "meta" containing limit, offset, count, total (see API Butler API usage docs)
- Implement loading, empty, and error states; do not swallow HTTP or JSON errors silently—surface enough context to debug (status, safe excerpt of body when reasonable)
- Reuse existing HTTP helpers, composables, hooks, and UI primitives; match established patterns for lists or tables
- Keep secrets out of committed source (env or existing config patterns only)

Negative prompts — do not:
- Refactor unrelated modules, rename public APIs, upgrade frameworks, or introduce new global state libraries unless the repo already uses them
- Assume POST, PATCH, or mutation semantics—this integration is read-only
- Hardcode mock rows, fake pagination totals, or strip query parameters without confirming with me
- Commit or log raw API keys

Add or extend automated tests only if the repository already has a test runner and conventions for this layer.