--- title: "SqlBak Integration" description: "SqlBak is a database backup and monitoring platform. Workflows check that scheduled backup and maintenance jobs actually ran, read run logs and upload results, and review servers, connections, and destinations." url: https://flowrunner.ai/integrations/sqlbak date_modified: 2026-09-04T14:59:52-07:00 --- # SqlBak [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) SqlBak is a database backup and monitoring platform. Workflows check that scheduled backup and maintenance jobs actually ran, read run logs and upload results, and review servers, connections, and destinations. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 17 actions · API key · available [SqlBak website](https://sqlbak.com/) · [Platform Documentation](https://sqlbak.docs.apiary.io/) · Capability data verified 2026-08-25 1. The morning backup check fires once the maintenance window has closed 2. List Servers filtered to disconnected agents finds machines that took no backup and raised no failure 3. List Job Runs pulls every failed run since the last check, looping over the account's jobs 4. Get Job Run Logs filtered to errors returns the one line that says why 5. Get Job Run's per-destination upload results confirm the file reached off-site storage, not only that the backup finished 6. Silent servers, failed runs, and upload gaps post to the on-call channel as one summary rather than three alerts 7. The database owner decides whether a silent agent is a dead machine or a decommissioned one, and what pages somebody ## What This Integration Enables SqlBak's schedules run on an agent installed on each server, which means this API cannot start a backup, stop one, or create one. That reads like a limitation and it is actually the shape of the product. What SqlBak's API does is tell you whether the backups that were supposed to happen actually did, and that is the question nobody has a good answer to until the morning they need one. The gap this closes is specific. A backup failure that emails somebody is a backup failure that gets seen when that person opens their inbox. A backup that never ran, on a server whose agent quietly disconnected, emails nobody, because there is no failed run to report. FlowRunner agents run the sweep the vendor's own guidance describes, catch both shapes, and put the result where an on-call rotation already looks. Two writes exist in this API, and one of them is the [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) moment on this page, because it is the only operation here that can create something confidently wrong. ### Without FlowRunner **Trust in a green dashboard**: Last night's backup is assumed to have run because nothing said otherwise **Silent servers**: An agent that went offline takes no backups and raises no failed runs, so a job-history check never sees it **Success measured at the wrong step**: A run that backed up cleanly and failed to upload to one destination is counted as a good backup ### With FlowRunner **Verification as a scheduled workflow**: Every failure since the last check is collected, explained by its error log, and delivered as one summary **Absence treated as a signal**: Disconnected agents and jobs that did not run at all are surfaced alongside the ones that failed loudly **Off-site confirmed, not assumed**: Per-destination upload results are read before a backup is called complete ## Use Case Scenarios ### A backup check that catches what did not happen The sweep runs on a schedule. List Jobs narrows to backup jobs, List Job Runs pulls failures since the last check for each one, and Get Job Run Logs filtered to errors returns a line short enough to put straight into an alert rather than a wall of log output. Then the part most monitoring skips: List Servers filtered to disconnected agents. A disconnected agent produces no runs at all, so it is invisible to any check built on job history, and it is the failure a backup monitor most needs to find. Failures route to [PagerDuty](https://flowrunner.ai/integrations/pagerduty) and the daily summary posts to [Slack](https://flowrunner.ai/integrations/slack) or [Microsoft Teams](https://flowrunner.ai/integrations/microsoft-teams). Per-job, Get Job Last Run answers the cheap version of the same question, with one caveat worth building around: it says nothing when a job did not run, so a schedule that silently stopped presents as an old success. ### The backup that succeeded and did not go anywhere Get Job Run returns per-database backup results and per-destination upload results as separate sets. A run can back up cleanly and fail to upload to one of several destinations, and a check that reads only the run status calls that a good night. The agent reads both and reports the destination that did not receive the file. Alongside it, a periodic audit of List Destinations filtered to local-folder targets is worth the two minutes it costs: a backup that exists only on the machine it came from is not an off-site backup, whatever the job status says. Findings land in a tracking record in [Linear](https://flowrunner.ai/integrations/linear) so the remediation has an owner. ### Standing up a new server without a page of manual configuration Get Job Settings returns the same document shape Import Job From JSON accepts, so the two together clone a working backup job onto a new machine. For a team adding database servers on any regular cadence, that turns an afternoon of clicking into a workflow step. It is also the one operation on this connector that can produce something broken and healthy-looking at the same time, which is the next section. ## Human-in-Loop Highlight Import Job From JSON is one of only two writes SqlBak exposes, and it is the one that can create a job that reports success forever while doing the wrong thing. A settings document exported from a working job carries destination ids and DBMS connection ids that belong to the source server. Import it onto a new machine without remapping those and the new job either writes to the source server's destination or points at a connection that means something different there. Nothing errors. The runs come back green. The logs are clean. The problem surfaces at restore time, which is both the first moment anybody looks and the worst possible moment to look. So the clone stops before the import. The agent pulls the source settings, resolves every id against List Destinations and List DBMS Connections for the target server, and posts what it could not match: "Cloning `nightly-full` from db-prod-01 to db-prod-04. Schedule, retention, and compression map cleanly. Destination `4471` (Azure container `backups-prod`) exists on the target. Connection `812` does not: db-prod-04 has two SQL Server connections, `903` and `907`. Which one is this job's database, or should I stop?" The agent did the comparison. The person who knows which database is which owns the answer, because the alternative is discovering it during a restore. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 17 actions ### Account 1 - **Get Account** Returns the SqlBak account with its subscription, credit, and the accounts it manages or is managed by. Worth checking the suspension flag and credit figure specifically: a suspended account keeps answering reads and stops taking backups, which is the quietest way for this product to be off. Also the cheapest connection check. ### Servers 4 - **List Servers** Returns the servers running the SqlBak agent. Filtered to disconnected status it is a dead-agent alerter, and that is the highest-value use of this operation: a disconnected agent takes no backups and raises no job failures, so nothing built on job history will ever mention it. - **Get Server** Returns one server's name, status, and agent type. - **Get Server Settings** Returns a server's monitoring and alerting settings: its temporary folder, its alert recipients, its down-alert schedule, and its size and free-space thresholds. Where an account that stopped sending alerts usually explains itself. - **Modify Server Settings** Changes a server's alerting and monitoring settings, and it is the operation that can turn this product's monitoring off. Disabling down alerts, narrowing the alert schedule, or turning off data collection all leave a real outage silent. Omitted fields are left alone rather than cleared, which makes it safe to call with a single field, but the alert address list replaces rather than merges. ### Jobs 5 - **List Jobs** Returns the account's backup and maintenance jobs. The starting point for an account-wide sweep, because the run-history operation requires a job. - **Get Job** Returns one job's summary. - **Get Job Settings** Returns a job's full configuration: which databases, which destinations, the schedule, the compression, and the retention. This doubles as the export, since what it returns is the document shape the import operation accepts. - **Get Job Last Run** Returns a job's most recent run. The cheapest health check for a single job and the one a dashboard actually asks. It says nothing when the job did not run at all, so the start time needs comparing against what was expected rather than read as reassurance. - **Import Job From JSON** Creates a job on a server from a settings document. Paired with the settings export it clones a working backup job onto a new machine. The settings carry destination and connection ids belonging to the source server, so a cross-server clone needs those remapped before the import rather than after. ### Job Runs 3 - **List Job Runs** Returns a job's run history. Filtered to failed status with a start-time floor it is a complete backup-failure alerter, and unlike a last-run check it catches every failure since the previous sweep rather than only the most recent one. - **Get Job Run** Returns one run in detail, including per-database backup results and per-destination upload results. Reading the upload results rather than the run status is what separates a verified off-site backup from a job that finished. - **Get Job Run Logs** Returns a run's log entries. Filtered to errors the result is usually one line worth putting straight into an alert. The severity filter selects a single level rather than that level and above, so warnings do not include errors. ### Connections and Destinations 4 - **List DBMS Connections** Returns the database connections the agents use. The lookup behind any cross-server clone, because connection ids are server-specific. - **Get DBMS Connection** Returns one database connection. - **List Destinations** Returns the storage destinations backups upload to, and narrowing by job answers where one job's backups actually go. Filtering to local-folder destinations is a worthwhile audit on its own. - **Get Destination** Returns one storage destination. ## Frequently Asked Questions ### What can FlowRunner do with SqlBak? FlowRunner agents can run Get Account, List Servers, and Get Server in SqlBak, plus 14 more actions. ### Does connecting SqlBak to FlowRunner require OAuth? No. SqlBak connects to FlowRunner with an API key, no OAuth flow required. ### Can SqlBak trigger a FlowRunner workflow automatically? SqlBak doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at SqlBak?** This integration exposes SqlBak to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/sqlbak. Site index: https://flowrunner.ai/llms.txt