OriginChain docs
examples · graph · 4 / 7

4. path - reachability check

← Graph examples
what this does

Is src connected to dst at all, within max_depth hops? Returns a single boolean. The traversal short-circuits the moment it finds the first connecting path - it does not enumerate every route.

when to use it
  • Permission checks - "is this user in the org tree under that admin?"
  • Reachability gates before running an expensive operation - cheaper than full BFS.
  • "Are these two entities related?" boolean badges in UIs.
schema requirement

The relation must be declared in the schema's [[relations]] block. See schemas/reference#relations.

the request
GET /v1/tenants/:t/graph/:schema/path?rel=...&src=...&dst=...&max_depth=N
curl -G "https://$OC_HOST/v1/tenants/$OC_TENANT/graph/shop.orders/path" \
  --data-urlencode "rel=bought_product" \
  --data-urlencode "src=o001" \
  --data-urlencode "dst=p001" \
  --data-urlencode "max_depth=3" \
  -H "Authorization: Bearer $OC_TOKEN"
what you get back
{ "reachable": true }

One field: reachable: true | false. false means "not within max_depth" - it isn't proof there's no path at higher depth.

how it works
  • Same BFS frontier as bfs, but it stops the instant dst appears in any expansion.
  • Worst case (no path) costs the same as a bounded bfs; best case is a single hop.
  • Use this over bfs whenever you only need the boolean - the savings come from not materialising the visited set.
common mistakes
  • Reading false as "no path". It only means "no path within max_depth". If you need a definitive answer, raise the depth or use all_simple_paths.
  • Swapping src and dst on a one-way relation. path is direction-sensitive. If you need the inverse direction, check that the relation is bidirectional.