Agent Settings API

The Slide API lets you inspect and update protected-system settings without using the Slide Console. Use it to audit backup configuration, enforce settings across multiple agents, or integrate Slide with another management system.

The interactive API reference contains the complete request and response schemas. This guide explains how to work safely with the agent settings that have effective policy, capability, or agent-type constraints.

Access and authentication

Agent endpoints use the same user API tokens as the rest of the Slide API.

1. Sign in to the Slide Console.
2. Open My Settings.
3. Create an API token and store the secret securely. The secret is displayed only once.
4. Send the token as a bearer token in the Authorization header.

API tokens inherit the creating user's roles and permissions. Reading settings requires Agent Read permission, while changing settings requires Agent Write permission. Responses are limited to agents the user is authorized to access.

The examples below use environment variables so the API token is not placed directly in scripts:

export SLIDE_API_BASE="https://api.slide.tech"
export SLIDE_API_TOKEN="<your API token>"
export SLIDE_AGENT_ID="a_0123456789ab"

Treat API tokens like passwords. Keep them in a secrets manager, give integrations only the permissions they need, and rotate tokens periodically.

Endpoints

Operation	Endpoint	Required permission
List agents and their settings	GET /v1/agent	Agent Read
Get one agent and its settings	GET /v1/agent/{agent_id}	Agent Read
Update one or more settings	PATCH /v1/agent/{agent_id}	Agent Write
List selectable agent release channels	GET /v1/agent-release-channel	Agent Read

The list endpoint supports pagination and filtering. The maximum page size is 50. For configuration verification, use the single-agent endpoint after you have identified the agent you want to manage.

Verify an agent's settings

curl --fail-with-body \
  -H "Authorization: Bearer $SLIDE_API_TOKEN" \
  "$SLIDE_API_BASE/v1/agent/$SLIDE_AGENT_ID" \
  | jq '{
      agent_id,
      display_name,
      backup_schedule,
      timezone,
      backup_schedule_active,
      backup_paused_until,
      backup_paused_indefinite,
      local_retention_policy,
      volumes_v2_enabled,
      volumes,
      partitions,
      release_channel_id,
      features,
      quiescence_scripts
    }'

backup_schedule_active reports whether backups can currently run. An expired finite pause has an active schedule, even if the previous backup_paused_until value is still present. For an indefinite pause, backup_paused_indefinite is true, backup_schedule_active is false, and backup_paused_until is omitted.

Volume and partition protection

Check volumes_v2_enabled before interpreting or changing volume protection settings.

Legacy volume settings

When volumes_v2_enabled is false, each item in volumes has a volume_id, effective include value, and mount points. Update a legacy volume by sending its ID and desired inclusion state in volumes.

Policy-based settings

When volumes_v2_enabled is true, responses include policy-based volume and partition data:

Field	Meaning
include	The effective capture state after all policies are applied
user_include	The explicitly stored user selection; omitted when the value is inherited
policy	The effective policy status and its reason
recommended_policy	The policy Slide recommends from the current disk and filesystem topology

Policy status can be included, excluded, force_included, or force_excluded. A forced policy protects required system data or excludes unsupported data and cannot be overridden by a user selection. Always verify the returned include and policy after an update instead of assuming that the requested value became effective.

Partitions appear in partitions only for agents using policy-based volume settings. Volume and partition IDs come from the agent's current inventory. Read the agent immediately before an update rather than persisting topology IDs indefinitely.

PATCH requests are partial. Only the volume and partition objects included in the request are changed; omitted rows retain their current user selections. Response-only inventory and policy fields are not accepted in update objects.

{
  "volumes": [
    {
      "volume_id": "v_0123456789ab",
      "include": true
    }
  ],
  "partitions": [
    {
      "partition_id": "part_0123456789ab",
      "include": false
    }
  ]
}

Release channels

Windows and Linux agents have independent release channels. List the channels available for the agent type before updating an agent:

curl --fail-with-body --get \
  -H "Authorization: Bearer $SLIDE_API_TOKEN" \
  --data-urlencode "agent_type=windows" \
  "$SLIDE_API_BASE/v1/agent-release-channel"

The response contains only partner-selectable channels. Each channel identifies its supported agent types and the types for which it is the default.

To change a channel, use an ID returned by this endpoint:

curl --fail-with-body \
  -X PATCH \
  -H "Authorization: Bearer $SLIDE_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"release_channel_id":"rc_0123456789ab"}' \
  "$SLIDE_API_BASE/v1/agent/$SLIDE_AGENT_ID"

Slide rejects channels that are unavailable to partners or incompatible with the agent type. Release-channel selection applies to Windows and Linux agents.

Update several settings together

You can combine independent settings in one PATCH. This example updates the release channel and selected protection rows without changing omitted volumes or partitions:

curl --fail-with-body \
  -X PATCH \
  -H "Authorization: Bearer $SLIDE_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data @- \
  "$SLIDE_API_BASE/v1/agent/$SLIDE_AGENT_ID" <<'JSON'
{
  "comments": "Managed by server-baseline automation",
  "release_channel_id": "rc_0123456789ab",
  "volumes": [
    {"volume_id": "v_0123456789ab", "include": true}
  ],
  "partitions": [
    {"partition_id": "part_0123456789ab", "include": false}
  ]
}
JSON

The response is the complete updated agent object. Compare the returned effective settings with the desired state and record any forced policy that prevented a requested protection change.

Pause and resume backups

Use one of the following fields in an Agent PATCH:

Desired state	Request field
Pause until a specific time	backup_paused_until with an RFC 3339 timestamp
Pause without an automatic resume time	backup_paused_indefinite: true
Resume immediately	backup_resume: true

backup_resume takes precedence if it is sent with another pause field. After an update, use backup_schedule_active, backup_paused_indefinite, and backup_paused_until to verify the effective state.

Capability and script inventory

features contains capability identifiers reported by the agent. Use this list, the agent type, and volumes_v2_enabled to decide which settings an automation should manage. Agents can differ by platform and version, so integrations should tolerate unfamiliar feature identifiers.

quiescence_scripts lists the quiescence scripts discovered by the agent, including each script ID and path. This inventory is read-only. Manage the script files on the protected system, then read the agent again to verify discovery.

Other configurable settings

Agent PATCH also supports the settings already available in the public API, including:

• display name and comments;
• backup schedule and timezone;
• local snapshot retention;
• alert pauses and resumes;
• default restore CPU, memory, network model, and disk bus;
• VSS writer participation;
• file indexing;
• NAS share path and credentials for NAS agents.

Passphrases and Windows service verification use their dedicated agent subresource endpoints. See the interactive API reference for their request and response schemas.

Safe automation pattern

For each agent:

1. Read the current agent object.
2. Check the agent type, features, and volumes_v2_enabled.
3. Build a PATCH containing only settings and protection rows that should change.
4. Send the PATCH.
5. Verify the complete returned agent object, including effective policy and pause state.
6. Re-read the agent before retrying a topology-dependent update.

This read-modify-verify flow prevents an automation from relying on stale volume or partition IDs and makes forced policy decisions visible.