@salesforce/b2c-dx-mcp 2.1.2 → 3.0.1

package/content/guidance/b2c-cli/b2c-job/references/RUN-AND-MONITOR.md

@@ -0,0 +1,119 @@
+# Run and Monitor Jobs
+
+### Run a Job
+
+```bash
+# run a job and return immediately
+b2c job run my-custom-job
+
+# run a job and wait for completion
+b2c job run my-custom-job --wait
+
+# run a job with a timeout (in seconds)
+b2c job run my-custom-job --wait --timeout 600
+
+# run a job with parameters (standard jobs)
+b2c job run my-custom-job -P "SiteScope={\"all_storefront_sites\":true}" -P OtherParam=value
+
+# show job log if the job fails
+b2c job run my-custom-job --wait --show-log
+```
+
+### Run System Jobs with Custom Request Bodies
+
+Some system jobs (like search indexing) use non-standard request schemas. Use `--body` to provide a raw JSON request body:
+
+```bash
+# run search index job for specific sites
+b2c job run sfcc-search-index-product-full-update --wait --body '{"site_scope":{"named_sites":["RefArch","SiteGenesis"]}}'
+
+# run search index job for a single site
+b2c job run sfcc-search-index-product-full-update --wait --body '{"site_scope":{"named_sites":["RefArch"]}}'
+```
+
+Note: `--body` and `-P` are mutually exclusive.
+
+### Standard (System) Job Steps
+
+B2C Commerce ships a catalog of **standard job steps** — built-in step **type IDs** (for example `ImportCatalog`, `ExportCatalog`, `ImportInventoryLists`) that are added to job flows in **Business Manager → Administration → Operations → Jobs**, or referenced by type ID in a `jobs.xml` flow inside a site-import archive. They are the building blocks of the multi-step jobs you run with `b2c job run`.
+
+Look up the catalog and any step's configuration parameters via the `b2c-cli:b2c-docs` skill — these docs are bundled with the CLI, so no instance connection is needed:
+
+```bash
+# Browse the standard step catalog
+b2c docs read job-steps
+
+# Look up a specific step's purpose + parameters
+b2c docs read ImportCatalog
+b2c docs search "export inventory"
+```
+
+**In-flow standard step vs. CLI command.** Some standard steps overlap with CLI commands — for instance, the standard catalog/site import steps vs. `b2c job import` (which itself runs the `sfcc-site-archive-import` system job). Use an **in-flow standard step** when the file is already staged on the instance or produced by an earlier step in the same flow (no round-trip, runs on a BM schedule). Use the **CLI** when moving data between your machine and the instance (uploading a local archive, downloading an export, or scripting from CI). For chaining custom + standard steps and IMPEX file hand-off, see the `b2c:b2c-custom-job-steps` skill.
+
+### View Job Logs
+
+```bash
+# get the log from the most recent execution of a job
+b2c job log my-custom-job
+
+# get the log from the most recent failed execution
+b2c job log my-custom-job --failed
+
+# get the log from a specific execution
+b2c job log my-custom-job abc123-def456
+```
+
+### Search Job Executions
+
+```bash
+# search for recent job executions
+b2c job search
+
+# filter by job ID
+b2c job search --job-id my-custom-job
+
+# filter by status
+b2c job search --status ERROR
+b2c job search --status RUNNING,PENDING
+
+# control result count and pagination
+b2c job search --count 50 --start 0
+
+# sort results
+b2c job search --sort-by start_time --sort-order desc
+
+# search with JSON output
+b2c job search --json
+```
+
+### Delete Job Executions
+
+```bash
+# delete a job execution record (requires SCAPI)
+b2c job execution delete my-job abc123-def456
+```
+
+### API Backend
+
+Job commands run over SCAPI. Configure `shortCode`, `tenantId`, and the SCAPI scopes and `job run`, `job search`, `job wait`, and `job log` work out of the box.
+
+**SCAPI scopes**: `sfcc.jobs.rw` (recommended) for full access, or `sfcc.jobs` for read-only (search, wait, log).
+
+OCAPI is deprecated and disabled on newer instances. `--api-backend auto` (the default) falls back to the OCAPI Data API on safe SCAPI capability/auth/request rejections; force a backend with `--api-backend scapi|ocapi`, dw.json `"api-backend": "scapi"`, or `SFCC_API_BACKEND=scapi`.
+
+SCAPI `DELETE` removes a completed execution record; it does not cancel a running job. The CLI does not expose job cancellation because the underlying job APIs do not provide that operation.
+
+> **Note:** `job import` and `job export` trigger the site-archive system jobs and transfer archive files over WebDAV. The job trigger honors `--api-backend`: in `auto` mode it runs over SCAPI (needs `sfcc.jobs.rw`) with OCAPI fallback if the SCAPI start is rejected. The archive transfer always uses WebDAV.
+
+### Wait for Job Completion
+
+```bash
+# wait for a specific job execution to complete (requires both job ID and execution ID)
+b2c job wait <job-id> <execution-id>
+
+# wait with a timeout
+b2c job wait <job-id> <execution-id> --timeout 600
+
+# wait with a custom polling interval
+b2c job wait <job-id> <execution-id> --poll-interval 5
+```

package/content/guidance/b2c-cli/b2c-logs/SKILL.md

@@ -0,0 +1,249 @@
+---
+name: b2c-logs
+description: Retrieve and search logs from B2C Commerce instances using the b2c CLI. Use this skill whenever the user needs to view server logs, search for errors, filter log entries by level or time, or monitor logs in real-time. Also use when the user reports a 500 error, broken checkout, failing job, or any server-side issue that needs log investigation — even if they just say "something's broken on the sandbox" or "check the logs".
+---
+
+# B2C Logs Skill
+
+Use the `b2c` CLI to retrieve and monitor log files on Salesforce B2C Commerce instances. The `logs get` command is designed for agent-friendly, non-interactive log retrieval with structured JSON output.
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli` instead (e.g., `npx @salesforce/b2c-cli logs get`).
+
+## Configuration & Authentication
+
+The CLI auto-discovers the target instance and credentials from `SFCC_*` environment variables (including project `.env`), the selected project-local or shared `dw.json`, and configuration plugins. `package.json` supplies only non-sensitive defaults. **Flags like `--server`, `--client-id`, `--client-secret`, `--username`, and `--password` are usually unnecessary** — only pass them to override what's auto-detected.
+
+Run `b2c setup inspect` to see the resolved configuration and which source provided each value (use `--json` for scripting; secrets stay masked by default). For precedence rules and troubleshooting, see the `b2c-cli:b2c-config` skill.
+
+## Agent-Friendly Log Retrieval
+
+The `logs get` command is optimized for coding agents:
+
+- Exits immediately after retrieving logs (non-interactive)
+- Supports `--json` for structured output
+- Filters by time, level, and text search
+- Auto-normalizes file paths for IDE click-to-open
+
+## Examples
+
+### Get Recent Logs
+
+```bash
+# Get last 20 entries from error and customerror logs (default)
+b2c logs get
+
+# Get last 50 entries
+b2c logs get --count 50
+
+# JSON output for programmatic parsing
+b2c logs get --json
+```
+
+### Filter by Time
+
+```bash
+# Entries from the last 5 minutes
+b2c logs get --since 5m
+
+# Entries from the last 1 hour
+b2c logs get --since 1h
+
+# Entries from the last 2 days
+b2c logs get --since 2d
+
+# Entries after a specific time (ISO 8601)
+b2c logs get --since "2026-01-25T10:00:00"
+```
+
+### Filter by Log Level
+
+```bash
+# Only ERROR level entries
+b2c logs get --level ERROR
+
+# ERROR and FATAL entries
+b2c logs get --level ERROR --level FATAL
+```
+
+### Search Text
+
+```bash
+# Search for "OrderMgr" in messages
+b2c logs get --search OrderMgr
+
+# Search for payment errors
+b2c logs get --search "PaymentProcessor"
+```
+
+### Combined Filters
+
+```bash
+# Recent errors containing "PaymentProcessor"
+b2c logs get --since 1h --level ERROR --search "PaymentProcessor" --json
+
+# Last hour of errors and fatals from specific log types
+b2c logs get --filter error --filter warn --since 1h --level ERROR --level FATAL
+```
+
+### List Available Log Files
+
+```bash
+# List all log files
+b2c logs list
+
+# List specific log types
+b2c logs list --filter error --filter customerror
+
+# List logs in a subdirectory (path-like filter)
+b2c logs list --filter internal/server
+
+# JSON output
+b2c logs list --json
+```
+
+### Real-Time Tailing (Human Use)
+
+For interactive log monitoring (not for agents):
+
+```bash
+# Tail error and customerror logs
+b2c logs tail
+
+# Tail specific log types
+b2c logs tail --filter debug --filter error
+
+# Tail only ERROR and FATAL level entries
+b2c logs tail --level ERROR --level FATAL
+
+# Tail with text search
+b2c logs tail --search "PaymentProcessor"
+
+# Combined filtering
+b2c logs tail --filter customerror --level ERROR --search "OrderMgr"
+
+# Stop with Ctrl+C
+```
+
+## Downloading Full Log Files
+
+To download the complete log file, use the `file` field from the JSON output with `b2c-cli:b2c-webdav`:
+
+```bash
+b2c webdav get error-odspod-0-appserver-20260126.log --root=logs -o -
+```
+
+## JSON Output Structure
+
+When using `--json`, `logs get` returns:
+
+```json
+{
+  "count": 1,
+  "entries": [
+    {
+      "file": "error-odspod-0-appserver-20260126.log",
+      "timestamp": "2026-01-26 04:38:03.022 GMT",
+      "level": "ERROR",
+      "message": "PipelineCallServlet|156679877|Sites-Site|...",
+      "raw": "[2026-01-26 04:38:03.022 GMT] ERROR PipelineCallServlet|..."
+    }
+  ]
+}
+```
+
+| Field       | Description                                                                |
+| ----------- | -------------------------------------------------------------------------- |
+| `file`      | Source log file name (use with `b2c-cli:b2c-webdav` to download full file) |
+| `level`     | Log level: ERROR, WARN, INFO, DEBUG, FATAL, TRACE                          |
+| `timestamp` | Entry timestamp                                                            |
+| `message`   | Log message (paths normalized for IDE click-to-open)                       |
+| `raw`       | Raw unprocessed log line                                                   |
+
+## Log Types
+
+Common log file prefixes:
+
+| Prefix        | Description                             |
+| ------------- | --------------------------------------- |
+| `error`       | System errors                           |
+| `customerror` | Custom script errors (`Logger.error()`) |
+| `warn`        | Warnings                                |
+| `debug`       | Debug output (when enabled)             |
+| `info`        | Informational messages                  |
+| `jobs`        | Job execution logs                      |
+| `api`         | API problems and violations             |
+| `deprecation` | Deprecated API usage                    |
+| `quota`       | Quota warnings                          |
+
+The prefixes above are the **built-in** log files. In addition, any script that logs through a _custom logger category_ writes to its own dedicated file with a `custom-` prefix — **distinct from `customerror`**. Integration and job code (payment gateways, ERP/OMS/CRM syncs, feed and import jobs) almost always logs this way, so the entry you need for a triage is frequently in a `custom-*` file, not in `error`/`customerror`.
+
+Custom log file names follow this pattern:
+
+```
+custom-<prefix>-<hostname>-appserver-<date>.log
+```
+
+The `<prefix>` segment is the **first argument** passed to `Logger.getLogger(prefix, category)` in the emitting code, so it maps a log file straight back to the code that wrote it:
+
+| Code                                              | Log file                        | Filter to read it                  |
+| ------------------------------------------------- | ------------------------------- | ---------------------------------- |
+| `Logger.getLogger('PaymentProcessor', 'payment')` | `custom-PaymentProcessor-*.log` | `--filter custom-PaymentProcessor` |
+| `Logger.getLogger('PimTaxImport', 'tax')`         | `custom-PimTaxImport-*.log`     | `--filter custom-PimTaxImport`     |
+| `Logger.getLogger('orderexport', 'export')`       | `custom-orderexport-*.log`      | `--filter custom-orderexport`      |
+
+(The second argument is the log _category_, used for configuration; it does not appear in the file name.) For the authoring side — how to create these loggers — see the `b2c:b2c-logging` skill.
+
+> **Note:** `--filter` does a **prefix (starts-with) match** on a file's log category, not an exact match — so `--filter custom-` sweeps every `custom-*` file, and `--filter custom-Payment` also matches `custom-PaymentProcessor`. The category is extracted by taking everything up to the _second_ dash, so a custom logger name is treated as word characters only (no dashes): a file named `custom-payment-gateway-*.log` is seen as category `custom-payment`. To read one specific custom log, filter on its full extracted prefix (e.g. `--filter custom-PimTaxImport`); to sweep them all, use `--filter custom-`.
+
+## Discovering Custom Log Files
+
+Because custom log files are not covered by the default `error`/`customerror` retrieval, discover them explicitly when investigating an integration or job:
+
+```bash
+# 1. Enumerate all log files, or narrow to just custom ones
+b2c logs list
+b2c logs list --filter custom
+
+# 2. Scan the output for an unfamiliar custom-* prefix whose size or
+#    last-modified time grew when the incident started, then read it
+b2c logs get --filter custom-PimTaxImport --since 1h
+
+# 3. Read all custom logs at once when you don't yet know the prefix
+b2c logs get --filter custom-
+```
+
+`b2c logs list` reports each file with its size and last-modified timestamp, which is the fastest way to spot the custom logger that lit up during an incident. Once you have the prefix, `--filter custom-<prefix>` (or a bare `--filter custom-` to sweep them all) reads the entries.
+
+If `logs list` output is incomplete or you want to confirm the raw `*.log` filenames on the instance, fall back to WebDAV:
+
+```bash
+# Enumerate log filenames directly over WebDAV
+b2c webdav ls --root logs
+```
+
+## Logs in Subdirectories
+
+The `Logs/` directory contains subdirectories such as `internal/` (e.g. `server`, `ccp`, `health`, `csrf-violations`, `internalquota`). These are **not** listed by default. To reach them, pass a path-like `--filter` (one containing a `/`): the tooling then recurses into that subdirectory and matches files by their path relative to `Logs/`.
+
+```bash
+# All "server" logs under internal/
+b2c logs list --filter internal/server
+
+# Everything under internal/ (trailing slash)
+b2c logs tail --filter internal/
+
+# Mix a subdirectory filter with normal prefix filters
+b2c logs get --filter error --filter internal/server
+```
+
+This works the same across `logs list`, `logs get`, and `logs tail` (and the equivalent MCP tools).
+
+## More Commands
+
+See `b2c logs --help` for all available commands and options.
+
+## Related Skills
+
+- `b2c-cli:b2c-webdav` - Direct WebDAV file access for downloading full log files
+- `b2c-cli:b2c-config` - Verify configuration and credentials
+- `b2c:b2c-logging` - Authoring side: how server-side code creates custom logger categories that produce `custom-*` log files

package/content/guidance/b2c-cli/b2c-metrics/SKILL.md

@@ -0,0 +1,315 @@
+---
+name: b2c-metrics
+description: Query observability metrics from SCAPI Metrics API (CLOSED BETA). Use this skill whenever the user needs request volume, latency distributions, error rates, cache performance, or technical health indicators for SCAPI, OCAPI, MRT, SFRA controllers, or overall system performance. Also use when they want to monitor third-party integrations, sales metrics, or eCDN performance -- even if they just say 'show me SCAPI metrics', 'what is my error rate', or 'check API performance'.
+---
+
+# B2C Metrics Skill
+
+::: danger CLOSED BETA
+The Metrics API is a closed beta feature. It must be enabled for your organization, and its behavior, output, and OAuth scopes may change without notice.
+:::
+
+Use the `b2c metrics` commands to query observability metrics from the SCAPI Metrics API (`observability/metrics/v1`). This provides time-series metrics data for monitoring and analyzing Commerce Cloud technical performance.
+
+> **Tip:** If `b2c` is not installed globally, use `npx @salesforce/b2c-cli`.
+
+## Command Structure
+
+```text
+metrics
+├── list                          - list available metric categories
+├── overall                       - system-wide aggregate metrics
+├── sales                         - sales transaction metrics
+├── ecdn                          - edge CDN performance
+├── third-party                   - third-party service integrations
+│   └── Flags:
+│       └── --third-party-service-id  - filter by service ID
+├── scapi                         - SCAPI request volume/latency/errors/cache
+│   └── Flags:
+│       ├── --api-family          - filter by API family
+│       └── --api-name            - filter by API name
+├── scapi-hooks                   - SCAPI hook execution metrics
+├── mrt                           - Managed Runtime (PWA Kit) metrics
+├── controller                    - SFRA controller performance
+└── ocapi                         - OCAPI request metrics
+    └── Flags:
+        ├── --ocapi-category      - filter by OCAPI category
+        └── --ocapi-api           - filter by OCAPI API
+
+Common Flags (all category commands):
+├── --from / --to / --window      - time window (relative "1h"/"7d" or ISO 8601)
+└── --tags / --no-tags            - enrich series with structured tags (default: true)
+```
+
+## Configuration
+
+Values like `tenantId`, `shortCode`, `clientId`, and `clientSecret` resolve from `dw.json` / `SFCC_*` env vars / the active instance / configuration plugins. Examples below show minimal usage; **add flags only to override configured values** — passing `--client-id`/`--client-secret`/`--tenant-id`/`--short-code` is usually unnecessary. If a required value is missing, the CLI emits an actionable error pointing at the flag, env var, and config key.
+
+Run `b2c setup inspect` to see the resolved configuration and which source provided each value (`--json` for scripting; secrets stay masked by default). For precedence rules and troubleshooting, see the `b2c-cli:b2c-config` skill.
+
+Relevant overrides:
+
+- `--tenant-id` (alias `--tenant`) / `SFCC_TENANT_ID` / `tenantId`
+- `--short-code` / `SFCC_SHORTCODE` / `shortCode`
+- `--client-id` / `SFCC_CLIENT_ID` / `clientId`
+- `--client-secret` / `SFCC_CLIENT_SECRET` / `clientSecret`
+
+## Requirements
+
+- OAuth client credentials (Metrics API uses client credentials only; `--user-auth` is not supported)
+- API client has `Salesforce Commerce API` role with tenant filter for your instance
+- OAuth scope `sfcc.metrics` (automatically requested by the CLI)
+
+::: danger CLOSED BETA
+The Metrics API is a closed beta feature. It must be enabled for your organization before use.
+:::
+
+## Quick Workflow
+
+1. List available categories (`b2c metrics list`)
+2. Fetch metrics using the category command (e.g., `b2c metrics overall`, `b2c metrics scapi`)
+3. Filter by time window (`--from`/`--to`/`--window` — relative like `1h`/`7d` or ISO 8601) or category-specific filters
+
+## Metric Categories and Commands
+
+| Command                   | Description                               | Category-Specific Filters         |
+| ------------------------- | ----------------------------------------- | --------------------------------- |
+| `b2c metrics overall`     | System-wide aggregate metrics             | None                              |
+| `b2c metrics sales`       | Sales transaction metrics                 | None                              |
+| `b2c metrics ecdn`        | Edge CDN performance                      | None                              |
+| `b2c metrics third-party` | Third-party service integrations          | `--third-party-service-id`        |
+| `b2c metrics scapi`       | SCAPI request volume/latency/errors/cache | `--api-family`, `--api-name`      |
+| `b2c metrics scapi-hooks` | SCAPI hook execution metrics              | None                              |
+| `b2c metrics mrt`         | Managed Runtime (PWA Kit) metrics         | None                              |
+| `b2c metrics controller`  | SFRA controller performance               | None                              |
+| `b2c metrics ocapi`       | OCAPI request metrics                     | `--ocapi-category`, `--ocapi-api` |
+
+::: warning Filter Validation
+Category-specific filters are only accepted by the command they apply to. For example, `--api-family` is only valid for `b2c metrics scapi`. Passing a filter to a different command results in a "Nonexistent flag" error.
+:::
+
+## Discovery Examples
+
+```bash
+# List all categories (uses configured tenant)
+b2c metrics list
+
+# List as JSON
+b2c metrics list --json
+
+# Target a different tenant than the active config
+b2c metrics list --tenant-id zzxy_prd
+```
+
+## Fetch Metrics Examples
+
+```bash
+# Get overall metrics (last 24 hours by default)
+b2c metrics overall
+
+# Get metrics for the last hour
+b2c metrics overall --window 1h
+
+# Get a 1-hour window from 7 days ago
+b2c metrics scapi --from 7d --window 1h
+
+# Get metrics for a specific ISO 8601 time range
+b2c metrics scapi --from "2026-01-25T10:00:00" --to "2026-01-25T11:00:00"
+
+# Get SCAPI metrics filtered by API family
+b2c metrics scapi --api-family products
+
+# Get SCAPI metrics for a specific API
+b2c metrics scapi --api-family products --api-name shopper-products
+
+# Get third-party metrics for a specific service
+b2c metrics third-party --third-party-service-id my-integration
+
+# Get OCAPI metrics filtered by category and API
+b2c metrics ocapi --ocapi-category shop --ocapi-api baskets
+
+# Get controller metrics for the last 6 hours
+b2c metrics controller --window 6h
+
+# Output as JSON
+b2c metrics overall --json
+```
+
+## Time Windows
+
+Metrics commands accept flexible time-window specifications via three flags:
+
+- `--from` — Start bound: relative duration (`1h`, `7d` = that long ago) or ISO 8601 timestamp
+- `--to` — End bound: relative duration or ISO 8601 timestamp
+- `--window` (alias `--for`) — Window duration (`1h`, `30m`, `2d`)
+
+The commands always send an explicit `from`+`to` range, defaulting to a **24-hour window**. The Metrics API pairs a request that omits `to` with its own "now" and enforces a **24-hour maximum window**, so an open-ended `--from` older than a day would always be rejected; filling the window client-side makes the behavior predictable.
+
+**Resolution rules:**
+
+- `--from` + `--to` → used as given (a range wider than 24h is sent as-is; the API returns its own error)
+- `--from` + `--window` → end = start + window (e.g., `--from 7d --window 1h` = a 1-hour window, 7 days ago)
+- `--to` + `--window` → start = end − window
+- `--window` alone → the last `<window>` (end = now, start = now − window)
+- `--from` alone → a 24-hour window forward from it: end = min(start + 24h, now)
+- `--to` alone → a 24-hour window back from it: start = end − 24h
+- Nothing → the last 24 hours (end = now, start = now − 24h)
+
+You can specify at most two of the three flags.
+
+**Examples:**
+
+```bash
+# Last hour
+b2c metrics overall --window 1h
+
+# Last 7 days
+b2c metrics sales --window 7d
+
+# 1-hour window starting 7 days ago
+b2c metrics scapi --from 7d --window 1h
+
+# Specific ISO 8601 range
+b2c metrics scapi --from "2026-01-25T10:00:00" --to "2026-01-25T11:00:00"
+
+# From 24 hours ago until now (--from alone → default 24h window, capped at now)
+b2c metrics overall --from 24h
+```
+
+**Data retention:** The Metrics API retains 30 days of data. If `--from` lands at or beyond the retention edge, the CLI adjusts it forward by a small safety margin (5 minutes) and emits a warning.
+
+**Wire units:** Request bounds are sent to the API as epoch **seconds**; response timestamps come back as epoch **milliseconds** (JS-native)
+
+## Series Tags
+
+By default, the CLI enriches each data series with a structured `tags` object to make filtering and grouping easier. The Metrics API returns series identifiers that pack multiple dimensions into a single string (e.g., `bdpx.product`, `bdpx.product HIT`, `2xx bdpx.host`). The `tags` object unpacks these into discrete key-value pairs.
+
+**Tag contents (three tiers):**
+
+1. **Realm and environment** — always present, derived from the requested tenant/org ID (`f_ecom_bdpx_prd` → `realm=bdpx`, `environment=prd`).
+2. **Per-series dimensions** — parsed from the packed series ID: `apiFamily`, `apiName`, `host`, `cacheStatus`, `statusClass`, `ocapiCategory`, `controller`, `exceptionType`, `aggregation`.
+3. **Applied filters** — any category-specific filter you passed (`--api-family`, etc.) is folded in authoritatively, overriding heuristic guesses.
+
+**Example:**
+
+- `scapi cacheHitRate` series `bdpx.product HIT` → `{"realm":"bdpx","environment":"prd","apiFamily":"product","cacheStatus":"HIT"}`
+
+**Disabling tags:**
+
+Pass `--no-tags` to disable enrichment and return the raw API shape (no `tags` key on series).
+
+**Important framing:**
+
+Tag parsing is a **client-side, best-effort bridge** over the API's current packed-string format. The `realm`/`environment` and applied-filter tiers are always reliable; the string-parsed dimensions are heuristic.
+
+## Response Format
+
+Metrics responses contain an array of metrics. Each metric includes:
+
+- **metricId**: Unique identifier (e.g., `requests_total`)
+- **title**: Human-readable title
+- **description**: What the metric measures
+- **unit**: Unit of measurement (e.g., `requests`, `ms`, `%`); may be empty
+- **dataSeries**: Array of data series, each containing:
+  - **id**: Series identifier
+  - **name**: Series name (e.g., `2xx`, `4xx`, `5xx` for HTTP status codes)
+  - **tags**: Structured dimension tags (enabled by default)
+  - **data**: Array of timestamped values:
+    - **timestamp**: Epoch milliseconds (the CLI normalizes from the API's epoch-seconds wire format)
+    - **value**: Numeric value
+
+With `--json`, the response is wrapped as `{query, data}` where `query` echoes the resolved time bounds and filters:
+
+```json
+{
+  "query": {
+    "category": "overall",
+    "from": "2026-01-25T10:00:00.000Z",
+    "to": "2026-01-25T11:00:00.000Z",
+    "fromEpochSeconds": 1737802800,
+    "toEpochSeconds": 1737806400
+  },
+  "data": [
+    {
+      "metricId": "requests_total",
+      "title": "Total Requests",
+      "description": "Total number of requests",
+      "unit": "requests",
+      "dataSeries": [
+        {
+          "id": "2xx",
+          "name": "2xx",
+          "tags": {
+            "realm": "bdpx",
+            "environment": "prd",
+            "statusClass": "2xx"
+          },
+          "data": [
+            {"timestamp": 1737802800000, "value": 1500},
+            {"timestamp": 1737803400000, "value": 1620}
+          ]
+        }
+      ]
+    }
+  ]
+}
+```
+
+The `query` object always includes both `from`/`to` (and `fromEpochSeconds`/`toEpochSeconds`). When a bound was derived from the 24-hour default window (e.g. `--from` alone, or no time flags), `query.defaultedWindow` is `true`; when `--from` was clamped forward off the retention edge, `query.clampedFrom` is `true`.
+
+## SDK Usage
+
+The Metrics API is also available via the SDK:
+
+```typescript
+import {createMetricsClient} from '@salesforce/b2c-tooling-sdk/clients';
+import {getScapiMetrics, getOverallMetrics, resolveMetricsWindow} from '@salesforce/b2c-tooling-sdk';
+
+// Create client
+const client = createMetricsClient(
+  {
+    shortCode: 'kv7kzm78',
+    tenantId: 'zzxy_prd',
+  },
+  {clientId: 'xxx', clientSecret: 'xxx'},
+);
+
+// Get overall metrics
+// `from`/`to` accept a Date or epoch milliseconds; the SDK converts to
+// the API's epoch-seconds wire format.
+const overallMetrics = await getOverallMetrics(client, 'zzxy_prd', {
+  from: new Date(Date.now() - 7 * 24 * 60 * 60 * 1000), // 7 days ago
+  to: new Date(),
+});
+
+// Get SCAPI metrics with filters
+const scapiMetrics = await getScapiMetrics(client, 'zzxy_prd', {
+  from: new Date(Date.now() - 24 * 60 * 60 * 1000), // 24 hours ago
+  apiFamily: 'product',
+  apiName: 'shopper-products',
+});
+
+// Use resolveMetricsWindow to handle from/to/window resolution
+const window = resolveMetricsWindow({from: '7d', window: '1h'});
+const historicalMetrics = await getScapiMetrics(client, 'zzxy_prd', {
+  from: window.from,
+  to: window.to,
+  apiFamily: 'product',
+});
+```
+
+Available operations: `getOverallMetrics`, `getSalesMetrics`, `getEcdnMetrics`, `getThirdPartyMetrics`, `getScapiMetrics`, `getScapiHooksMetrics`, `getMrtMetrics`, `getControllerMetrics`, `getOcapiMetrics`, `getMetricsByCategory`.
+
+Available helpers: `resolveMetricsWindow({from, to, window})`, `parseMetricsBound(value)`, `enrichMetricsTags(response, category, context)`, `parseSeriesTags({category, metricId, seriesId, context})`.
+
+All operations accept `(client, tenantId, options?)` and return `Promise<MetricsDataResponse>`. Time-window `from`/`to` accept a `Date` or epoch **milliseconds** (converted to the API's epoch-seconds wire format); response data-point timestamps come back in epoch **milliseconds**. The tenant ID may be bare (e.g., `zzxy_prd`) or prefixed (e.g., `f_ecom_zzxy_prd`) — the SDK normalizes it automatically.
+
+## Troubleshooting
+
+- **`tenant-id is required`**: set `--tenant-id` (or `SFCC_TENANT_ID`)
+- **Auth method error**: Metrics API supports client credentials only; remove `--user-auth`
+- **403/unauthorized**: verify API client role and tenant filter include target instance
+- **404/category not enabled**: the category may not be enabled for your organization (closed beta)
+- **503/temporarily unavailable**: metrics service may be temporarily unavailable
+
+For full command reference, use `b2c metrics --help` and see [CLI docs](/cli/metrics) and [Metrics Guide](/guide/metrics).