Sources

A deployment’s Sources page shows every installed source that fills a synced table, 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 commands, against the same deployment. Other pages link here: a synced table on the Data page 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. Declare a synced 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, 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.

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.

​

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. 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: 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. 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. 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 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 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 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.

​

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

Manage accounts is how an application user connects their own provider account, as described in Connected accounts. It appears once a source-bound table is deployed. 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. 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. 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: 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.