preview
We're still working on this feature, but we'd love for you to try it out!
This feature is currently provided as part of a preview program pursuant to our pre-release policies.
You can use our NerdGraph API to create and manage Pathpoint flows programmatically, instead of building them in the UI.
A flow represents one business journey, such as checkout, authentication, or onboarding. It's the unit you create and manage through the API. Flows are entities, so each one has an entity GUID you use to read, update, or delete it.
Every flow follows a four-tier hierarchy, with KPIs attached at the flow level, the stage level, or both:
Flow├── Flow KPIs└── Stages ├── Stage KPIs └── Levels └── Steps └── Signals (entity GUIDs, alert condition GUIDs, or a dynamic query)For an introduction to Pathpoint itself, see Get started with Pathpoint.
Before you begin
You need:
- Pathpoint enabled on your account.
- A New Relic to authenticate your requests.
- Your account ID.
Flow operations
To run these examples interactively, open the NerdGraph GraphiQL explorer and search the schema for pathPoint. Before running an example, replace its placeholders with your own values: YOUR_ACCOUNT_ID, TARGET_ACCOUNT_ID, FLOW_GUID, SOURCE_FLOW_GUID, ENTITY_GUID, ANOTHER_ENTITY_GUID, ENTITY_NAME, ALERT_CONDITION_GUID, and the stage, level, and step IDs.
Create a flow
Create a flow by passing its nested stages, levels, steps, and signals in a single mutation.
pathPointCreate requires the account scope. Within the payload, only name is required. Everything else, including stages, is optional. A step gets its signals in one of three ways, and you can combine them:
- A dynamic query (
entitySearchQuery): Whatever entities match the query, re-evaluated at each refresh. - A pinned entity (
type: ENTITY): One specific entity, identified by its GUID. - A pinned alert condition (
type: ALERT): One alert condition, identified by its GUID.
The type field is optional. The GUID is enough to identify the signal.
Stages also take an optional related block that controls how the UI draws the connector arrows between them, independent of health rollup. Set source: true if a stage should show an incoming arrow from the stage before it, and target: true if it should show an outgoing arrow to the stage after it. In a flow where every stage connects to the next in sequence, the first stage is source: false, target: true, the last is source: true, target: false, and every stage in between is true for both.
Importante
A KPI's accountId defaults to the flow's account. If you set it to a different account, the KPI isn't created and no error comes back. Check the excludedKpis field in the response to see which KPIs the mutation skipped.
Read a flow
Read a flow by its entity GUID to get its full configuration plus the current health status of the flow, each stage, each level, and each step. healthStatus appears only on reads.
Stages, levels, and steps return 50 items per page. When a nextCursor comes back non-null, pass it to fetch the next page.
{ actor { account(id: YOUR_ACCOUNT_ID) { pathPoint { flow(guid: "FLOW_GUID") { guid name description category refreshInterval healthRollup healthStatus version message kpis { id name category accountId query { from where select { aggregationType attribute alias threshold } timeWindow { customRange relativeRange { since compareAgainst } } } metricQuery } stages { totalCount nextCursor items { id name link healthRollup healthStatus isExcluded related { source target } levels { totalCount nextCursor items { id healthStatus steps { totalCount nextCursor items { id name healthStatus isExcluded scopedAccounts config { healthRollup thresholdType thresholdValue } entitySearchQuery { query isExcluded } signals { guid name type isExcluded } } } } } } } metadata { createdAt createdBy { name email } updatedAt updatedBy { name email } } } } } }}Request fewer fields if you don't need the whole tree. Reading just name and healthStatus, for example, is enough to poll a flow's status.
Update a flow
pathPointUpdate is a diff-based operation. It compares the payload you send against the flow's current state and acts on each stage, level, step, and KPI according to whether you included its ID:
- ID included: Updates the existing object.
- ID omitted: Creates a new object.
- Object left out of the payload entirely: Deletes it from the flow.
Advertencia
Because omission means deletion, always read the flow first, modify the payload you get back, and send the complete intended state. Sending a partial payload deletes everything you left out.
The version field is also required. It's the flow's last-updated timestamp in epoch milliseconds, used for optimistic concurrency control. Omitting it or sending a stale value causes the update to fail.
Duplicate a flow
You can duplicate either the structure alone or the whole flow:
STRUCTURE: Copies stages, levels, and steps only, without signals or KPIs.WHOLE_FLOW: Copies the structure along with its signals and KPIs.
Any property you set in the input overrides the source flow's value. Omit a property to inherit it.
Delete a flow
Deleting a flow cascades: it removes the flow along with all its stages, levels, steps, and KPIs. The signals themselves, the entities and alert conditions the flow pointed at, stay in your account.
Advertencia
Deleting a flow is permanent.
mutation { pathPointDelete(guid: "FLOW_GUID") { guid name }}Partial failures
A create or update can succeed overall while individual objects fail. Two fields in the response tell you when that happened:
message: Details of any stages, levels, or steps that failed. It'snullwhen everything succeeded.excludedKpis: The names of KPIs that weren't created, most commonly because the KPI'saccountIddidn't match the flow's account.
Request both fields in your mutations so you don't treat a partial success as a complete one.
Limits
The following limits apply to every flow, whether you build it through the API or in the UI:
Limit | Value |
|---|---|
Maximum stages per flow | 50 |
Maximum levels per stage | 50 |
Maximum steps per level | 50 |
Maximum items returned per page | 50 |
Type reference
These enums appear in the operations above. Each row lists the accepted values, followed by what they control:
Enum | Values |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|