snapshot-to-api（snapshot TO API 搜索）

Snapshot to API

Replace browser snapshots with direct API calls. 15-20x fewer tokens, 2x faster, 100% complete data.

Why

Browser snapshots return the full DOM tree — menus, buttons, refs, styling — when you only need the data. A typical table page: 45 KB DOM → ~15k tokens, ~15% useful. The same data via API: 3.5 KB JSON → ~1k tokens, ~90% useful.

Core Workflow

Step 1: Open the target page

browser(action=open, url="<target_url>", profile=openclaw)

Purpose: establish cookie/session auth. You don't need to read the page.

Step 2: Discover API endpoints

// Evaluate in the browser tab
() => {
  const entries = performance.getEntriesByType('resource')
    .filter(e => e.name.includes(window.location.hostname) &&
                 !e.name.match(/\.(js|css|png|jpg|webp|svg|woff|ttf)(\?|$)/))
    .map(e => e.name);
  return JSON.stringify(entries, null, 2);
}

This returns all API calls the page made during loading — the data sources behind the UI.

Step 3: Identify the data API

Look for URLs containing:

• /api/, /v2/, /v3/
• Keywords matching your data need (schema, table, list, detail, query, search)
• GET endpoints with query params like id=, name=, type=

Ignore: analytics, tracking, user-info, config, SDK URLs.

Step 4: Test the API via evaluate

// Replace <API_PATH> with the path from Step 3
() => {
  return fetch('<API_PATH>')
    .then(r => r.json())
    .then(data => {
      // Inspect the structure
      const keys = Object.keys(data?.data || data || {});
      return JSON.stringify({
        topLevelKeys: keys,
        sample: JSON.stringify(data).substring(0, 1000)
      });
    });
}

Step 5: Extract structured data

Once you understand the response shape, write a focused extractor:

() => {
  return fetch('<API_PATH>')
    .then(r => r.json())
    .then(data => {
      // Extract only what you need — return clean JSON
      return JSON.stringify({ /* structured result */ });
    });
}

Step 6: Close the browser tab

browser(action=close, targetId="<targetId>")

Param Tuning

Many APIs need specific parameters to return full data. Common pattern:

1. Start with the full URL the page used (from Step 2)
2. Try removing parameters one at a time
3. ⚠️ Some params return empty data instead of errors when missing — always verify field counts

Cross-Environment Variations

Different environments (regions, clusters, staging/prod) may have:

• Different base domains (e.g., app.example.com vs app-eu.example.com)
• Different API path prefixes (e.g., /api/v2/ vs /api_eu/v2/)
• Different ID suffixes in query params (e.g., @0 vs @10)

Always test each environment separately.

When NOT to Use

• Write operations (forms, submissions) — keep using browser automation for safety
• Pages requiring user interaction to load data (click-to-expand, infinite scroll APIs)
• Auth flows that need OAuth redirects — cookie-based auth only
• Frequently changing APIs — snapshot may be more maintainable as fallback

Comparison Reference

See references/comparison.md for detailed benchmark data (token counts, timing, completeness).

After Discovery

1. Update the original Skill — replace snapshot steps with evaluate + fetch
2. Keep snapshot as fallback — in case the API changes or auth expires
3. Document the API — path, required params, response structure, environment differences
4. Log to learnings — record the discovery for future reference