Skip to content
PainScaler

Search and reachability

Two related features sharing the same in-memory index: a global search bar, and a hostname-targeted reachability query.

GET /api/v1/search?q=term runs across:

  • Application segments (name, description, domains)
  • Segment groups (name, description)
  • Access policies (name, description)
  • SCIM groups (name)
  • Connector groups (name, description)
  • Server groups (name, description)

Match is case-insensitive substring. Results carry the resource type so the UI can group + link them. No fuzziness, no ranking - if it appears it will get returned. The point is “stop opening twelve console tabs”, not “rebuild ElasticSearch in Go”.

Returns SearchResult[]:

type SearchResult struct {
    Type        string  // "segment" | "segment_group" | "policy" | ...
    ID          string
    Name        string
    Description string
    MatchField  string  // which field hit
}

Reachability

GET /api/v1/reachability?q=hostname answers “who can hit this?” for any hostname.

The query walks the wildcard hierarchy:

  • Exact match against DomainToSegments first.
  • If no exact hit, walk the parents: db.prod.example.com -> *.prod.example.com -> *.example.com -> *.com. First wildcard that matches wins.

Returns ReachabilityResult:

type ReachabilityResult struct {
    Hostname string
    Matches  []SegmentReachability
}


type SegmentReachability struct {
    SegmentID    string
    SegmentName  string
    MatchedDomain string  // the actual entry that matched
    IsWildcard   bool
    Policies     []PolicyCoverage
}

PolicyCoverage is the same shape returned by /api/v1/segment/{id}/policies

  • the policies that grant access to that segment, with their SCIM group references resolved by name where possible.

Policies for a segment

GET /api/v1/segment/{id}/policies is the targeted version: given a known segment ID, list every policy that touches it (directly or via segment group), each enriched with:

  • The action (ALLOW / BLOCK_ACCESS)
  • Rule order
  • Whether the policy targets the segment directly or through a segment group
  • The SCIM groups the policy applies to

This is what the segment detail page calls. It is also the building block for the route matrix (see flow graph).

Why not just search the ZPA console?

The ZPA UI has a search box. It searches one resource type at a time and does not show you the backlinks. Finding “every policy that covers db.prod.internal” from the console takes you through:

  1. Open Application Segments. Search the domain. Get the segment.
  2. Note the segment group.
  3. Open Access Policies. Filter by that segment group. Read each rule to see which SCIM groups apply.
  4. Repeat for any wildcard parents that might also match.

PainScaler’s reachability query does that in one call. That is the whole point.