Get Tribe Search

Find the right tribe for a visitor — the endpoint behind a store finder.

Organisation keys only. A tribe key gets 403 Tribe is not supported (it is already scoped to one tribe, so there is nothing to search).

This endpoint has two completely different modes, chosen by what you send:

1. Direct lookup

Send any of tribe_id, tribe_slug or global_id and it becomes an exact-match lookup over the organisation’s Active tribes. Multiple selectors are ANDed. No geocoding, no distance, no results limit — you get whatever matches.

2. Proximity search

Send address (which gets geocoded) or latitude + longitude, optionally narrowed by a name substring, and capped by results (default 5). The search runs in two phases and stops as soon as it has enough:

1. Territory first — tribes whose drawn territory polygon contains the point, plus tribes whose territory_post_codes list includes the address’s postcode. Deduplicated and sorted by distance. If this alone fills results, the search stops here.
2. Then nearest — the closest remaining tribes by great-circle distance, appended in distance order until results is reached.

So a tribe that owns the territory outranks a tribe that is physically closer. That is deliberate: franchise territory beats raw proximity.

When the address will not geocode (N/A, a typo, a place that does not exist) the endpoint does not error and does not return whatever sits nearest to (0, 0). It falls back to the organisation’s designated fallback tribe — optionally still filtered by name — so a store finder stays populated.

Response — an array of tribes in the same shape as GET /tribes, including the effective website_number_swap_enabled. There is no pagination block. Success is HTTP 201.