> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parable.work/llms.txt
> Use this file to discover all available pages before exploring further.

# Provider Directory

> Browse Provider Plugins and inspect their available connection options before configuring a Workspace connection.

The Provider Directory lists the systems Parable can connect to and the
Provider Plugins available for each system. Browse it before creating a
connection so your integration can select a supported grouping and
authentication strategy.

In the Workspace Providers page, search matches Provider names across Needs
Attention, Required, Suggested, Connected, and All providers. Counts reflect
the matching Providers; empty sections disappear with their headings and
spacing. Search also filters requested Providers by name. Clearing search
restores the directory. Catalog search resets to the first page and fetches
results without reloading connection state or the page shell.

Status sections and All providers use the same grid spacing. Provider card
headers reserve room for a title and two caption lines, including when the
caption is empty or only one line. Longer descriptions and status reasons
are clamped to two lines, keeping the cards the same height.
The title and caption are centered together against the logo and card, measured
from the title's capital-letter top to the final caption line's baseline.
Descenders extend below that baseline. Font space is trimmed using font metrics,
without a fixed positional offset.
Long Provider names truncate horizontally while accents and descenders remain visible.

## Browse Providers

```bash theme={null}
curl "https://api.parable.work/api/vendors/parable-vendors" \
  -H "Authorization: Bearer $PARABLE_API_TOKEN"
```

Directory responses distinguish several layers:

| Product concept     | Protocol representation   | Purpose                                                              |
| ------------------- | ------------------------- | -------------------------------------------------------------------- |
| Provider            | `ParableVendor`           | The external company or system.                                      |
| Grouping            | `ParableVendorGrouping`   | A product, deployment, or authentication variant beneath a Provider. |
| Provider Plugin     | `Connector`               | The definition Parable uses for authentication and data access.      |
| Provider connection | `TenantConnectorInstance` | A configured copy belonging to the current Workspace.                |

Leaf groupings expose the Provider Plugin choices that can be configured. A
Provider may have more than one grouping when its products or deployment modes
require different credentials or endpoints.

Open **Providers** directly from the Workspace sidebar, which also switches to
People and Protection without a duplicate tab bar above Providers. Use the directory filters
to browse available Providers, connected services, connections needing attention,
and requests. Provider details and connection forms retain their own headers and
breadcrumbs. The connection documentation rail contains **Overview**, **Setup
Guide**, and **Troubleshooting** alongside the configuration form. Open
**Artifacts** from the directory to inspect uploaded data assets.

## Inspect existing connections

List the current Workspace's Provider connections:

```bash theme={null}
curl "https://api.parable.work/api/vendors/tenant-connector-instances" \
  -H "Authorization: Bearer $PARABLE_API_TOKEN"
```

Each instance includes its connection state and the nested plugin definition
needed to understand available authentication strategies and data streams.

Next, [create a Provider connection](/protocols/workspace/providers/connections).

## Frontend cache isolation

Each server-rendered request owns its QueryClient. Browser navigation retains
one client within the resolved Workspace, authenticated session, effective user
and permissions. A scope change replaces the client and its observers before
rendering the new scope. Session tokens are represented by one-way fingerprints,
never serialized as credentials. Server clients do not schedule browser GC timers.

The QueryClient instance is the authenticated cache namespace, so existing query
keys, reads, writes and invalidation prefixes stay unchanged. All consumers use
that provider-owned client. The audit covers the Provider catalog and exclusion
filter, connections, requests, vendor/grouping details, validation polling, admin
Parables and their refs/packages/deployments/report context, user search and
Workspace search/detail. Search, pagination and resource identifiers remain in
their existing keys; polling and cache defaults are unchanged within a scope.

Persisted command receipts include scope in their own keys. The former sidebar
hover-prefetch Map has no remaining consumers on current main. Existing user/resource-scoped draft recovery and
actor-scoped preferences are unchanged. No TanStack persistence or dehydration
path exists in the app; loaders supply initial data.

Regression coverage includes sequential and overlapping streaming SSR, distinct
authenticated scopes, stable browser caching, scope transitions, late responses,
hydration, scoped invalidation, polling and receipt reattachment. Local synthetic
verification compares Tech-startup and Acme's initial HTML with JavaScript disabled,
then checks hydrated membership and supported login, Workspace and impersonation
transitions. Browser request concurrency is complemented by a deterministic
streaming barrier in the regression tests.