SqlBak

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 17 actions API key available

SqlBak website Platform Documentation Capability data verified 2026-08-25

The morning backup check fires once the maintenance window has closed

List Servers filtered to disconnected agents finds machines that took no backup and raised no failure

List Job Runs pulls every failed run since the last check, looping over the account's jobs

Get Job Run Logs filtered to errors returns the one line that says why

Get Job Run's per-destination upload results confirm the file reached off-site storage, not only that the backup finished

Silent servers, failed runs, and upload gaps post to the on-call channel as one summary rather than three alerts

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 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 and the daily summary posts to Slack or 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 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

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

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

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

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

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.

Start building with SqlBak

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us