Overview
Pure Storage FlashArray is an all-flash block and file storage array. Each array runs the Purity//FA operating environment and presents a REST API on its management endpoint. The 2.x REST interface is token based: you hold a long-lived API token tied to a Purity user account, POST it to the login endpoint, and receive a short-lived session token that is then sent on every subsequent request. The collections underneath describe the array itself, its controllers and drives, the physical hardware tree, the volumes it serves and the host groups those volumes are presented to.
The ReadyWorks connector implements exactly that exchange. Both authentication methods post to an API token endpoint (the default is /api/2.26/login) with an api-token header, read the x-auth-token value out of the response headers, and replay it as x-auth-token on every data call. Each shipped job is a GET against a versioned resource path under /api/2.26/, and the JSON lands in a pure_get_* staging table.
In the estate this gives you the block storage layer. Array, controller, drive and hardware inventory carries the serial numbers and component detail needed for support entitlement and refresh planning. Volume and host-group data shows which hosts are presented which storage, so before you move, rebuild or retire a server you can see what it depends on and what else shares the same group. The alerts job gives a near real-time view of array health alongside the rest of the estate rather than only inside the Purity UI.
The connector is declared bidirectional and the outbound job form is enabled, but no outbound templates ship. As delivered it reads from FlashArray and writes nothing back.
NOTE: The connector id is PURE STORAGE and the help link, template names and staging tables all say Pure Storage, but the display name shown in the connector picker is Everpure and the description reads “Connect to the Everpure (formerly Pure Storage) FlashArray REST API”. Pure Storage has not been renamed to Everpure. Look for Everpure in the picker if you cannot find Pure Storage.
NOTE: Every template pins the REST version into the path as /api/2.26/. Confirm your Purity release serves that version before enabling jobs, and edit the API End Point on each job if it does not.
Connector Properties
Authentication Methods
Two authentication methods ship, both of them API token exchanges handled by the same driver. They differ only in where the API token comes from.
NOTE: Both methods are flagged as the default and both sit at display order 30, so which one a new connection pre-selects is not determined by the metadata. Check which method is selected before saving a new connection.
NOTE: In both recipes the >GetHeader entry is a directive to the driver rather than a header sent to the array. It names the response header (x-auth-token) whose value is captured and then made available as %auth_data% on the data calls.
Method 1: API Token Header Authentication From Enumeration (PURE STORAGE_92efee2bcd)
API Token Header Authentication From Enumeration
A variant intended to take the array’s API token from an enumeration value at run time (%enum_auth_token%) rather than from a field stored on the connection, so that one connection could walk several arrays in turn. Nothing in the shipped metadata supplies that value: the method exposes no API Token field, and none of the nine templates configures an enumeration. Do not select this method unless you have built the enumeration that feeds it.
Connection Configuration Fields (3)
Authentication Configuration
Headers sent on the authentication call:
Headers sent on the data calls:
cURL options:
NOTE: This method sets the cURL POST option on the data calls as well as the authentication call, while every shipped template uses method type GET.
Method 2: API Token Header Authentication (PURE STORAGE_token_head)
API Token Header Authentication
The method to use. You store the FlashArray API token on the connection, and the connector posts it in an api-token header to the API Token Post End Point (default /api/2.26/login), captures the returned x-auth-token session token and sends that on every data call. Generate the API token against a dedicated Purity user with a read-only role. This method also exposes the Single Authentication switch, which controls whether the login is repeated on each pagination or enumeration loop.
Connection Configuration Fields (6)
Authentication Configuration
Headers sent on the authentication call:
Headers sent on the data calls:
cURL options:
Inbound Job Fields Enabled (44)
The inbound job form exposes the standard REST job fields: endpoint, return data node, pagination, three levels of enumeration, and the staging table the response lands in.
Outbound Job Fields Enabled (13)
Inbound Job Templates (9)
Nine inbound templates ship, eight of them mapped to FlashArray REST collections and one blank scaffold. Two are active by default (GET Pure Arrays hourly and GET Pure Alerts every five minutes); the rest ship disabled on a Daily schedule. None sets a return data node and none sets pagination.
Job Template Configuration
Settings Common to All Nine Templates
Settings That Vary by Template
Job Parameters and Enumeration
GET Pure Arrays
Additional staging fields:
GET Pure Alerts
Additional staging fields:
GET Pure Controllers
Additional staging fields:
GET Pure Drives
Additional staging fields:
GET Pure Hardware
Additional staging fields:
GET Pure Host Groups
Additional staging fields:
GET Pure Port Initiators
Additional staging fields:
GET Pure Volumes
Additional staging fields:
NOTE: All eight resource templates carry an Additional Fields entry that stamps a literal Array Name of gso-e3-px90-p01 onto every staged row. That is a value left in the shipped metadata, not your array. Change or remove it on every job before you enable it.
Outbound Job Templates (0)
No outbound templates ship with this connector. The outbound job form is enabled, so you can author your own, but nothing is written back to the array by default.