The missing manual for storage APIs.

Talk to any array in ten minutes

Every modern enterprise array ships a REST API: an HTTPS endpoint that answers JSON. The GUI you click is usually just a customer of that same API. To automate anything — monitoring, provisioning, reporting — you need exactly three facts per platform: where it listens (base URL and port), how it authenticates, and how it pages large results. Everything else is reading the reference.

The four auth patterns — learn 4, unlock 20+

Twenty vendors did not invent twenty schemes. Every storage API in this guide authenticates in one of four ways:

The connect matrix — 21 platforms

Each row: the port, the exact login call, the header that carries your identity afterwards, and where the platform's full endpoint reference lives. The nine platforms with a ▸ have full deep-dive tabs in the next section — auth recipes, pagination code, and field gotchas.

Nine platforms, in production depth

For the nine platforms below, the connect matrix expands into working recipes: full auth flows, pagination loops in curl and Python, error semantics, and the field gotchas that cost real change windows. This matrix is the skeleton of the guide — each vendor tab below expands every row into working commands.

Copy# 1. Exchange the API token for a session token
curl -sk -X POST "https://ARRAY/api/2.4/login" \
     -H "api-token: YOUR-API-TOKEN" -D -
# → response HEADER contains:  x-auth-token: <session-token>

# 2. Use the session token on every subsequent call
curl -sk "https://ARRAY/api/2.4/volumes?limit=100" \
     -H "x-auth-token: SESSION-TOKEN"

Copy# Cookie-based session; keep the cookie jar
curl -sk -c cookies.txt -X POST "https://ARRAY/api/1.17/auth/session" \
     -H "Content-Type: application/json" \
     -d '{"api_token": "YOUR-API-TOKEN"}'

curl -sk -b cookies.txt "https://ARRAY/api/1.17/volume"

Copy# Page with limit + continuation_token until more_items_remaining is false
GET /api/2.4/volumes?limit=500
# response: { "items": [...], "more_items_remaining": true,
#             "continuation_token": "abc..." }
GET /api/2.4/volumes?limit=500&continuation_token=abc...

Copyimport requests

s = requests.Session(); s.verify = False
r = s.post(f"https://{ARRAY}/api/2.4/login",
           headers={"api-token": TOKEN})
s.headers["x-auth-token"] = r.headers["x-auth-token"]

items, tok = [], None
while True:
    p = {"limit": 500, **({"continuation_token": tok} if tok else {})}
    j = s.get(f"https://{ARRAY}/api/2.4/volumes", params=p).json()
    items += j["items"]
    if not j.get("more_items_remaining"): break
    tok = j["continuation_token"]

Copycurl -sku admin:PASSWORD \
  "https://CLUSTER/api/storage/volumes?fields=name,size,svm.name&max_records=100"
# response envelope: { "records": [...], "num_records": N,
#                      "_links": { "next": { "href": "..." } } }

Copyimport requests
url = f"https://{CLUSTER}/api/storage/volumes"
params = {"fields": "name,size,space", "max_records": 500}
recs = []
while url:
    j = requests.get(url, params=params, auth=(USER, PW), verify=False).json()
    recs += j["records"]
    nxt = j.get("_links", {}).get("next", {}).get("href")
    url = f"https://{CLUSTER}{nxt}" if nxt else None
    params = None  # the next-link already carries the query

Copy# 1. Login GET — keep cookies, capture the CSRF token from headers
curl -sk -c ck.txt -D - -o /dev/null \
  -H "X-EMC-REST-CLIENT: true" -u admin:PASSWORD \
  "https://UNITY/api/types/loginSessionInfo/instances"
# → header:  EMC-CSRF-TOKEN: <token>

# 2. Reads: cookies + client header are enough
curl -sk -b ck.txt -H "X-EMC-REST-CLIENT: true" \
  "https://UNITY/api/types/pool/instances?fields=name,sizeTotal,sizeUsed"

# 3. Writes: add the CSRF token
curl -sk -b ck.txt -X POST \
  -H "X-EMC-REST-CLIENT: true" \
  -H "EMC-CSRF-TOKEN: <token>" \
  -H "Content-Type: application/json" \
  -d '{"name":"LUN_APP01","lunParameters":{"pool":{"id":"pool_1"},"size":1099511627776}}' \
  "https://UNITY/api/types/storageResource/action/createLun"

Copy# Everything is wrapped: entries[].content
{ "entries": [
    { "content": { "id": "pool_1", "name": "Pool_SSD",
                   "sizeTotal": 21990232555520, "sizeUsed": 9895604649984 } }
] }
# Paginate with ?page=N&per_page=M ; add &compact=true to trim envelopes

Copy# Which arrays does this Unisphere manage?
curl -sku user:PASS "https://UNISPHERE:8443/univmax/restapi/100/system/symmetrix"

# SRDF state per storage group — the compliance workhorse
curl -sku user:PASS \
 "https://UNISPHERE:8443/univmax/restapi/100/replication/symmetrix/{sid}/storagegroup/{sg}/rdf_group"

Copy# 1. Login — capture cookies and the DELL-EMC-TOKEN header
curl -sk -c ck.txt -D - -o /dev/null -u admin:PASS \
  "https://ARRAY/api/rest/login_session"

# 2. Reads: select fields explicitly, page with limit/offset
curl -sk -b ck.txt \
  "https://ARRAY/api/rest/volume?select=id,name,size&limit=1000&offset=0"

# 3. Writes: add the token
curl -sk -b ck.txt -X POST -H "DELL-EMC-TOKEN: <token>" \
  -H "Content-Type: application/json" -d '{"name":"vol01","size":1099511627776}' \
  "https://ARRAY/api/rest/volume"

Copy# First page
GET /platform/12/quota/quotas?limit=1000
# response ends with:  "resume": "1-1-MAAw..."   (null when done)

# Every later page: the resume token REPLACES all other query params
GET /platform/12/quota/quotas?resume=1-1-MAAw...

Copy# v2: conventional GET
curl -sk -u admin:PASS "https://PRISM:9440/PrismGateway/services/rest/v2.0/storage_containers/"

# v3: listing is a POST with a body — not a GET
curl -sk -u admin:PASS -X POST -H "Content-Type: application/json" \
  -d '{"kind":"vm","length":500,"offset":0}' \
  "https://PC:9440/api/nutanix/v3/vms/list"

Copycurl -sk -X POST -H "X-Auth-Username: superuser" -H "X-Auth-Password: PASS" \
  "https://CLUSTER:7443/rest/auth"
# → { "token": "..." }

curl -sk -X POST -H "X-Auth-Token: TOKEN" "https://CLUSTER:7443/rest/lsvdisk"

Copy# 1. Open a session
curl -sk -u user:PASS -X POST \
  "https://CM:23451/ConfigurationManager/v1/objects/storages/{devId}/sessions"
# → { "token": "...", "sessionId": N }

# 2. Use it
curl -sk -H "Authorization: Session TOKEN" \
  "https://CM:23451/ConfigurationManager/v1/objects/storages/{devId}/ldevs?count=200"

# 3. ALWAYS close it — session slots are finite
curl -sk -H "Authorization: Session TOKEN" -X DELETE \
  "https://CM:23451/ConfigurationManager/v1/objects/storages/{devId}/sessions/{sessionId}"

Part 1 — Theory: two numbers, two axes, one rule

Business continuity is keeping the business running when something breaks; disaster recovery is the technical subset storage engineers own. Every DR design reduces to two numbers — and confusing them is the most common mistake in the field.

The Seven Tiers (SHARE/IBM, 1992 — still maps onto everything)

The two axes that make every marketing name legible

Axis 1 — timing (when the host gets its ack): synchronous commits on both arrays before acknowledging — RPO 0, latency pays the round trip, distance practically capped near ~100 km / sub-10 ms. Asynchronous acknowledges locally and catches the remote up — RPO > 0, unlimited distance.

Axis 2 — mechanism (how the change travels):

Active-active (metro / stretched) is a special shape of sync: both arrays present the same volume and serve I/O simultaneously, kept identical through a quorum witness. No source, no target — compliance is pair state, Active or Suspended. Examples: Hitachi GAD, SRDF/Metro, PowerStore Metro Volume, Pure ActiveCluster, NetApp MetroCluster.

Finally: a consistency group ties volumes together so they replicate and fail over as a unit, preserving write order across all of them. Any database with data and logs on separate volumes needs one. Every vendor implements it; only the name changes — consistency group, protection group, RDF group, journal group, copy group.

Why synchronous replication has a latency floor

"RPO 0" has a mechanical cost, and it shows up as a hard distance/latency ceiling — not a marketing footnote. Under synchronous replication the host write is not acknowledged until the remote array has the data too: host → local cache → wire → remote cache → ack back → ack to host. That round trip sits directly in every write's response time, which is why sync deployments are commonly planned inside a sub-10 ms round-trip / ~100 km envelope — vendor-specific ceilings vary (SRDF/S, TrueCopy, and ONTAP Synchronous SnapMirror each publish their own supported distance/latency tables; treat this as a planning heuristic, not a physical constant, and confirm against your platform's current interoperability matrix).

Two consequences follow directly from that mechanism, not from any one vendor's implementation:

Working out actual asynchronous RPO — not the adjective, the number

"Asynchronous" describes the acknowledgment model, not a number. The number a DR runbook needs is: if I fail over right now, how far back does my recovered copy sit? That depends on which of the four async mechanisms above is running, and the formula differs by mechanism:

Part 2 — Eleven platforms, mapped to the same axes

Each card: the replication technologies, which mechanism they are underneath, and the field-verified gotchas. Expand what you run.

This section condenses the author's full Business Continuity & Storage Replication Field Reference (Clear Technologies / VSI Platform Engineering, 2026) — vendor facts verified against current vendor documentation at time of writing.

The verbs, per platform — CLI, not API

The lifecycle from the theory section, expressed in each platform's native operator CLI. Rows are the same everywhere; only the words change. Commands are the canonical forms — production use takes device/group arguments and flags that vary by version; the linked vendor references carry every option.

Dell PowerMax / VMAX — SYMCLI symrdf

NetApp ONTAP — snapmirror

Hitachi VSP — CCI (pair* / horctakeover)

IBM FlashSystem / SVC — Storage Virtualize CLI

HPE 3PAR / Primera / Alletra 9000 — Remote Copy CLI

Pure Storage FlashArray — Purity CLI

Dell PowerScale — SyncIQ (isi sync)

Dell Data Domain — MTree replication

Dell Unity XT & PowerStore — session CLIs

HPE Nimble / Alletra 6000 — volume collections

Full option references: Dell Solutions Enabler SRDF CLI Guide, the ONTAP command reference, Hitachi CCI guides, IBM Storage Virtualize command docs, and the HPE 3PAR CLI Reference — see Resources.

One discipline, four vocabularies

SRDF, SnapMirror, Universal Replicator, and ActiveDR are the same idea wearing four uniforms: a source that owns the write, a target that shadows it, a link between them, and a set of verbs for breaking and reversing that relationship on purpose. Engineers who know one stack freeze when handed another — not because the concepts changed, but because every vendor renamed them. This table is the translation layer.

Command & concept mapping

The lifecycle every stack shares

Strip away the vendor names and one state machine remains. Learn it once; map it forever.

Three rules that survive every vendor

1 — Failover is a write-ownership transfer, not a copy operation. Whether it's symrdf failover, snapmirror break, or horctakeover, the command's real job is deciding which side is allowed to accept writes. Data movement is what happens before and after.

2 — Async means the target is a point in time, not a mirror. SRDF/A cycles, SnapMirror schedules, and UR journals all trade currency for distance. Know the cycle/schedule interval — that is a component of your RPO, and it belongs in the DR runbook as a number, not an adjective; see the worked RPO formulas above for how that interval becomes an actual worst-case number per mechanism. (The RPO bandwidth calculator below turns change rate into required link capacity; the journal/CDP sizing calculator turns change rate into required journal capacity.)

3 — The failback plan is the failover plan. Every takeover creates an inverted relationship that someone must resync, reverse, or rebuild. A DR drill that ends at "application is up at site B" is half a drill. Write the return leg first.

The replication simulator

One replication pair, six vendor CLIs. The state machine underneath never changes — only the vocabulary does, which is the entire thesis of this site made playable. Type commands, watch the pair react, and run the missions every storage engineer must be able to perform half-asleep. Type help to list every modeled command in the current dialect — inventory (symrdf list, lsrcrelationship, showrcopy…), health (ping, verify, pairvolchk), mode changes, split for DR tests, update before failback, swap — the full lifecycle. Switch dialects mid-mission and finish in another vendor’s words.

Why hard zoning exists, and where it breaks down

The Zoning Studio below generates zone configs; this section is the theory the tool assumes you already know. Two topics that "soft vs. hard zoning" 101-level writeups usually name but don't finish explaining: what soft zoning's WWPN-based membership actually fails to stop, and what happens to zone enforcement once NPIV puts more than one host identity behind a single physical switch port.

Soft zoning: membership is not enforcement

Zoning has two independent jobs that are easy to conflate: membership (which WWPNs are configured into a zone together) and enforcement (what actually stops traffic between WWPNs that aren't). Soft zoning does the first and not the second.

Under soft zoning, the fabric's name server simply omits devices outside a WWPN's zone from that WWPN's query results — a host asking "what targets exist?" only gets back the targets it's zoned to see. That is a discovery filter, not a traffic block. A host, VM, or compromised initiator that already knows (or guesses, or is manually configured with) a target's WWPN can address it directly — the switch enforces nothing at the frame level and simply forwards the frame, because soft zoning never programmed a hardware filter to drop it. Hard zoning is different in exactly this respect: the fabric switch enforces zone membership at the port ASIC, validating source ID (S_ID) and destination ID (D_ID) on every frame and dropping traffic between ports whose IDs aren't co-zoned — independent of what any device claims its own WWPN is.

NPIV: when the WWPN you're zoning isn't the physical port

N-Port ID Virtualization (NPIV) lets one physical HBA port register multiple virtual WWPNs with the fabric — the mechanism behind per-VM WWPNs on a hypervisor, and behind N-Port Virtualizer (NPV) blade-switch designs where an entire chassis's server ports "borrow" fabric services from an upstream core switch rather than joining the fabric as full switches themselves.

Standard zoning theory assumes a roughly 1:1 relationship between a physical port and the WWPN sitting behind it. NPIV breaks that assumption on purpose — and that has two concrete consequences worth knowing before you zone an NPIV or blade environment:

Both points above describe the standard, vendor-documented NPV/NPIV design tradeoff (fabric services proxied upstream; WWPN-only zoning) rather than a single vendor's specific defect — but exact TCAM budgets, maximum WWPNs-per-port, and zone-database size ceilings are switch-model- and firmware-specific. Check your platform's current configuration limits before sizing a large NPIV deployment.

Ransomware resilience, fabric evolution, key management

Five topics that came up repeatedly when checking what practitioners actually search for versus what this guide covered. Weighted honestly: some of these have real, citable, vendor-verified mechanics; one — capacity forecasting — turned out to be mostly vendor marketing dressed as methodology, and is treated that way below rather than padded out.

Ransomware-resilient backup: 3-2-1-1-0

The classic 3-2-1 rule (3 copies, 2 different media, 1 offsite) says nothing about an adversary who can authenticate to your backup infrastructure and delete or encrypt the backups themselves — which is exactly what modern ransomware playbooks target before triggering encryption on production. 3-2-1-1-0 adds two digits to close that gap. Per Veeam, which popularized this extension of the older 3-2-1 rule: the additional 1 means one copy that is offline, air-gapped, or immutable — these are alternatives satisfying the same requirement, not three separate mandates, though some secondary sources conflate "air-gapped" and "immutable" as if they were the same digit; they aren't identical mechanisms, just interchangeable ways to satisfy this one. The 0 means zero recovery errors, verified by actually testing recovery, not by assuming a completed backup job is a restorable one.

NVMe-oF: the fabric bindings, and why FC-NVMe is a different standards body

NVMe over Fabrics (NVMe-oF) is published by NVM Express, Inc. — the same organization that owns the base NVMe specification. NVMe-oF 1.0 (2016) defined the fabric-independent command and queueing model plus an initial RDMA transport binding (covering InfiniBand, RoCE, and iWARP under one RDMA binding). NVMe-oF 1.1 (2019) added the TCP transport binding (NVMe/TCP) along with improved multipath and discovery. The spec family has since been restructured into a modular set of documents, all maintained at nvmexpress.org.

This sits alongside this guide's existing FC and iSCSI content as the third transport family: NVMe/TCP and NVMe/RoCE run over Ethernet fabrics (the RoCE binding needs a lossless/DCB-configured fabric the same way FCoE does; NVMe/TCP does not), while FC-NVMe rides existing Fibre Channel fabrics and zoning exactly like traditional FCP — the zoning theory above applies to FC-NVMe unchanged, since zoning operates on WWPN identity regardless of which upper-layer protocol (FCP or FC-NVMe) rides on top of the FC fabric.

Encryption and key management: SED vs. array-level vs. application-level, and KMIP

Three layers get called "encryption at rest" and they protect against different failure modes:

KMIP (Key Management Interoperability Protocol) is an OASIS-ratified protocol for standardized communication between storage/encryption endpoints and a centralized external key management server, typically over TCP port 5696. Dell, IBM, and NetApp are documented members of the OASIS KMIP Technical Committee; Nutanix documents support for KMIP-compliant external key management servers in its own security documentation. Pure FlashArray documents Purity//FA native encryption with external KMS integration in its security guides; independently confirm current KMIP-specific support against Pure's current documentation before designing around it, since the mechanism wasn't verified line-by-line against a live KMIP conformance statement for this guide. Same caveat for Hitachi VSP — treat vendor KMIP support as something to confirm against the specific firmware/CM release you run, not as a blanket guarantee across a platform family.

Capacity forecasting — and an honest assessment of what's actually out there

Most vendor capacity-forecasting features are marketed as predictive or AI-driven without publishing the underlying methodology — which, on inspection, is itself informative: it suggests there usually isn't much methodology to publish. NetApp is the one vendor in this guide's coverage that documents its actual algorithm: Active IQ Digital Advisor's Capacity Forecast feature computes an average weekly growth rate from up to twelve months of historical used-capacity data, then extrapolates that rate forward across a one-to-six-month window, flagging systems approaching a 90% projected-utilization threshold — explicitly accounting for reconfiguration events (an aggregate expansion isn't misread as organic growth). That is a real, documented growth-rate-extrapolation methodology — not the "AI/ML-driven" framing Active IQ's broader marketing implies elsewhere; the ML capabilities Active IQ is best known for (anomaly and performance detection) are documented as separate features from this specific capacity forecast, though NetApp's own materials don't draw that exact boundary in a single place.

Hybrid and multi-cloud storage: two concrete mechanisms, not marketing

NetApp FabricPool operates at the block level (4KB blocks), not the file level — the same mechanism tiers both NAS and SAN data uniformly, since ONTAP doesn't distinguish file-vs-LUN at the tiering layer itself. A tiering minimum cooling period defines how long a block must go untouched before it's eligible to move: the Auto policy defaults to 31 days and is manually adjustable from 2 to 183 days (ONTAP 9.8+). (Cloud Volumes ONTAP has a separate, distinct behavior where Auto tiering activates once the aggregate crosses roughly 50% capacity — don't conflate that trigger with the on-prem cooling-period default described here.) A daily background scan finds cold blocks, packages them into 4MB objects, and writes them to the configured object store (AWS S3, Azure Blob, Google Cloud Storage, or an on-prem S3-compatible target including StorageGRID). Tiering policy (None / Snapshot-Only / Auto / All) controls which data classes are eligible for tiering at all.

AWS Storage Gateway bridges on-prem to cloud through four gateway types (a fourth, FSx File Gateway, is closed to new customers but remains documented — not detailed here), all sharing a read-through/write-back local cache — writes commit locally first for low latency, then replicate asynchronously to AWS: S3 File Gateway presents NFS/SMB and lands files as native S3 objects directly manageable via S3 APIs afterward; Volume Gateway presents iSCSI block volumes, with "cached volumes" mode keeping only a working set local while the full dataset lives in S3, and point-in-time snapshots materializing as incremental (changed-blocks-only) EBS snapshots; Tape Gateway emulates a virtual tape library and media changer over iSCSI for existing backup software, with virtual tapes living in S3 and optionally archived to Glacier Flexible Retrieval or Glacier Deep Archive.

Other vendors in this guide's coverage (Pure, Dell, Hitachi, IBM, Nutanix) have their own cloud-tiering and hybrid mechanisms; they aren't detailed here because this guide doesn't yet have primary-source-verified mechanics for them at the same depth as FabricPool and Storage Gateway above. Treat their absence as "not yet researched to this guide's standard," not as "doesn't exist."

The math you keep re-deriving

Five calculators, all client-side — nothing you type leaves your browser. Each encodes a formula storage engineers rebuild in spreadsheets every year.

The shortlist worth bookmarking

Curated, verified, and deliberately short. Primary vendor documentation first; the community references that have earned their place second.

Why trust a personal site over vendor docs?

Don't — use both. Vendor documentation is authoritative for its own platform and always wins on version-specific detail. What it can't give you is the cross-vendor view: the patterns and traps you only learn by making twenty different arrays feed one pipeline. That's the job I do daily — building Python collectors and REST integrations across Pure, NetApp, Dell EMC, Hitachi, IBM, and more for an infrastructure-observability platform — and this site is the notebook from that work, published.

Method: every recipe here follows the same rules as production code. Nothing is included that hasn't been exercised against real or rigorously emulated arrays; behaviors are stated with the API generation they apply to; and when something is a planning heuristic rather than a law (overhead factors, for instance), it's labeled as one. Corrections are welcome and get credited — the fastest route is LinkedIn.

Roadmap: an in-browser array API sandbox (practice real request/response cycles against emulated endpoints, zero setup), more vendors (Hitachi VSP, PowerMax/Unisphere, Isilon/PowerScale), an interactive SRDF course, and Arabic-language editions — there is currently no Arabic-language enterprise storage resource of substance, and that should change.