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

# Sources

> Follow, check and recover the sources that fill your synced tables, and connect accounts, from the console

<Warning>The Sources page is in beta.</Warning>

A deployment's **Sources** page shows every installed
[source](/integrations/overview) that fills a
[synced table](/integrations/synced-tables), grouped by connection. From it you
can follow each source's syncs, check its connection, recover a sync that
stopped, set up a new connection and connect provider accounts. It does the
same work as the [`bijection integration`](/integrations/cli) commands, against
the same deployment.

Other pages link here: a synced table on the
[Data page](/dashboard/deployments/data) shows its sources with a **Source
details** link, and the schema's definition panel links a source-bound table to
its sources. A link from a table or source opens the page with that source
expanded and an **All source connections** link to return to the full list.

## Before any source is deployed

Until the deployment's schema binds a table to an integration collection, the
page shows **Deploy a source definition first**, with a link to the
[Schema page](/dashboard/deployments/schema). Declare a
[synced table](/integrations/synced-tables#binding-a-table) and push it, for
example with `bijection dev`.

Once a source-bound table is deployed but no source is installed, the page
shows **No sources connected** and the setup sections below.

## The list of sources

Sources are grouped by connection: one card per integration and account (or
per connection name, where no account is recorded). The card header shows the
integration, the account's label or the connection name, and how many tables
the connection fills. The page header counts connections and tables, and says
**on this page** when the list is paged. The list shows up to 50 sources a page;
use **Next page** and **First page** to move through it. For a deployment with
[components](/components/using), the selector at the top right chooses the
component.

Each source in a card is one row, with:

* The table it fills, and **Browse →**, which opens the table on the Data page,
  where synced records are read-only.
* Its status, highlighted when it needs attention.
* A freshness label: when the source was last observed, or last checked if that
  is newer (**Observed 5m ago**, **Checked 1h ago**), or **No observation yet**.
  **Check observation time** means the recorded time is ahead of your device's
  clock. A source is labelled stale only against a freshness target configured
  for its table; without one, nothing is marked stale.

| Status | Meaning |
| - | - |
| **Scheduled** | Syncs on its schedule |
| **Updating** | A sync is pending or running |
| **Retry scheduled** | A sync failed in a way that can succeed later; a retry is scheduled |
| **Sync blocked** | A sync can't continue without you. Published data stays readable |
| **Needs attention · unreachable** | The provider is currently marked unreachable |
| **Source continuity lost** | The source's history has a gap, so coverage is incomplete |
| **Imported data erased** | The source's published records were erased |
| **Paused** / **Disconnected** | The connected account is paused or disconnected |
| **Replaced · retire sync** | The connection was replaced and its old sync is still scheduled |
| **Retired** | The connection was replaced and nothing is scheduled for it any more |
| **Schedule unavailable** | The deployment reported no schedule for the source |

Replaced and retired sources are hidden unless you check **Show retired
sources**, except a replaced source whose old sync is still scheduled, which
always shows.

## A source's details

Click a source to expand it. The page loads the source's status only while it
is expanded, and refreshes it every few seconds.

### Syncing and history

**Sync now** requests a sync immediately. If a sync is already running, the
request is served by the next one. It contacts the provider, so it needs
permission to write data.

**Sync history** lists the open sync and the newest finished ones: when each
started, how long it took, what started it (**Schedule**, **Manual**,
**Notification**, **Reconciliation** or **Repair**), its state, and what it
admitted: pages, requests, records received, claims and response bytes, and
when it published. Records received count what the run admitted, not rows that
changed in the table. See [Sync history](/integrations/connections#sync-history).

### Checking the connection

The **Connection** section shows the result of the last check and **Test
connection**, which runs the connection's identity check again and compares the
answer with the verified account, without changing the connection. The result
is **Confirmed**, **Identity differs**, **Unverified** or **Failed** with its
reason, as described in
[Connecting and syncing](/integrations/connections#following-syncs). If the
answer is lost, the button becomes **Finish check** and completes the same check
rather than starting another. Testing needs permission to write data.

**Remote schema** → **Browse tables** lists the tables and views a SQL
connection's credential can see, marking the ones the source reads; click a
table to see its columns, types, nullability and primary key. The listing is for
display only and selects nothing for syncing. Other sources, including
PostgreSQL replication and mail, answer that remote schema browsing covers SQL
connections. Browsing contacts the source, so it needs permission to write data.

### When a sync stops

When the source's last sync recorded a reason, the page shows one line naming
the problem and what to do:

| Recorded reason | Shown as |
| - | - |
| Authentication refused | Provider authentication failed |
| Request signature refused | Provider rejected the request signature |
| Missing permissions | Connection is missing permissions |
| Rate limited | Provider rate limit reached; retries continue |
| Response failed validation | Provider response could not be validated |
| Storage capacity | Sync is waiting for storage capacity; cleanup and retry are scheduled |
| Source or provider busy | Sync is retrying |
| Work limit | Sync needs recovery; reduce the selected scope |
| Provider unavailable | Connection needs attention; check account access and the deployed definition |

When a sync is blocked with retained work, the source shows **Update binding
and resume**, the recovery after a deploy changed the integration. It installs
the source again on the same connection and table, then resumes exactly the
retained work. If the source
changed in the meantime, nothing is resumed and the page asks you to refresh
its status first. It needs permission to deploy and to write data. This is the
console's form of `install` followed by `resume`; see
[When a sync stops](/integrations/connections#when-a-sync-stops).

**Last health observation**, when reported, shows the time of the source's last
health check, each alert with when it began (no completed observation, a
freshness objective exceeded, acquisition held, continuity lost, a failed
quality check, health evidence unavailable, or PostgreSQL WAL retention at
risk), each collection's freshness against its declared objective, and any
declared quality check results. **Findings** lists what the source's own
captures showed, such as a delivered external call whose first later capture
holds different values than it requested. Findings are observations; they
change no outcome.

### Connection details and recovery

**Connection details and recovery** lists the connection name, the integration,
the authorizing account and its state, the verified resource, whether the
transport is currently unreachable, the last reachable and last answered
observations, the acquisition state, the current request's status, when
coverage was last published and the source observation window it covers, and
whether the current request has recorded a publication. A recorded reason is
also shown here in full.

When the source retains a request, three controls act on exactly that request:

* **Continue retained request** runs the retained request again under its own
  ID.
* **Resume acquisition** resumes it, like `bijection integration resume`.
* **Cancel this occurrence** stops future work for it, like
  `bijection integration cancel-source`. Future syncs stay scheduled.
  Cancelling does not undo completed provider effects.

Each needs permission to write data. **Schedule** opens the deployment's
[cron jobs](/dashboard/deployments/schedules).

Some kinds of source add their own section here:

* **PostgreSQL acquisition** shows the replication phase, the last admitted and
  last applied change positions, the source head, retained WAL bytes, the last
  source contact and admitted observation, the recorded reason for a stop, and
  why a publication failed. **Stop acquisition** and **Rebuild source snapshot**
  do what [`postgres-control`](/integrations/postgres#operating-the-source) does,
  against the state the page last read. They need permission to deploy.
* **Mail acquisition** shows whether a mailbox listing is being prepared,
  whether continuity was lost, and the pending content and gap counts.
  **Repair acquisition gaps** is [`mail-repair`](/integrations/mail#gaps-and-repair)
  and needs permission to write data.
* **SQL acquisition** says whether a complete source update is being prepared,
  and when source history is discontinuous.
* A source that reads a published dataset shows the last complete version, the
  version being read and its progress. When publication needs attention,
  **Rebuild from latest version** reads the latest accepted version again, and
  **Remove published records** → **Stop publication and erase records**
  permanently stops the source and deletes its published records. Both need
  permission to deploy, and neither is available while a request is active.

### Webhook events

**Webhook events** manages the
[occurrence feed](/integrations/listeners#webhook-events-for-operations) of a
source whose integration declares one.

* With no handler configured, fill in the **Operation**, the **Event type
  field** and the **Accepted event types**, and click **Configure event
  handler**.
* With a handler, the section shows pending events, events needing attention,
  retained identities and capacity use against the feed's limits, and a table of
  all pending events and the twenty most recent receipts. From it you can
  **Retry this event**, or, when the program changed since an event was
  admitted, confirm with a reason and retry it under the current program. You
  can **Hold processing** and resume it, **Expand identity quota** with a reason
  (it only grows), **Retire this feed** or reopen it, find an event by its
  identity, read a pending event's retained payload, and **Discard this input**
  with a reason.

Configuring, controlling the feed and reading a payload need permission to
deploy. See the [`webhook-*` commands](/integrations/cli#webhook-events).

### Other sections

**Dependent views** links the views computed from the source's table.
**Publication and acquisition evidence** shows the raw status the deployment
reported. **Table definition** shows the synced table's definition.

A replaced connection's source shows only that its records and request history
are retained and, while its old sync is still scheduled, **Retire predecessor
sync**, which needs permission to write data and leaves the current connection
unchanged.

## Connecting accounts

<Warning>Connected accounts are in beta.</Warning>

**Manage accounts** is how an application user connects their own provider
account, as described in
[Connected accounts](/integrations/connections#connected-accounts). It appears
once a source-bound table is deployed.

<Steps>
  <Step title="Choose the application user">
    Enter the user who will own the connection, as the token identifier from
    your authentication provider (`issuer|subject`), and click **Continue**.
    Account requests are then sent as that user, which needs permission to act
    as a user. The deployment refuses account requests from an administrator
    who is not acting as a user.
  </Step>

  <Step title="Start the authorization">
    Choose the **Declared table**, answer any setup fields the integration asks
    of a connecting account, enter the **Redirect URL** the deployment's provider
    client accepts, and click **Connect account**. The provider's consent page
    opens in a new tab.
  </Step>

  <Step title="Finish connecting">
    Paste the complete address the provider returned to into **Returned URL**
    and click **Finish connecting**. An address from a different authorization
    is refused before its code is sent.
  </Step>

  <Step title="Choose resources">
    Check what the account may read and click **Install selected**. The
    selection is complete: a resource left out is no longer acquired.
  </Step>
</Steps>

Each connected account then shows its state (**Connected**, **Paused** or
**Disconnected**), the access granted, when it was last checked, how many of its
sources are acquiring, and its connection health. When the health needs you, the
one repair it offers is:

* **Reconnect this account** when access must be renewed or permissions changed.
  The authorization is bound to this same account, so its sources stay attached.
* **Resume acquisition** when the provider asked to wait longer than the
  integration allows, which holds acquisition until you resume it.
* **Open the recorded failure** when the credential was rejected or the
  installed definition is unavailable. Reconnecting would not repair either.
* Nothing while the provider is throttling or unreachable; retries continue.

The account controls are **Pause**, **Resume**, **Choose resources**,
**Disconnect** and **Erase**, with the effects listed in
[Connected accounts](/integrations/connections#connected-accounts). Disconnect
and Erase ask for confirmation, and Erase asks you to type the account handle;
the deployment refuses to erase an account that is not disconnected. **Hide**
removes the account from this panel only.

The panel remembers the accounts connected in the current browser tab, not
every account of the deployment: a new tab starts with none. The sources those
accounts fill are always listed above, read from the deployment.

## Setting up a connection

**Advanced setup** configures a connection with a deployment credential, the
console's form of the steps in
[Connecting and syncing](/integrations/connections).

<Steps>
  <Step title="Describe the connection">
    Choose the **Declared table** and enter the **Connection name**. The form
    then asks for the integration's
    [setup fields](/integrations/defining-integrations#setup-fields) the
    deployment doesn't hold yet, checking each value as you type, and for the
    **HTTP base URL (when required)** unless a setup field fills it. Secrets are
    never typed into these fields.
  </Step>

  <Step title="Name or store the credential">
    Enter the **Private credential name**. To create it here, open **Create a
    private credential**, enter the value and click **Store credential**. This
    needs permission to write environment variables.
  </Step>

  <Step title="Configure and verify">
    **Configure and verify** configures the connection, then admits and runs its
    identity check. It needs permission to deploy and to write data. If the
    check is still running, **Continue identity request** continues the same
    request.
  </Step>

  <Step title="Install the collection">
    Once the identity is verified, **Install collection** installs the source.
    It then syncs on its declared schedule. **Configure another connection**
    starts over.
  </Step>
</Steps>

The form keeps its progress in the current browser tab, so a reload resumes the
same request instead of starting another. The section also lists every declared
source table with its integration and collection.

## Permissions

Reading the page needs permission to view the deployment's data. Each control
names what it needs above; in summary:

| Permission | Controls |
| - | - |
| Write data (`deployment:data:write`) | Sync now, Test connection, Browse tables, Continue, Resume and Cancel a retained request, Repair acquisition gaps, Retire predecessor sync, account controls |
| Deploy (`deployment:deploy`) | Install collection, PostgreSQL controls, dataset rebuild and erase, webhook event controls |
| Deploy and write data | Configure and verify, Update binding and resume |
| Write environment variables (`deployment:env:write`) | Store credential |
| Act as a user (`deployment:functions:actAsUser`) | Every account request |

A control you lack permission for is shown disabled. The deployment checks the
same permissions itself and refuses a request that lacks one. Admins and
Developers hold all of these; Viewers can read the page but change nothing. See
[Role Actions](/team-management/role-actions).