# CLAUDE Source: https://altostrat.io/docs/CLAUDE # Mintlify documentation ## Working relationship * You can push back on ideas-this can lead to better documentation. Cite sources and explain your reasoning when you do so * ALWAYS ask for clarification rather than making assumptions * NEVER lie, guess, or make up information ## Project context * Format: MDX files with YAML frontmatter * Config: docs.json for navigation, theme, settings * Components: Mintlify components * Weekly Studio changelog: see `/changelog-update` slash command for the maintenance process. Source git history lives in `~/prototype`. ## Content strategy * Document just enough for user success - not too much, not too little * Prioritize accuracy and usability of information * Make content evergreen when possible * Search for existing information before adding new content. Avoid duplication unless it is done for a strategic reason * Check existing patterns for consistency * Start by making the smallest reasonable changes ## docs.json * Refer to the [docs.json schema](https://mintlify.com/docs.json) when building the docs.json file and site navigation ## Frontmatter requirements for pages * title: Clear, descriptive page title * description: Concise summary for SEO/navigation ## Writing standards * Second-person voice ("you") * Prerequisites at start of procedural content * Test all code examples before publishing * Match style and formatting of existing pages * Include both basic and advanced use cases * Language tags on all code blocks * Alt text on all images * Relative paths for internal links ## Git workflow * NEVER use --no-verify when committing * Ask how to handle uncommitted changes before starting * Create a new branch when no clear branch exists for changes * Commit frequently throughout development * NEVER skip or disable pre-commit hooks ## Do not * Skip frontmatter on any MDX file * Use absolute URLs for internal links * Include untested code examples * Make assumptions - always ask for clarification # Generate a temporary access token Source: https://altostrat.io/docs/api/en/access-tokens/generate-a-temporary-access-token /api/en/faults.yaml post /fault/token Generates a short-lived JSON Web Token (JWT) that can be used to provide temporary, read-only access to specific fault data, typically for embedding in external dashboards. # Read a shared health dashboard Source: https://altostrat.io/docs/api/en/access-tokens/read-a-shared-health-dashboard /api/en/faults.yaml get /fault/token/{id} Returns the fault list associated with a shared health-dashboard token. # Attach Tag to Container Source: https://altostrat.io/docs/api/en/account-containers/attach-tag-to-container /api/en/radius.yaml post /radius/account-containers/{id}/tags/{tagId} # Create Container Source: https://altostrat.io/docs/api/en/account-containers/create-container /api/en/radius.yaml post /radius/account-containers # Delete Container Source: https://altostrat.io/docs/api/en/account-containers/delete-container /api/en/radius.yaml delete /radius/account-containers/{id} Deletes a container. The container must be empty (no child containers or accounts). # Detach Tag from Container Source: https://altostrat.io/docs/api/en/account-containers/detach-tag-from-container /api/en/radius.yaml delete /radius/account-containers/{id}/tags/{tagId} # Get Container Source: https://altostrat.io/docs/api/en/account-containers/get-container /api/en/radius.yaml get /radius/account-containers/{id} # List Containers Source: https://altostrat.io/docs/api/en/account-containers/list-containers /api/en/radius.yaml get /radius/account-containers Retrieve a list of account containers. Can be filtered by parent or level for tree traversal. Includes a separate list of pinned containers. # Move Container Source: https://altostrat.io/docs/api/en/account-containers/move-container /api/en/radius.yaml post /radius/account-containers/{id}/move Initiates an asynchronous job to move a container (and its entire subtree) to a new parent. # Pin Container Source: https://altostrat.io/docs/api/en/account-containers/pin-container /api/en/radius.yaml post /radius/account-containers/{id}/pin Pins a container to the user's dashboard/sidebar for quick access. # Transfer Users Source: https://altostrat.io/docs/api/en/account-containers/transfer-users /api/en/radius.yaml post /radius/account-containers/{id}/transfer-users Bulk transfer all users from this container to another container. # Unpin Container Source: https://altostrat.io/docs/api/en/account-containers/unpin-container /api/en/radius.yaml delete /radius/account-containers/{id}/pin Removes a container from the user's pinned list. # Update Container Source: https://altostrat.io/docs/api/en/account-containers/update-container /api/en/radius.yaml patch /radius/account-containers/{id} # Attach Tag to Account Source: https://altostrat.io/docs/api/en/accounts/attach-tag-to-account /api/en/radius.yaml post /radius/accounts/{id}/tags/{tagId} # Create an Account Source: https://altostrat.io/docs/api/en/accounts/create-an-account /api/en/radius.yaml post /radius/accounts # Delete an Account Source: https://altostrat.io/docs/api/en/accounts/delete-an-account /api/en/radius.yaml delete /radius/accounts/{id} # Detach Tag from Account Source: https://altostrat.io/docs/api/en/accounts/detach-tag-from-account /api/en/radius.yaml delete /radius/accounts/{id}/tags/{tagId} # List Account Groups Source: https://altostrat.io/docs/api/en/accounts/list-account-groups /api/en/radius.yaml get /radius/accounts/{id}/groups # List Accounts Source: https://altostrat.io/docs/api/en/accounts/list-accounts /api/en/radius.yaml get /radius/accounts # Move Account Source: https://altostrat.io/docs/api/en/accounts/move-account /api/en/radius.yaml post /radius/accounts/{id}/move Move an account to a different container. # Retrieve an Account Source: https://altostrat.io/docs/api/en/accounts/retrieve-an-account /api/en/radius.yaml get /radius/accounts/{id} # Update an Account Source: https://altostrat.io/docs/api/en/accounts/update-an-account /api/en/radius.yaml patch /radius/accounts/{id} # Generate Script from Prompt Source: https://altostrat.io/docs/api/en/ai-script-generation/generate-script-from-prompt /api/en/scripts.yaml post /scripts/gen-ai Submits a natural language prompt to the AI engine to generate a MikroTik RouterOS script. The response includes the generated script content, a flag indicating if the script is potentially destructive, and any errors or warnings from the AI. # Get top faulty resources Source: https://altostrat.io/docs/api/en/analytics/get-top-faulty-resources /api/en/faults.yaml get /fault/top_faults Retrieves a list of the top 10 most frequently faulting resources over the last 14 days, along with a sample of their most recent fault events. This is useful for identifying problematic areas in your network. # List faults from the last seven days Source: https://altostrat.io/docs/api/en/analytics/list-faults-from-the-last-seven-days /api/en/faults.yaml get /fault/last-7-days Returns recent fault records for the last seven days for dashboard and health views. # Create an API key Source: https://altostrat.io/docs/api/en/api-keys/create-an-api-key /api/en/api-keys.yaml post /api/keys Creates an API key with the selected permissions. The `secret` is shown exactly once in the response, so store it in a secret manager before you close the dialog or discard the response body. # Delete an API key Source: https://altostrat.io/docs/api/en/api-keys/delete-an-api-key /api/en/api-keys.yaml delete /api/keys/{id} Revokes an API key and removes its backing machine-to-machine application. # List API keys Source: https://altostrat.io/docs/api/en/api-keys/list-api-keys /api/en/api-keys.yaml get /api/keys Returns the API keys owned by the current organization. Secrets are never returned from this endpoint. # Retrieve an API key Source: https://altostrat.io/docs/api/en/api-keys/retrieve-an-api-key /api/en/api-keys.yaml get /api/keys/{id} Returns metadata for one API key. The secret is not returned. # Rotate an API key secret Source: https://altostrat.io/docs/api/en/api-keys/rotate-an-api-key-secret /api/en/api-keys.yaml post /api/keys/{id}/rotate Rotates the API key secret and invalidates the previous secret. The new `secret` is shown exactly once in the response. # Search ARP Entries Source: https://altostrat.io/docs/api/en/arp-inventory/search-arp-entries /api/en/monitoring-metrics.yaml post /metrics/arps Performs a paginated search for ARP entries across one or more sites, with options for filtering and sorting. This is the primary endpoint for building an inventory of connected devices. # Update ARP Entry Source: https://altostrat.io/docs/api/en/arp-inventory/update-arp-entry /api/en/monitoring-metrics.yaml put /metrics/arps/{siteId}/{arpEntryId} Updates metadata for a specific ARP entry, such as assigning it to a group or setting a custom alias. # List audit log events Source: https://altostrat.io/docs/api/en/audit-logs/list-audit-log-events /api/en/audit-logs.yaml get /audit-logs Retrieve a list of audit log events for your organization. This endpoint supports powerful filtering and pagination to help you find specific events for security, compliance, or debugging purposes. Results are returned in reverse chronological order (most recent first) by default. # Create an auth integration Source: https://altostrat.io/docs/api/en/auth-integrations/create-an-auth-integration /api/en/captive-portal.yaml post /captive/auth-integrations Creates a new authentication integration for use with captive portal instances that have an 'oauth2' strategy. # Delete an auth integration Source: https://altostrat.io/docs/api/en/auth-integrations/delete-an-auth-integration /api/en/captive-portal.yaml delete /captive/auth-integrations/{authIntegrationId} Permanently deletes an authentication integration. This action cannot be undone and may affect captive portal instances that rely on it. # List all auth integrations Source: https://altostrat.io/docs/api/en/auth-integrations/list-all-auth-integrations /api/en/captive-portal.yaml get /captive/auth-integrations Retrieves a list of all OAuth2 authentication integrations (IDPs) configured for the user's account. # Retrieve an auth integration Source: https://altostrat.io/docs/api/en/auth-integrations/retrieve-an-auth-integration /api/en/captive-portal.yaml get /captive/auth-integrations/{authIntegrationId} Retrieves the details of a specific authentication integration by its unique ID. # Update an auth integration Source: https://altostrat.io/docs/api/en/auth-integrations/update-an-auth-integration /api/en/captive-portal.yaml put /captive/auth-integrations/{authIntegrationId} Updates the configuration of an existing authentication integration. # Create a workflow authorization URL Source: https://altostrat.io/docs/api/en/authorizations/create-a-workflow-authorization-url /api/en/workflows.yaml post /workflows/authorization Creates an authorization flow URL that lets a workflow act on behalf of the current user. # Delete a workflow authorization Source: https://altostrat.io/docs/api/en/authorizations/delete-a-workflow-authorization /api/en/workflows.yaml delete /workflows/authorization/{authId} Deletes a workflow authorization so workflows can no longer use that delegated account context. # List workflow authorizations Source: https://altostrat.io/docs/api/en/authorizations/list-workflow-authorizations /api/en/workflows.yaml get /workflows/authorization Returns workflow account authorizations available to the authenticated user. # List Backups for a Site Source: https://altostrat.io/docs/api/en/backups/list-backups-for-a-site /api/en/backups.yaml get /backup/{siteId} Retrieves a list of all available configuration backup files for a specific site, sorted from newest to oldest. This allows you to see the entire history of captured configurations for a device. # List discovered site subnets Source: https://altostrat.io/docs/api/en/backups/list-discovered-site-subnets /api/en/backups.yaml get /backup/{siteId}/subnets Returns the subnet routes discovered from the latest configuration data for a site. SDX uses this when you attach site subnets to captive portal, VPN, CVE scan, and other network services. # Request a New Backup Source: https://altostrat.io/docs/api/en/backups/request-a-new-backup /api/en/backups.yaml post /backup/{siteId} Asynchronously triggers a new configuration backup for the specified site. The backup process runs in the background. This endpoint returns immediately with a status indicating the request has been accepted for processing. # Retrieve a Specific Backup Source: https://altostrat.io/docs/api/en/backups/retrieve-a-specific-backup /api/en/backups.yaml get /backup/{siteId}/{filename} Fetches the contents of a specific backup file. The format of the response can be controlled via HTTP headers to return JSON metadata, raw text, highlighted HTML, or a downloadable file. # Create a BGP Threat Intelligence Policy Source: https://altostrat.io/docs/api/en/bgp-threat-intelligence/create-a-bgp-threat-intelligence-policy /api/en/utm-ips.yaml post /content/bgp/policy Creates a new BGP policy, specifying which IP reputation lists to use for blocking traffic. # Delete a BGP Policy Source: https://altostrat.io/docs/api/en/bgp-threat-intelligence/delete-a-bgp-policy /api/en/utm-ips.yaml delete /content/bgp/policy/{policyId} Permanently deletes a BGP policy. This operation will fail if the policy is currently attached to one or more sites. # List BGP IP Reputation Lists Source: https://altostrat.io/docs/api/en/bgp-threat-intelligence/list-bgp-ip-reputation-lists /api/en/utm-ips.yaml get /content/bgp/category Retrieves a list of all available BGP IP reputation lists that can be included in a BGP policy. # List BGP Threat Intelligence Policies Source: https://altostrat.io/docs/api/en/bgp-threat-intelligence/list-bgp-threat-intelligence-policies /api/en/utm-ips.yaml get /content/bgp/policy Retrieves a list of all BGP Threat Intelligence policies associated with your account. # Retrieve a BGP Policy Source: https://altostrat.io/docs/api/en/bgp-threat-intelligence/retrieve-a-bgp-policy /api/en/utm-ips.yaml get /content/bgp/policy/{policyId} Retrieves the details of a specific BGP Threat Intelligence policy by its unique identifier. # Update a BGP Policy Source: https://altostrat.io/docs/api/en/bgp-threat-intelligence/update-a-bgp-policy /api/en/utm-ips.yaml put /content/bgp/policy/{policyId} Updates the properties of an existing BGP policy, including its name, status, selected IP lists, and site attachments. # Create a billing account Source: https://altostrat.io/docs/api/en/billing-accounts/create-a-billing-account /api/en/workspaces.yaml post /workspaces/{workspaceId}/billing-accounts Creates a new billing account within a workspace. This also creates a corresponding Customer object in Stripe. The behavior is constrained by the workspace's billing mode; for `single` mode, only one billing account can be created. For `pooled` and `assigned` modes, up to 10 can be created. # Delete a billing account Source: https://altostrat.io/docs/api/en/billing-accounts/delete-a-billing-account /api/en/workspaces.yaml delete /workspaces/{workspaceId}/billing-accounts/{billingAccountId} Permanently deletes a billing account. This action cannot be undone. A billing account cannot be deleted if it has any active subscriptions. # List billing accounts Source: https://altostrat.io/docs/api/en/billing-accounts/list-billing-accounts /api/en/workspaces.yaml get /workspaces/{workspaceId}/billing-accounts Returns a list of billing accounts associated with a workspace. # Retrieve a billing account Source: https://altostrat.io/docs/api/en/billing-accounts/retrieve-a-billing-account /api/en/workspaces.yaml get /workspaces/{workspaceId}/billing-accounts/{billingAccountId} Retrieves the details of a specific billing account. # Update a billing account Source: https://altostrat.io/docs/api/en/billing-accounts/update-a-billing-account /api/en/workspaces.yaml patch /workspaces/{workspaceId}/billing-accounts/{billingAccountId} Updates the details of a billing account. Any parameters not provided will be left unchanged. This operation also updates the corresponding Customer object in Stripe. # Create a captive portal instance Source: https://altostrat.io/docs/api/en/captive-portal-instances/create-a-captive-portal-instance /api/en/captive-portal.yaml post /captive/instances Creates a new captive portal instance with a basic configuration. Further details, such as themes and sites, can be added via an update operation. # Delete a captive portal instance Source: https://altostrat.io/docs/api/en/captive-portal-instances/delete-a-captive-portal-instance /api/en/captive-portal.yaml delete /captive/instances/{instanceId} Permanently deletes a captive portal instance and all associated subnets, sites, coupons, and assets. This action cannot be undone. # List all captive portal instances Source: https://altostrat.io/docs/api/en/captive-portal-instances/list-all-captive-portal-instances /api/en/captive-portal.yaml get /captive/instances Retrieves a list of all captive portal instances accessible to the authenticated user. # Retrieve a captive portal instance Source: https://altostrat.io/docs/api/en/captive-portal-instances/retrieve-a-captive-portal-instance /api/en/captive-portal.yaml get /captive/instances/{instanceId} Retrieves the complete details of a specific captive portal instance by its unique ID. # Update a captive portal instance Source: https://altostrat.io/docs/api/en/captive-portal-instances/update-a-captive-portal-instance /api/en/captive-portal.yaml put /captive/instances/{instanceId} Updates the configuration of a specific captive portal instance, including its theme, sites, subnets, and other settings. # Upload an instance image Source: https://altostrat.io/docs/api/en/captive-portal-instances/upload-an-instance-image /api/en/captive-portal.yaml post /captive/instances/{instanceId}/images/{type} Uploads a logo or icon for a specific captive portal instance. The image will be stored and served via a signed URL in the instance's theme. # Download Client CA Source: https://altostrat.io/docs/api/en/certificates/download-client-ca /api/en/radius.yaml get /radius/client-ca/certificate # Download NAS Certificate Source: https://altostrat.io/docs/api/en/certificates/download-nas-certificate /api/en/radius.yaml get /radius/nas/{id}/certificates/certificate # Download NAS Private Key Source: https://altostrat.io/docs/api/en/certificates/download-nas-private-key /api/en/radius.yaml get /radius/nas/{id}/certificates/private-key # Fetch a VPN client configuration Source: https://altostrat.io/docs/api/en/client-configuration/fetch-a-vpn-client-configuration /api/en/managed-vpn.yaml get /vpn/client Returns the VPN client configuration for a share token. The portal calls this endpoint with the share token in the bearer `Authorization` header. # Add a comment to a fault Source: https://altostrat.io/docs/api/en/comments/add-a-comment-to-a-fault /api/en/faults.yaml post /fault/{faultId}/comment Adds a new comment to an existing fault. Comments are useful for tracking troubleshooting steps, adding context, or communicating with team members about an incident. # Get Raw README Content Source: https://altostrat.io/docs/api/en/community-scripts/get-raw-readme-content /api/en/scripts.yaml get /scripts/community-scripts/{communityScriptId}.md Downloads the raw, plain-text markdown content of a community script's README file, if one exists. # Get Raw Script Content Source: https://altostrat.io/docs/api/en/community-scripts/get-raw-script-content /api/en/scripts.yaml get /scripts/community-scripts/{communityScriptId}.rsc Downloads the raw, plain-text content of a community script, suitable for direct use or inspection. # List Community Scripts Source: https://altostrat.io/docs/api/en/community-scripts/list-community-scripts /api/en/scripts.yaml get /scripts/community-scripts Retrieves a paginated list of scripts from the public community repository. This is a valuable resource for finding pre-built solutions for common MikroTik tasks. # Retrieve a Community Script Source: https://altostrat.io/docs/api/en/community-scripts/retrieve-a-community-script /api/en/scripts.yaml get /scripts/community-scripts/{communityScriptId} Fetches detailed information about a specific community script, including its content, description, and metadata about the author and source repository. # Submit a Community Script Source: https://altostrat.io/docs/api/en/community-scripts/submit-a-community-script /api/en/scripts.yaml post /scripts/community-scripts Submits a new script to the community repository by providing a URL to a raw `.rsc` file on GitHub. The system will then fetch the script content and associated repository metadata. # Create a coupon schedule Source: https://altostrat.io/docs/api/en/coupon-schedules/create-a-coupon-schedule /api/en/captive-portal.yaml post /captive/instances/{instanceId}/coupon-schedules Creates a new schedule to automatically generate coupons on a recurring basis (daily, weekly, or monthly). # Delete a coupon schedule Source: https://altostrat.io/docs/api/en/coupon-schedules/delete-a-coupon-schedule /api/en/captive-portal.yaml delete /captive/instances/{instanceId}/coupon-schedules/{scheduleId} Permanently deletes a coupon schedule. This will not delete coupons that have already been generated by the schedule. # Generate a signed coupon URL Source: https://altostrat.io/docs/api/en/coupon-schedules/generate-a-signed-coupon-url /api/en/captive-portal.yaml get /captive/instances/{instanceId}/coupon-schedules/{scheduleId}/generate_url Creates a temporary, signed URL that can be used to retrieve the list of valid coupons generated by a specific schedule. This is useful for distributing coupons to third-party systems without exposing API keys. The URL is valid for 24 hours. # List coupon schedules Source: https://altostrat.io/docs/api/en/coupon-schedules/list-coupon-schedules /api/en/captive-portal.yaml get /captive/instances/{instanceId}/coupon-schedules Retrieves a list of all coupon generation schedules for a specific captive portal instance. # Retrieve a coupon schedule Source: https://altostrat.io/docs/api/en/coupon-schedules/retrieve-a-coupon-schedule /api/en/captive-portal.yaml get /captive/instances/{instanceId}/coupon-schedules/{scheduleId} Retrieves the details of a specific coupon schedule by its ID. # Run a coupon schedule now Source: https://altostrat.io/docs/api/en/coupon-schedules/run-a-coupon-schedule-now /api/en/captive-portal.yaml post /captive/instances/{instanceId}/coupon-schedules/{scheduleId}/run Manually triggers a coupon schedule to generate a new batch of coupons immediately, outside of its normal recurrence. # Update a coupon schedule Source: https://altostrat.io/docs/api/en/coupon-schedules/update-a-coupon-schedule /api/en/captive-portal.yaml put /captive/instances/{instanceId}/coupon-schedules/{scheduleId} Updates the configuration of an existing coupon schedule. # Create coupons Source: https://altostrat.io/docs/api/en/coupons/create-coupons /api/en/captive-portal.yaml post /captive/instances/{instanceId}/coupons Generates a batch of one-time use coupons for a specified captive portal instance. # List valid coupons for an instance Source: https://altostrat.io/docs/api/en/coupons/list-valid-coupons-for-an-instance /api/en/captive-portal.yaml get /captive/instances/{instanceId}/coupons Retrieves a list of all valid (unredeemed and not expired) coupons for a specific captive portal instance. # Get Data Transferred Volume Source: https://altostrat.io/docs/api/en/dashboard/get-data-transferred-volume /api/en/monitoring-metrics.yaml get /metrics/dashboard/data-transferred Retrieves the total volume of data transferred (in bytes) across specified sites, aggregated into time buckets. Use this endpoint to analyze data consumption and usage patterns. # Get Network Throughput Source: https://altostrat.io/docs/api/en/dashboard/get-network-throughput /api/en/monitoring-metrics.yaml get /metrics/dashboard/throughput Retrieves time-series data representing the average network throughput (in bits per second) across specified sites over a given time window. Use this endpoint to visualize traffic rates for dashboards and reports. # Delete Job Source: https://altostrat.io/docs/api/en/data-migration/delete-job /api/en/radius.yaml delete /radius/migration/jobs/{jobId} # Download Example CSV Source: https://altostrat.io/docs/api/en/data-migration/download-example-csv /api/en/radius.yaml get /radius/migration/examples/{type}.csv Download a template CSV file for bulk import. # Get Columns Source: https://altostrat.io/docs/api/en/data-migration/get-columns /api/en/radius.yaml get /radius/migration/columns/{type} # Get Job Status Source: https://altostrat.io/docs/api/en/data-migration/get-job-status /api/en/radius.yaml get /radius/migration/jobs/{jobId} # Get Upload URL Source: https://altostrat.io/docs/api/en/data-migration/get-upload-url /api/en/radius.yaml get /radius/migration/signed-url # List Jobs Source: https://altostrat.io/docs/api/en/data-migration/list-jobs /api/en/radius.yaml get /radius/migration/jobs # Preview File Source: https://altostrat.io/docs/api/en/data-migration/preview-file /api/en/radius.yaml get /radius/migration/{filename}/preview # Start Dry Run Source: https://altostrat.io/docs/api/en/data-migration/start-dry-run /api/en/radius.yaml post /radius/migration/dry-run # Start Import Source: https://altostrat.io/docs/api/en/data-migration/start-import /api/en/radius.yaml post /radius/migration/import # Queue an asynchronous RouterOS script Source: https://altostrat.io/docs/api/en/developer-api/queue-an-asynchronous-routeros-script /api/en/mikrotik-api.yaml post /api/asynchronous/{siteId} Queues a RouterOS script for execution on a managed site. Use asynchronous scripts for configuration changes, backups, and work that should be tracked as a device job. # Run a synchronous RouterOS command Source: https://altostrat.io/docs/api/en/developer-api/run-a-synchronous-routeros-command /api/en/mikrotik-api.yaml post /api/synchronous/{siteId} Runs a RouterOS command against a managed site and returns the router response. Use synchronous commands for reads or short diagnostics, not long-running configuration changes. # Get router metadata Source: https://altostrat.io/docs/api/en/developer-routers/get-router-metadata /api/en/mikrotik-api.yaml get /api/routers/{siteId}/metadata Get router metadata exposed by the SDX developer API for a managed router. # Get router metrics summary Source: https://altostrat.io/docs/api/en/developer-routers/get-router-metrics-summary /api/en/mikrotik-api.yaml get /api/routers/{siteId}/metrics Get router metrics summary exposed by the SDX developer API for a managed router. # Get router OEM data Source: https://altostrat.io/docs/api/en/developer-routers/get-router-oem-data /api/en/mikrotik-api.yaml get /api/routers/{siteId}/oem Get router OEM data exposed by the SDX developer API for a managed router. # List developer API routers Source: https://altostrat.io/docs/api/en/developer-routers/list-developer-api-routers /api/en/mikrotik-api.yaml get /api/routers Lists routers that the authenticated API key or user can access through the developer API. # List router faults Source: https://altostrat.io/docs/api/en/developer-routers/list-router-faults /api/en/mikrotik-api.yaml get /api/routers/{siteId}/faults List router faults exposed by the SDX developer API for a managed router. # List router jobs Source: https://altostrat.io/docs/api/en/developer-routers/list-router-jobs /api/en/mikrotik-api.yaml get /api/routers/{siteId}/jobs List router jobs exposed by the SDX developer API for a managed router. # Get Device Heartbeat History Source: https://altostrat.io/docs/api/en/device-health-&-status/get-device-heartbeat-history /api/en/monitoring-metrics.yaml get /metrics/mikrotik-stats/{siteId} Retrieves the device's heartbeat and connectivity status over the past 24 hours, aggregated hourly. This helps identify periods of downtime or missed check-ins. # Get Last Seen Time Source: https://altostrat.io/docs/api/en/device-health-&-status/get-last-seen-time /api/en/monitoring-metrics.yaml get /metrics/last-seen/{siteId} Returns the time since the device at the specified site last reported its status. # Get Recent Device Health Stats Source: https://altostrat.io/docs/api/en/device-health-&-status/get-recent-device-health-stats /api/en/monitoring-metrics.yaml get /metrics/mikrotik-stats-all/{siteId} Retrieves a time-series of key health metrics (CPU, memory, disk, uptime) for a specific site's device from the last 8 hours. # Retrieve Site Stats Over a Date Range Source: https://altostrat.io/docs/api/en/device-stats/retrieve-site-stats-over-a-date-range /api/en/mikrotik-api.yaml get /sites/{siteId}/mikrotik-stats Fetches time-series performance metrics (CPU, memory, disk, uptime) for a site within a specified date range. For ranges over 48 hours, data is automatically aggregated hourly to ensure a fast response. For shorter ranges, raw data points are returned. # JSON Web Key Set (JWKS) Endpoint Source: https://altostrat.io/docs/api/en/discovery/json-web-key-set-jwks-endpoint /api/en/authentication.yaml get /.well-known/jwks.json Provides the set of public keys used to verify the signature of JWTs issued by the authentication server. Clients should use the `kid` (Key ID) from a JWT's header to select the correct key for validation. # OIDC Discovery Endpoint Source: https://altostrat.io/docs/api/en/discovery/oidc-discovery-endpoint /api/en/authentication.yaml get /.well-known/openid-configuration Returns a JSON document containing the OpenID Provider's configuration metadata. OIDC-compliant clients use this endpoint to automatically discover the locations of the authorization, token, userinfo, and JWKS endpoints, as well as all supported capabilities. # Create a DNS Content Filtering Policy Source: https://altostrat.io/docs/api/en/dns-content-filtering/create-a-dns-content-filtering-policy /api/en/utm-ips.yaml post /content/policy Creates a new DNS Content Filtering policy with specified filtering rules, application blocks, and safe search settings. # Delete a DNS Policy Source: https://altostrat.io/docs/api/en/dns-content-filtering/delete-a-dns-policy /api/en/utm-ips.yaml delete /content/policy/{policyId} Permanently deletes a DNS policy. This operation will fail if the policy is currently attached to one or more sites. # List Application Categories Source: https://altostrat.io/docs/api/en/dns-content-filtering/list-application-categories /api/en/utm-ips.yaml get /content/category Retrieves a list of all available application categories. Each category contains a list of applications that can be targeted in DNS policies. # List DNS Content Filtering Policies Source: https://altostrat.io/docs/api/en/dns-content-filtering/list-dns-content-filtering-policies /api/en/utm-ips.yaml get /content/policy Retrieves a list of all DNS Content Filtering policies associated with your account. # List Safe Search Services Source: https://altostrat.io/docs/api/en/dns-content-filtering/list-safe-search-services /api/en/utm-ips.yaml get /content/category/safe_search Retrieves a list of services (e.g., Google, YouTube) for which Safe Search can be enforced in a DNS policy. # Retrieve a DNS Policy Source: https://altostrat.io/docs/api/en/dns-content-filtering/retrieve-a-dns-policy /api/en/utm-ips.yaml get /content/policy/{policyId} Retrieves the details of a specific DNS Content Filtering policy by its unique identifier. # Update a DNS Policy Source: https://altostrat.io/docs/api/en/dns-content-filtering/update-a-dns-policy /api/en/utm-ips.yaml put /content/policy/{policyId} Updates the properties of an existing DNS policy. You can change its name, application blocks, safe search settings, and site attachments. # Search Altostrat Documentation Source: https://altostrat.io/docs/api/en/documentation-search/search-altostrat-documentation /api/en/search.yaml get /search/docs Use this endpoint to integrate Altostrat's official help and developer documentation search directly into your tools. It's designed to provide quick answers and code references, helping developers resolve issues and build integrations faster. # Search for Platform Entities Source: https://altostrat.io/docs/api/en/entity-search/search-for-platform-entities /api/en/search.yaml get /search This endpoint allows for a powerful, full-text search across all indexed entities within a user's tenancy scope. By default, it searches all resources within the user's organization. You can narrow the scope to a specific workspace or apply fine-grained filters based on entity type and creation date to pinpoint the exact information you need. # Activate Failover Service Source: https://altostrat.io/docs/api/en/failover-service/activate-failover-service /api/en/wan-failover.yaml post /failover/{site_id}/configs Activates the WAN Failover service for a specified site. This is the first step to enabling SD-WAN capabilities. Activating the service automatically creates two default, unconfigured WAN tunnels. # Deactivate Failover Service Source: https://altostrat.io/docs/api/en/failover-service/deactivate-failover-service /api/en/wan-failover.yaml delete /failover/{site_id}/configs/{subscription_id} Deactivates the WAN Failover service for a site, removing all associated WAN tunnels and their configurations from both the Altostrat platform and the on-site router. This action is irreversible. # Get Failover Service Status Source: https://altostrat.io/docs/api/en/failover-service/get-failover-service-status /api/en/wan-failover.yaml get /failover/{site_id}/configs Checks the status of the WAN Failover service for a specific site, returning the subscription ID if it is active. # List Sites with Failover Service Source: https://altostrat.io/docs/api/en/failover-service/list-sites-with-failover-service /api/en/wan-failover.yaml get /failover/service-counts Retrieves a list of all sites associated with the authenticated user that have the WAN Failover service currently activated. # Create a fault Source: https://altostrat.io/docs/api/en/faults/create-a-fault /api/en/faults.yaml post /fault Manually creates a new fault object. This is typically used for creating faults from external systems or for testing purposes. For automated ingestion, other microservices push events that are processed into faults. # Delete a fault Source: https://altostrat.io/docs/api/en/faults/delete-a-fault /api/en/faults.yaml delete /fault/{faultId} Permanently deletes a fault object. This action cannot be undone. # List all faults Source: https://altostrat.io/docs/api/en/faults/list-all-faults /api/en/faults.yaml get /fault Returns a paginated list of fault objects for your account. The faults are returned in reverse chronological order by creation time. You can filter the results using the query parameters. # Retrieve a fault Source: https://altostrat.io/docs/api/en/faults/retrieve-a-fault /api/en/faults.yaml get /fault/{faultId} Retrieves the details of an existing fault. You need only supply the unique fault identifier that was returned upon fault creation. # Update a fault Source: https://altostrat.io/docs/api/en/faults/update-a-fault /api/en/faults.yaml put /fault/{faultId} Updates the specified fault by setting the values of the parameters passed. Any parameters not provided will be left unchanged. This is useful for changing a fault's severity or manually resolving it. # Delete a Generated Report Source: https://altostrat.io/docs/api/en/generated-reports/delete-a-generated-report /api/en/reports.yaml delete /reports/sla/reports/{reportId} Permanently deletes a previously generated report and its associated PDF and JSON data from storage. # List Generated Reports Source: https://altostrat.io/docs/api/en/generated-reports/list-generated-reports /api/en/reports.yaml get /reports/sla/reports Retrieves a paginated list of all historically generated reports for the workspace, sorted by creation date in descending order. # Export dashboard panel CSV Source: https://altostrat.io/docs/api/en/grafana-dashboards/export-dashboard-panel-csv /api/en/monitoring-metrics.yaml post /metrics/dashboards/{dashboardUid}/panels/{panelId}/export Exports a single Grafana dashboard panel as CSV for reporting, audit, or billing workflows. # List dashboards Source: https://altostrat.io/docs/api/en/grafana-dashboards/list-dashboards /api/en/monitoring-metrics.yaml get /metrics/dashboards Lists available Grafana dashboards with their variables and panel metadata. # List dashboards in a folder Source: https://altostrat.io/docs/api/en/grafana-dashboards/list-dashboards-in-a-folder /api/en/monitoring-metrics.yaml get /metrics/dashboards/{folderName} Lists Grafana dashboards from a specific folder. # Query a dashboard Source: https://altostrat.io/docs/api/en/grafana-dashboards/query-a-dashboard /api/en/monitoring-metrics.yaml post /metrics/dashboards/{dashboardUid}/query Executes the Prometheus queries defined by a Grafana dashboard, optionally limiting the request to selected panels. # Attach Tag to Group Source: https://altostrat.io/docs/api/en/groups/attach-tag-to-group /api/en/radius.yaml post /radius/groups/{id}/tags/{tagId} # Create Group Source: https://altostrat.io/docs/api/en/groups/create-group /api/en/radius.yaml post /radius/groups # Delete Group Source: https://altostrat.io/docs/api/en/groups/delete-group /api/en/radius.yaml delete /radius/groups/{id} # Detach Tag from Group Source: https://altostrat.io/docs/api/en/groups/detach-tag-from-group /api/en/radius.yaml delete /radius/groups/{id}/tags/{tagId} # List Accounts in Group Source: https://altostrat.io/docs/api/en/groups/list-accounts-in-group /api/en/radius.yaml get /radius/groups/{id}/accounts # List Groups Source: https://altostrat.io/docs/api/en/groups/list-groups /api/en/radius.yaml get /radius/groups # Retrieve Group Source: https://altostrat.io/docs/api/en/groups/retrieve-group /api/en/radius.yaml get /radius/groups/{id} # Update Group Source: https://altostrat.io/docs/api/en/groups/update-group /api/en/radius.yaml patch /radius/groups/{id} # List Router Interfaces Source: https://altostrat.io/docs/api/en/helper-endpoints/list-router-interfaces /api/en/wan-failover.yaml get /wan/{site_id}/tunnel/interfaces Retrieves a list of available physical and logical network interfaces from the router at the specified site. This is useful for identifying the correct `interface` name when configuring a tunnel. # List Router Interfaces for Failover Source: https://altostrat.io/docs/api/en/helper-endpoints/list-router-interfaces-for-failover /api/en/wan-failover.yaml get /failover/{site_id}/interfaces Retrieves available physical and logical interfaces from the router at the specified site for WAN failover configuration. # Look up Eligible Gateways Source: https://altostrat.io/docs/api/en/helper-endpoints/look-up-eligible-gateways /api/en/wan-failover.yaml post /wan/{site_id}/tunnel/gateways For a given router interface, this endpoint attempts to detect eligible upstream gateway IP addresses. This helps automate the process of finding the correct `gateway` IP for a tunnel configuration. # Look up Eligible Gateways for Failover Source: https://altostrat.io/docs/api/en/helper-endpoints/look-up-eligible-gateways-for-failover /api/en/wan-failover.yaml post /failover/{site_id}/gateways Detects eligible upstream gateway IP addresses for a router interface used in WAN failover configuration. # Active Sessions Count Source: https://altostrat.io/docs/api/en/insights/active-sessions-count /api/en/radius.yaml get /radius/insights/active-sessions # Auth Events History Source: https://altostrat.io/docs/api/en/insights/auth-events-history /api/en/radius.yaml get /radius/insights/authentication-events-over-time # Authentication Latency Source: https://altostrat.io/docs/api/en/insights/authentication-latency /api/en/radius.yaml get /radius/insights/authentication-latency # Authentication Outliers Source: https://altostrat.io/docs/api/en/insights/authentication-outliers /api/en/radius.yaml get /radius/insights/authentication-outliers # Disconnection Stats Source: https://altostrat.io/docs/api/en/insights/disconnection-stats /api/en/radius.yaml get /radius/insights/disconnection-stats # Frequent Disconnects Source: https://altostrat.io/docs/api/en/insights/frequent-disconnects /api/en/radius.yaml get /radius/insights/frequently-disconnected-users # Misconfigured NAS Source: https://altostrat.io/docs/api/en/insights/misconfigured-nas /api/en/radius.yaml get /radius/insights/misconfigured-nas # Most Active NAS Source: https://altostrat.io/docs/api/en/insights/most-active-nas /api/en/radius.yaml get /radius/insights/most-active-nas # NAS Disconnect Reasons Source: https://altostrat.io/docs/api/en/insights/nas-disconnect-reasons /api/en/radius.yaml get /radius/insights/nas-disconnect-summary # Network Health Snapshot Source: https://altostrat.io/docs/api/en/insights/network-health-snapshot /api/en/radius.yaml get /radius/insights/network-health-snapshot # Peak Concurrency Source: https://altostrat.io/docs/api/en/insights/peak-concurrency /api/en/radius.yaml get /radius/insights/peak-concurrency-over-time # Session Duration History Source: https://altostrat.io/docs/api/en/insights/session-duration-history /api/en/radius.yaml get /radius/insights/session-duration-over-time # Session Termination History Source: https://altostrat.io/docs/api/en/insights/session-termination-history /api/en/radius.yaml get /radius/insights/session-terminations-over-time # Short Lived Sessions Source: https://altostrat.io/docs/api/en/insights/short-lived-sessions /api/en/radius.yaml get /radius/insights/short-lived-sessions # Simultaneous Use Violations Source: https://altostrat.io/docs/api/en/insights/simultaneous-use-violations /api/en/radius.yaml get /radius/insights/simultaneous-use-violations # Top Talkers Source: https://altostrat.io/docs/api/en/insights/top-talkers /api/en/radius.yaml get /radius/insights/top-talkers # Create a VPN instance Source: https://altostrat.io/docs/api/en/instances/create-a-vpn-instance /api/en/managed-vpn.yaml post /vpn/instances Provisions a new VPN server instance in a specified region with a unique hostname. This is the first step in setting up a new VPN. # Delete a VPN instance Source: https://altostrat.io/docs/api/en/instances/delete-a-vpn-instance /api/en/managed-vpn.yaml delete /vpn/instances/{instanceId} Permanently decommissions a VPN instance and all its associated servers and peers. This action cannot be undone. # List all VPN instances Source: https://altostrat.io/docs/api/en/instances/list-all-vpn-instances /api/en/managed-vpn.yaml get /vpn/instances Retrieves a list of all VPN instances accessible by the authenticated user. # Retrieve a VPN instance Source: https://altostrat.io/docs/api/en/instances/retrieve-a-vpn-instance /api/en/managed-vpn.yaml get /vpn/instances/{instanceId} Fetches the details of a specific VPN instance by its unique identifier. # Retrieve instance bandwidth Source: https://altostrat.io/docs/api/en/instances/retrieve-instance-bandwidth /api/en/managed-vpn.yaml get /vpn/instances/{instanceId}/bandwidth Fetches the bandwidth usage statistics for the primary server associated with a VPN instance. # Update a VPN instance Source: https://altostrat.io/docs/api/en/instances/update-a-vpn-instance /api/en/managed-vpn.yaml put /vpn/instances/{instanceId} Modifies the configuration of an existing VPN instance, such as its name, DNS settings, or pushed routes. # API Reference Source: https://altostrat.io/docs/api/en/introduction Find generated OpenAPI reference material for public Altostrat SDX endpoints. The API Reference tab contains generated endpoint documentation for teams that automate SDX outside the portal. The public base URL is: ```text theme={null} https://v1.api.altostrat.io ``` Use the product documentation first when you are learning how SDX features behave. Use the generated API groups when you already know the workflow you want to automate and need endpoint names, request shapes, response fields, and authentication details. ## Before You Build * Use the paths exactly as shown in this reference. Several SDX services are mounted behind gateway prefixes such as `/api`, `/workflows`, `/vpn`, `/content`, `/metrics`, `/reports`, and `/scripts`. * Confirm the portal workflow manually before automating it. * Use API keys only for integrations that need server-to-server access. * Store credentials in a secret manager or the SDX vault where appropriate. * Prefer the narrowest role and team access that lets the integration do its job. * Test automation in a non-critical team or site before you run it across production. ## What Is Included This reference focuses on APIs that customers encounter in the portal or use for product automation. Internal service-to-service endpoints, local development endpoints, health checks, and backend-only token exchange routes are intentionally omitted. API keys and workflow vault secrets can grant powerful access. Treat them like production credentials, rotate them when ownership changes, and remove unused keys. # List invoices Source: https://altostrat.io/docs/api/en/invoices/list-invoices /api/en/workspaces.yaml get /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/invoices Returns a list of invoices for a billing account. Invoices are returned in reverse chronological order. # Preview an invoice Source: https://altostrat.io/docs/api/en/invoices/preview-an-invoice /api/en/workspaces.yaml post /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/invoices/preview Previews an upcoming invoice for a billing account, showing the financial impact of potential subscription changes, such as adding products or changing quantities. This does not modify any existing subscriptions. # Cancel a Pending Job Source: https://altostrat.io/docs/api/en/jobs/cancel-a-pending-job /api/en/mikrotik-api.yaml delete /site/{siteId}/job/{jobId} Deletes a job that has not yet started execution. Jobs that are in progress, completed, or failed cannot be deleted. # Create a Job for a Site Source: https://altostrat.io/docs/api/en/jobs/create-a-job-for-a-site /api/en/mikrotik-api.yaml post /site/{siteId}/job Creates and queues a new job to be executed on the specified site. The job's payload is a raw RouterOS script, and metadata is provided via headers. # List Jobs for a Site Source: https://altostrat.io/docs/api/en/jobs/list-jobs-for-a-site /api/en/mikrotik-api.yaml get /site/{siteId}/job Retrieves a list of all jobs that have been created for a specific site, ordered by creation date (most recent first). # Retrieve a Job Source: https://altostrat.io/docs/api/en/jobs/retrieve-a-job /api/en/mikrotik-api.yaml get /site/{siteId}/job/{jobId} Retrieves the complete details of a specific job by its unique identifier (UUID). # List Account Logs Source: https://altostrat.io/docs/api/en/logs/list-account-logs /api/en/radius.yaml get /radius/accounts/{id}/logs # List NAS Logs Source: https://altostrat.io/docs/api/en/logs/list-nas-logs /api/en/radius.yaml get /radius/nas/{id}/logs # Create a metadata object Source: https://altostrat.io/docs/api/en/metadata/create-a-metadata-object /api/en/metadata.yaml post /metadata Creates a new metadata object for a given resource, or fully overwrites an existing one for that resource. The metadata itself is a flexible key-value store. # Delete a metadata object Source: https://altostrat.io/docs/api/en/metadata/delete-a-metadata-object /api/en/metadata.yaml delete /metadata/{resourceId} Deletes all custom metadata associated with a resource. This action clears the `metadata` field but does not delete the resource itself. # List all metadata objects Source: https://altostrat.io/docs/api/en/metadata/list-all-metadata-objects /api/en/metadata.yaml get /metadata Retrieves a collection of all resources that have metadata associated with them for the current customer. # Retrieve a metadata object Source: https://altostrat.io/docs/api/en/metadata/retrieve-a-metadata-object /api/en/metadata.yaml get /metadata/{resourceId} Fetches the metadata object for a single resource, identified by its unique ID. # Update a metadata object Source: https://altostrat.io/docs/api/en/metadata/update-a-metadata-object /api/en/metadata.yaml put /metadata/{resourceId} Updates the metadata for a specific resource. This operation performs a merge; any keys you provide will be added or will overwrite existing keys, while keys you don't provide will be left untouched. To remove a key, set its value to `null` or an empty string. # Create NAS Device Source: https://altostrat.io/docs/api/en/nas-devices/create-nas-device /api/en/radius.yaml post /radius/nas # Delete NAS Device Source: https://altostrat.io/docs/api/en/nas-devices/delete-nas-device /api/en/radius.yaml delete /radius/nas/{id} # List NAS Devices Source: https://altostrat.io/docs/api/en/nas-devices/list-nas-devices /api/en/radius.yaml get /radius/nas # Retrieve NAS Device Source: https://altostrat.io/docs/api/en/nas-devices/retrieve-nas-device /api/en/radius.yaml get /radius/nas/{id} # Update NAS Device Source: https://altostrat.io/docs/api/en/nas-devices/update-nas-device /api/en/radius.yaml patch /radius/nas/{id} # Get BGP Security Report Source: https://altostrat.io/docs/api/en/network-logs/get-bgp-security-report /api/en/monitoring-metrics.yaml get /metrics/bgp-report/{siteId} Generates a BGP security report for a site based on the last 24 hours of data. The report includes top 10 destination ports, top 10 blocklists triggered, and top 10 source IPs initiating blocked traffic. # Get DNS Security Report Source: https://altostrat.io/docs/api/en/network-logs/get-dns-security-report /api/en/monitoring-metrics.yaml get /metrics/dns-report/{siteId} Generates a DNS security report for a site based on the last 24 hours of data. The report includes top 10 blocked categories, top 10 blocked applications, and top 10 internal source IPs making blocked requests. # Get Site Syslog Entries Source: https://altostrat.io/docs/api/en/network-logs/get-site-syslog-entries /api/en/monitoring-metrics.yaml get /metrics/syslogs/{siteId} Retrieves a paginated list of syslog messages for a specific site, ordered by the most recent first. # Create a Notification Group Source: https://altostrat.io/docs/api/en/notification-groups/create-a-notification-group /api/en/notifications.yaml post /notifications Creates a new notification group. This allows you to define a new rule for who gets notified about which topics, for which sites, and on what schedule. # Delete a Notification Group Source: https://altostrat.io/docs/api/en/notification-groups/delete-a-notification-group /api/en/notifications.yaml delete /notifications/{groupId} Permanently deletes a notification group. This action cannot be undone. # List Notification Groups Source: https://altostrat.io/docs/api/en/notification-groups/list-notification-groups /api/en/notifications.yaml get /notifications Retrieves a list of all notification groups configured for the authenticated user's workspace. Each group represents a specific set of rules for routing alerts. # Retrieve a Notification Group Source: https://altostrat.io/docs/api/en/notification-groups/retrieve-a-notification-group /api/en/notifications.yaml get /notifications/{groupId} Fetches the details of a specific notification group by its unique ID. # Update a Notification Group Source: https://altostrat.io/docs/api/en/notification-groups/update-a-notification-group /api/en/notifications.yaml put /notifications/{groupId} Updates the configuration of an existing notification group. This operation replaces the entire group object with the provided data. # Exchange Code or Refresh Token for Tokens Source: https://altostrat.io/docs/api/en/oauth-20-&-oidc/exchange-code-or-refresh-token-for-tokens /api/en/authentication.yaml post /oauth/token Used to exchange an `authorization_code` for tokens, or to use a `refresh_token` to get a new `access_token`. Client authentication can be performed via `client_secret_post` (in the body), `client_secret_basic` (HTTP Basic Auth), or `private_key_jwt`. # Get User Profile Source: https://altostrat.io/docs/api/en/oauth-20-&-oidc/get-user-profile /api/en/authentication.yaml get /userinfo Retrieves the profile of the user associated with the provided `access_token`. The claims returned are based on the scopes granted during authentication. # Initiate User Authentication Source: https://altostrat.io/docs/api/en/oauth-20-&-oidc/initiate-user-authentication /api/en/authentication.yaml get /authorize This is the starting point for user authentication. The Altostrat web application redirects the user's browser to this endpoint to begin the OAuth 2.0 Authorization Code Flow with PKCE. # Log Out User (Legacy) Source: https://altostrat.io/docs/api/en/oauth-20-&-oidc/log-out-user-legacy /api/en/authentication.yaml get /v2/logout Logs the user out of their Altostrat session and redirects them back to a specified URL. # Log Out User (OIDC Compliant) Source: https://altostrat.io/docs/api/en/oauth-20-&-oidc/log-out-user-oidc-compliant /api/en/authentication.yaml get /oidc/logout This endpoint conforms to the OIDC Session Management specification. It logs the user out and can redirect them back to the application. # Revoke Token Source: https://altostrat.io/docs/api/en/oauth-20-&-oidc/revoke-token /api/en/authentication.yaml post /oauth/revoke Revokes an `access_token` or `refresh_token`, invalidating it immediately. This is useful for scenarios like password changes or user-initiated logouts from all devices. # Create a child organization Source: https://altostrat.io/docs/api/en/organizations/create-a-child-organization /api/en/workspaces.yaml post /workspaces/{workspaceId}/organizations/{organizationId}/children Creates a new organization as a direct child of the specified parent organization. The hierarchy cannot exceed 10 levels of depth, and a parent cannot have more than 100 direct children. # Create an organization Source: https://altostrat.io/docs/api/en/organizations/create-an-organization /api/en/workspaces.yaml post /workspaces/{workspaceId}/organizations Creates a new top-level organization within a workspace. To create a child organization, use the `/organizations/{organizationId}/children` endpoint. A workspace cannot have more than 1,000 organizations in total. # Delete an organization Source: https://altostrat.io/docs/api/en/organizations/delete-an-organization /api/en/workspaces.yaml delete /workspaces/{workspaceId}/organizations/{organizationId} Permanently deletes an organization. An organization cannot be deleted if it or any of its descendants have active resource usage. # Export organization usage as CSV Source: https://altostrat.io/docs/api/en/organizations/export-organization-usage-as-csv /api/en/workspaces.yaml get /workspaces/{workspaceId}/organizations/usage.csv Generates and downloads a CSV file detailing the resource usage and limits for all organizations within the specified workspace. # Export organization usage as PDF Source: https://altostrat.io/docs/api/en/organizations/export-organization-usage-as-pdf /api/en/workspaces.yaml get /workspaces/{workspaceId}/organizations/usage.pdf Generates and downloads a PDF file detailing the resource usage and limits for all organizations within the specified workspace. # List all descendant organizations Source: https://altostrat.io/docs/api/en/organizations/list-all-descendant-organizations /api/en/workspaces.yaml get /workspaces/{workspaceId}/organizations/{organizationId}/descendants Returns a flat list of all organizations that are descendants (children, grandchildren, etc.) of the specified parent organization. # List child organizations Source: https://altostrat.io/docs/api/en/organizations/list-child-organizations /api/en/workspaces.yaml get /workspaces/{workspaceId}/organizations/{organizationId}/children Returns a list of immediate child organizations of a specified parent organization. # List organizations Source: https://altostrat.io/docs/api/en/organizations/list-organizations /api/en/workspaces.yaml get /workspaces/{workspaceId}/organizations Returns a list of all organizations within the specified workspace. # Retrieve an organization Source: https://altostrat.io/docs/api/en/organizations/retrieve-an-organization /api/en/workspaces.yaml get /workspaces/{workspaceId}/organizations/{organizationId} Retrieves the details of a specific organization within a workspace. # Retrieve organization limits Source: https://altostrat.io/docs/api/en/organizations/retrieve-organization-limits /api/en/workspaces.yaml get /workspaces/{workspaceId}/organizations/{organizationId}/limits Retrieves a detailed breakdown of usage, limits, and available capacity for each meterable product type for a specific organization. This takes into account the organization's own limits, limits inherited from its parents, and the total capacity available from its subscription. # Retrieve parent organization Source: https://altostrat.io/docs/api/en/organizations/retrieve-parent-organization /api/en/workspaces.yaml get /workspaces/{workspaceId}/organizations/{organizationId}/parent Retrieves the parent organization of a specified child organization. If the organization is at the top level, this endpoint will return a 204 No Content response. # Update an organization Source: https://altostrat.io/docs/api/en/organizations/update-an-organization /api/en/workspaces.yaml patch /workspaces/{workspaceId}/organizations/{organizationId} Updates specified attributes of an organization. This endpoint can be used to change the organization's name, update its resource limits, or modify branding settings. You only need to provide the fields you want to change. # Create a Setup Intent Source: https://altostrat.io/docs/api/en/payment-methods/create-a-setup-intent /api/en/workspaces.yaml post /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/payment-methods Creates a Stripe Setup Intent to collect payment method details for future payments. This returns a `client_secret` that you can use with Stripe.js or the mobile SDKs to display a payment form. A billing account cannot have more than 5 payment methods. # Detach a payment method Source: https://altostrat.io/docs/api/en/payment-methods/detach-a-payment-method /api/en/workspaces.yaml delete /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/payment-methods/{paymentMethodId} Detaches a payment method from a billing account. You cannot detach the only payment method on an account, nor can you detach the default payment method if there are active subscriptions. # List payment methods Source: https://altostrat.io/docs/api/en/payment-methods/list-payment-methods /api/en/workspaces.yaml get /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/payment-methods Returns a list of payment methods attached to a billing account. # Set default payment method Source: https://altostrat.io/docs/api/en/payment-methods/set-default-payment-method /api/en/workspaces.yaml put /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/payment-methods/{paymentMethodId} Sets a specified payment method as the default for a billing account. This payment method will be used for all future subscription invoices. # Create a peer Source: https://altostrat.io/docs/api/en/peers/create-a-peer /api/en/managed-vpn.yaml post /vpn/instances/{instanceId}/peers Creates a new peer (a client or a site) and associates it with a VPN instance. # Delete a peer Source: https://altostrat.io/docs/api/en/peers/delete-a-peer /api/en/managed-vpn.yaml delete /vpn/instances/{instanceId}/peers/{peerId} Permanently removes a peer from a VPN instance. This revokes its access. # List all peers for an instance Source: https://altostrat.io/docs/api/en/peers/list-all-peers-for-an-instance /api/en/managed-vpn.yaml get /vpn/instances/{instanceId}/peers Retrieves a list of all peers (clients and sites) associated with a specific VPN instance. # Retrieve a peer Source: https://altostrat.io/docs/api/en/peers/retrieve-a-peer /api/en/managed-vpn.yaml get /vpn/instances/{instanceId}/peers/{peerId} Fetches the details of a specific peer by its unique identifier. # Update a peer Source: https://altostrat.io/docs/api/en/peers/update-a-peer /api/en/managed-vpn.yaml put /vpn/instances/{instanceId}/peers/{peerId} Modifies the configuration of an existing peer, such as its subnets or routing behavior. # Get Workspace Statistics Source: https://altostrat.io/docs/api/en/platform/get-workspace-statistics /api/en/radius.yaml get /radius/ # List Available RADIUS Attributes Source: https://altostrat.io/docs/api/en/platform/list-available-radius-attributes /api/en/radius.yaml get /radius/attributes # Create a policy Source: https://altostrat.io/docs/api/en/policies/create-a-policy /api/en/control-plane.yaml post /control-plane/policies Creates a new security policy. You can define rules for services like Winbox, SSH, and HTTP/S, including which networks are allowed to access them. # Delete a policy Source: https://altostrat.io/docs/api/en/policies/delete-a-policy /api/en/control-plane.yaml delete /control-plane/policies/{policyId} Deletes a policy. You cannot delete the default policy. Any sites using the deleted policy will be reassigned to the default policy. # List all policies Source: https://altostrat.io/docs/api/en/policies/list-all-policies /api/en/control-plane.yaml get /control-plane/policies Retrieves a list of all security policies belonging to your workspace. Policies define the firewall rules and service access configurations applied to your sites. # Retrieve a policy Source: https://altostrat.io/docs/api/en/policies/retrieve-a-policy /api/en/control-plane.yaml get /control-plane/policies/{policyId} Retrieves the details of a specific policy, including its rules and a list of sites it is applied to. # Update a policy Source: https://altostrat.io/docs/api/en/policies/update-a-policy /api/en/control-plane.yaml put /control-plane/policies/{policyId} Updates the specified policy by setting the values of the parameters passed. Any parameters not provided will be left unchanged. # Create a prefix list Source: https://altostrat.io/docs/api/en/prefix-lists/create-a-prefix-list /api/en/security-groups.yaml post /vpc/prefix-lists Creates a new prefix list with a defined set of CIDR blocks and initial site associations. Site associations and address list deployments are handled asynchronously. # Delete a prefix list Source: https://altostrat.io/docs/api/en/prefix-lists/delete-a-prefix-list /api/en/security-groups.yaml delete /vpc/prefix-lists/{prefixListId} Permanently deletes a prefix list. This action will fail if the prefix list is currently referenced by any security group rule. An asynchronous process will remove the corresponding address list from all associated sites. # List prefix lists Source: https://altostrat.io/docs/api/en/prefix-lists/list-prefix-lists /api/en/security-groups.yaml get /vpc/prefix-lists Retrieves a list of all prefix lists within your organization. This endpoint provides a summary view and does not include the detailed list of prefixes or sites for performance. To get full details, retrieve a specific prefix list by its ID. # Retrieve a prefix list Source: https://altostrat.io/docs/api/en/prefix-lists/retrieve-a-prefix-list /api/en/security-groups.yaml get /vpc/prefix-lists/{prefixListId} Retrieves the complete details of a specific prefix list, including its name, description, status, associated sites, and a full list of its prefixes. # Update a prefix list Source: https://altostrat.io/docs/api/en/prefix-lists/update-a-prefix-list /api/en/security-groups.yaml put /vpc/prefix-lists/{prefixListId} Updates an existing prefix list by fully replacing its attributes, including its name, description, prefixes, and site associations. This is a full replacement operation (PUT); any omitted fields will result in those items being removed. # List Products Source: https://altostrat.io/docs/api/en/products/list-products /api/en/mikrotik-oem-data.yaml get /oem/products Returns a paginated list of MikroTik products. The list can be filtered by product name or model number, allowing for powerful search and cataloging capabilities. # Retrieve a Product Source: https://altostrat.io/docs/api/en/products/retrieve-a-product /api/en/mikrotik-oem-data.yaml get /oem/product/{slug} Retrieves the complete details of a single MikroTik product, identified by its unique slug. This endpoint provides an exhaustive set of specifications, including core hardware details, performance test results, included accessories, and downloadable assets. # Execute a Prometheus query Source: https://altostrat.io/docs/api/en/prometheus-querying/execute-a-prometheus-query /api/en/monitoring-metrics.yaml post /metrics/query Executes a Prometheus query through the SDX metrics gateway and scopes the result to the authenticated workspace and organization. # List label values Source: https://altostrat.io/docs/api/en/prometheus-querying/list-label-values /api/en/monitoring-metrics.yaml get /metrics/labels/{labelName}/values Returns Prometheus values for a label available to the authenticated workspace and organization. # List metric labels Source: https://altostrat.io/docs/api/en/prometheus-querying/list-metric-labels /api/en/monitoring-metrics.yaml get /metrics/labels Returns Prometheus label names available to the authenticated workspace and organization for the requested time window. # List metric names Source: https://altostrat.io/docs/api/en/prometheus-querying/list-metric-names /api/en/monitoring-metrics.yaml get /metrics/metrics Returns metric names available to the authenticated workspace and organization for the requested time window. # Retrieve coupons from a signed URL Source: https://altostrat.io/docs/api/en/public-coupon-urls/retrieve-coupons-from-a-signed-url /api/en/captive-portal.yaml get /captive/coupons Returns valid coupons for a coupon schedule when called with the signed query string generated by `GET /captive/instances/{instanceId}/coupon-schedules/{scheduleId}/generate_url`. # Get public branding information Source: https://altostrat.io/docs/api/en/public/get-public-branding-information /api/en/workspaces.yaml get /organizations/{id}/branding Retrieves the public branding information for an organization, such as its display name, logo, and theme colors. You can use either the organization's primary ID (`org_...`) or its external UUID as the identifier. This is a public, unauthenticated endpoint. # Resolve login hint Source: https://altostrat.io/docs/api/en/public/resolve-login-hint /api/en/workspaces.yaml get /organizations/resolve/{login_hint} Given a unique login hint (e.g., a short company name like 'acme'), this endpoint returns the corresponding organization ID. This is useful for pre-filling organization details in a login flow. This is a public, unauthenticated endpoint. # Create Realm Source: https://altostrat.io/docs/api/en/realms/create-realm /api/en/radius.yaml post /radius/realms # Delete Realm Source: https://altostrat.io/docs/api/en/realms/delete-realm /api/en/radius.yaml delete /radius/realms/{id} # Get Realm Source: https://altostrat.io/docs/api/en/realms/get-realm /api/en/radius.yaml get /radius/realms/{id} # List Realms Source: https://altostrat.io/docs/api/en/realms/list-realms /api/en/radius.yaml get /radius/realms # Update Realm Source: https://altostrat.io/docs/api/en/realms/update-realm /api/en/radius.yaml patch /radius/realms/{id} # List common services Source: https://altostrat.io/docs/api/en/reference-data/list-common-services /api/en/security-groups.yaml get /vpc/reference/services Retrieves a list of common network services and their standard port numbers to aid in the creation of firewall rules. # List supported protocols Source: https://altostrat.io/docs/api/en/reference-data/list-supported-protocols /api/en/security-groups.yaml get /vpc/reference/protocols Retrieves a list of all supported network protocols and their corresponding integer values, which are required when creating firewall rules. # List Resellers Source: https://altostrat.io/docs/api/en/resellers/list-resellers /api/en/mikrotik-oem-data.yaml get /oem/mikrotik-resellers Returns a paginated list of official MikroTik resellers. This allows you to find resellers based on their geographical location or name, providing valuable information for procurement and partnership purposes. # Retrieve a Runbook Source: https://altostrat.io/docs/api/en/runbooks/retrieve-a-runbook /api/en/mikrotik-api.yaml get /runbooks/{runbookId} Retrieves the details of a specific runbook, including its name and the bootstrap command used to onboard new devices with this configuration. # Start a Scan Source: https://altostrat.io/docs/api/en/scan-execution/start-a-scan /api/en/cve-scans.yaml post /scans/cve/scheduled/{scanScheduleId}/invoke Manually triggers a scan for a given schedule, overriding its normal timetable. The scan will be queued for execution immediately. # Start On-Demand Multi-IP Scan Source: https://altostrat.io/docs/api/en/scan-execution/start-on-demand-multi-ip-scan /api/en/cve-scans.yaml post /scans/cve/scan/multiple-ips Initiates an immediate, on-demand scan for a specific list of IP addresses. This uses the configuration of an existing scan schedule but targets only the specified IPs within a particular site. # Start On-Demand Single-IP Scan Source: https://altostrat.io/docs/api/en/scan-execution/start-on-demand-single-ip-scan /api/en/cve-scans.yaml post /scans/cve/scheduled/single-ip Initiates an immediate, on-demand scan for a single IP address. This uses the configuration of an existing scan schedule but targets only the specified IP within a particular site. # Stop a Scan Source: https://altostrat.io/docs/api/en/scan-execution/stop-a-scan /api/en/cve-scans.yaml delete /scans/cve/scheduled/{scanScheduleId}/invoke Forcefully stops a scan that is currently in progress for a given schedule. # Get Latest Scan Status Source: https://altostrat.io/docs/api/en/scan-results/get-latest-scan-status /api/en/cve-scans.yaml get /scans/cve/{scanScheduleId}/status Retrieves the status of the most recent scan associated with a specific schedule, whether it is running, completed, or failed. # List Scan Reports Source: https://altostrat.io/docs/api/en/scan-results/list-scan-reports /api/en/cve-scans.yaml get /scans/cve Retrieves a list of completed scan reports for your account, ordered by the most recent first. Each item in the list is a summary of a scan run. # Retrieve a Scan Report Source: https://altostrat.io/docs/api/en/scan-results/retrieve-a-scan-report /api/en/cve-scans.yaml get /scans/cve/{scan_id} Fetches the detailed report for a specific completed scan run. The report includes scan metadata and links to download the full JSON or PDF report. # Create Scan Schedule Source: https://altostrat.io/docs/api/en/scan-schedules/create-scan-schedule /api/en/cve-scans.yaml post /scans/cve/scheduled Creates a new recurring CVE scan schedule. You must define the timing, frequency, target sites and subnets, and notification settings. A successful creation returns the full schedule object. # Delete a Scan Schedule Source: https://altostrat.io/docs/api/en/scan-schedules/delete-a-scan-schedule /api/en/cve-scans.yaml delete /scans/cve/scheduled/{scanScheduleId} Permanently deletes a scan schedule. This action cannot be undone and will stop any future scans for this schedule. # List Scan Schedules Source: https://altostrat.io/docs/api/en/scan-schedules/list-scan-schedules /api/en/cve-scans.yaml get /scans/cve/scheduled Retrieves a list of all CVE scan schedules configured for your account. This is useful for displaying all configured scans in a dashboard or for programmatic management. # Retrieve a Scan Schedule Source: https://altostrat.io/docs/api/en/scan-schedules/retrieve-a-scan-schedule /api/en/cve-scans.yaml get /scans/cve/scheduled/{scanScheduleId} Fetches the details of a specific scan schedule by its unique identifier. # Update a Scan Schedule Source: https://altostrat.io/docs/api/en/scan-schedules/update-a-scan-schedule /api/en/cve-scans.yaml put /scans/cve/scheduled/{scanScheduleId} Updates the configuration of an existing scan schedule. All fields are replaced by the new values provided in the request body. # Cancel or Delete a Scheduled Script Source: https://altostrat.io/docs/api/en/scheduled-scripts/cancel-or-delete-a-scheduled-script /api/en/scripts.yaml delete /scripts/scheduled/{scheduledScriptId} This endpoint has dual functionality. If the script is 'unauthorized' and has not been launched, it will be permanently deleted. If the script is 'scheduled' or 'launched', it will be marked as 'cancelled' to prevent further execution, but the record will be retained. # Get Execution Progress Source: https://altostrat.io/docs/api/en/scheduled-scripts/get-execution-progress /api/en/scripts.yaml get /scripts/scheduled/{scheduledScriptId}/progress Retrieves the real-time execution progress for a script that has been launched. It provides lists of sites where the script has completed, failed, or is still pending. # Immediately Run a Scheduled Script Source: https://altostrat.io/docs/api/en/scheduled-scripts/immediately-run-a-scheduled-script /api/en/scripts.yaml put /scripts/scheduled/{scheduledScriptId}/run Triggers an immediate execution of an already authorized script, overriding its scheduled 'launch_at' time. This is useful for urgent deployments. The script must be in an 'authorized' state to be run immediately. # List Scheduled Scripts Source: https://altostrat.io/docs/api/en/scheduled-scripts/list-scheduled-scripts /api/en/scripts.yaml get /scripts/scheduled Retrieves a list of all scripts scheduled for execution that are accessible by the authenticated user. This provides an overview of pending, in-progress, and completed automation tasks. # Request Script Authorization Source: https://altostrat.io/docs/api/en/scheduled-scripts/request-script-authorization /api/en/scripts.yaml get /scripts/scheduled/{scheduledScriptId}/authorize Initiates the authorization workflow for an 'unauthorized' script. This action sends notifications (e.g., WhatsApp, email) to the configured recipients, containing a unique link to approve the script's execution. # Retrieve a Scheduled Script Source: https://altostrat.io/docs/api/en/scheduled-scripts/retrieve-a-scheduled-script /api/en/scripts.yaml get /scripts/scheduled/{scheduledScriptId} Fetches the detailed information for a single scheduled script, including its current status, progress, and configuration. # Run a Test Execution Source: https://altostrat.io/docs/api/en/scheduled-scripts/run-a-test-execution /api/en/scripts.yaml put /scripts/scheduled/{scheduledScriptId}/run-test Immediately dispatches the script for execution on the designated 'test_site_id'. This allows for validation of the script's logic and impact in a controlled environment before a full-scale launch. The script does not need to be authorized to run a test. # Schedule a New Script Source: https://altostrat.io/docs/api/en/scheduled-scripts/schedule-a-new-script /api/en/scripts.yaml post /scripts/scheduled Creates a new scheduled script entry. This involves defining the script content, selecting target devices (sites), specifying a launch time, and configuring notification recipients. The script will be in an 'unauthorized' state until an authorization workflow is completed. # Update a Scheduled Script Source: https://altostrat.io/docs/api/en/scheduled-scripts/update-a-scheduled-script /api/en/scripts.yaml put /scripts/scheduled/{scheduledScriptId} Modifies an existing scheduled script. This is only possible if the script has not yet been launched. Updating a script will reset its authorization status to 'unauthorized', requiring re-approval before it can be executed. # Create a new schedule Source: https://altostrat.io/docs/api/en/schedules/create-a-new-schedule /api/en/schedules.yaml post /chrono/schedules Creates a new schedule with a defined set of recurring time slots. Upon creation, the schedule's `active` status is automatically calculated based on the current time and the provided slots. # Delete a schedule Source: https://altostrat.io/docs/api/en/schedules/delete-a-schedule /api/en/schedules.yaml delete /chrono/schedules/{scheduleId} Permanently deletes a schedule, including all of its associated time slots and metadata. This action cannot be undone. # List all schedules Source: https://altostrat.io/docs/api/en/schedules/list-all-schedules /api/en/schedules.yaml get /chrono/schedules Retrieves a list of all schedule objects belonging to your workspace. The schedules are returned sorted by creation date, with the most recently created schedules appearing first. # Retrieve a schedule Source: https://altostrat.io/docs/api/en/schedules/retrieve-a-schedule /api/en/schedules.yaml get /chrono/schedules/{scheduleId} Retrieves the details of an existing schedule by its unique identifier. # Update a schedule Source: https://altostrat.io/docs/api/en/schedules/update-a-schedule /api/en/schedules.yaml put /chrono/schedules/{scheduleId} Updates the specified schedule by setting the properties of the request body. Any properties not provided will be left unchanged. When updating `hours`, the entire array is replaced. When updating `metadata`, providing a key with a `null` value will delete that metadata entry. # Create a Script Template Source: https://altostrat.io/docs/api/en/script-templates/create-a-script-template /api/en/scripts.yaml post /scripts/templates Creates a new, private script template for the user's organization. This allows for the storage and reuse of standardized scripts within a team. # Delete a Script Template Source: https://altostrat.io/docs/api/en/script-templates/delete-a-script-template /api/en/scripts.yaml delete /scripts/templates/{templateId} Permanently removes a private script template. This action cannot be undone and is only permitted on templates that the user is authorized to edit. # List Script Templates Source: https://altostrat.io/docs/api/en/script-templates/list-script-templates /api/en/scripts.yaml get /scripts/templates Retrieves a collection of script templates. Templates can be filtered to show public (global), private (organization-specific), or all accessible templates. They can also be searched by name or description. # Retrieve a Script Template Source: https://altostrat.io/docs/api/en/script-templates/retrieve-a-script-template /api/en/scripts.yaml get /scripts/templates/{templateId} Fetches the details of a specific script template, including its content. # Update a Script Template Source: https://altostrat.io/docs/api/en/script-templates/update-a-script-template /api/en/scripts.yaml put /scripts/templates/{templateId} Modifies an existing script template. This action is only permitted on templates that are private to the user's organization and were created by the user. Global templates are read-only. # Create a security group Source: https://altostrat.io/docs/api/en/security-groups/create-a-security-group /api/en/security-groups.yaml post /vpc/security-groups Creates a new security group with a defined set of firewall rules and initial site associations. The group is created atomically. Site associations and rule deployments are handled asynchronously. The response will indicate a `syncing` status if there are sites to update. # Delete a security group Source: https://altostrat.io/docs/api/en/security-groups/delete-a-security-group /api/en/security-groups.yaml delete /vpc/security-groups/{securityGroupId} Permanently deletes a security group. This action cannot be undone. An asynchronous process will remove the corresponding firewall rules from all associated sites. # List security groups Source: https://altostrat.io/docs/api/en/security-groups/list-security-groups /api/en/security-groups.yaml get /vpc/security-groups Retrieves a list of all security groups within your organization. This endpoint provides a summary view of each group and does not include the detailed list of rules or associated sites for performance reasons. To get full details, retrieve a specific security group by its ID. # Retrieve a security group Source: https://altostrat.io/docs/api/en/security-groups/retrieve-a-security-group /api/en/security-groups.yaml get /vpc/security-groups/{securityGroupId} Retrieves the complete details of a specific security group, including its name, description, status, associated sites, and a full list of its firewall rules. # Update a security group Source: https://altostrat.io/docs/api/en/security-groups/update-a-security-group /api/en/security-groups.yaml put /vpc/security-groups/{securityGroupId} Updates an existing security group by fully replacing its attributes, including its name, description, rules, and site associations. This is a full replacement operation (PUT); any omitted fields in the `rules` or `sites` arrays will result in those items being removed. # Create a site note Source: https://altostrat.io/docs/api/en/site-files/create-a-site-note /api/en/metadata.yaml post /metadata/{siteId}/notes Creates a new markdown note and attaches it to the specified site. # Delete a document file Source: https://altostrat.io/docs/api/en/site-files/delete-a-document-file /api/en/metadata.yaml delete /metadata/{siteId}/documents/{documentId} Permanently deletes a document file from a site. # Delete a media file Source: https://altostrat.io/docs/api/en/site-files/delete-a-media-file /api/en/metadata.yaml delete /metadata/{siteId}/media/{mediaId} Permanently deletes a media file from a site. # Delete a site note Source: https://altostrat.io/docs/api/en/site-files/delete-a-site-note /api/en/metadata.yaml delete /metadata/{siteId}/notes/{noteId} Permanently deletes a note from a site. # Download a document file Source: https://altostrat.io/docs/api/en/site-files/download-a-document-file /api/en/metadata.yaml get /metadata/{siteId}/documents/{documentId} Downloads a specific document file associated with a site. # Download a media file Source: https://altostrat.io/docs/api/en/site-files/download-a-media-file /api/en/metadata.yaml get /metadata/{siteId}/media/{mediaId} Downloads a specific media file associated with a site. # Get document upload URL Source: https://altostrat.io/docs/api/en/site-files/get-document-upload-url /api/en/metadata.yaml post /metadata/{siteId}/documents Requests a pre-signed URL that can be used to upload a document file (e.g., PDF, DOCX) directly to secure storage. You should perform a PUT request to the returned `signed_url` with the file content as the request body. # Get media upload URL Source: https://altostrat.io/docs/api/en/site-files/get-media-upload-url /api/en/metadata.yaml post /metadata/{siteId}/media Requests a pre-signed URL that can be used to upload a media file (e.g., image, video) directly to secure storage. You should perform a PUT request to the returned `signed_url` with the file content as the request body. # Get site note content Source: https://altostrat.io/docs/api/en/site-files/get-site-note-content /api/en/metadata.yaml get /metadata/{siteId}/notes/{noteId} Downloads the raw Markdown content of a specific site note. # List site notes Source: https://altostrat.io/docs/api/en/site-files/list-site-notes /api/en/metadata.yaml get /metadata/{siteId}/notes Retrieves a list of all markdown notes associated with a specific site. # Get Interface Metrics Source: https://altostrat.io/docs/api/en/site-interfaces-&-metrics/get-interface-metrics /api/en/monitoring-metrics.yaml post /metrics/interfaces/{interfaceId}/metrics Fetches time-series traffic metrics (ifInOctets for inbound, ifOutOctets for outbound) for a specific network interface over a given time period. The values are returned as bits per second. # List Site Interfaces Source: https://altostrat.io/docs/api/en/site-interfaces-&-metrics/list-site-interfaces /api/en/monitoring-metrics.yaml get /metrics/interfaces/{siteId} Retrieves a list of all network interfaces monitored via SNMP for a specific site. # Get site note Source: https://altostrat.io/docs/api/en/site-notes/get-site-note /api/en/control-plane.yaml get /control-plane/{siteId}/note Returns the note metadata stored for a managed site. # Update site note Source: https://altostrat.io/docs/api/en/site-notes/update-site-note /api/en/control-plane.yaml post /control-plane/{siteId}/note Creates or replaces the note stored for a managed site. # Get API credentials for a site Source: https://altostrat.io/docs/api/en/site-operations/get-api-credentials-for-a-site /api/en/control-plane.yaml get /control-plane/{siteId}/credentials Retrieves the current API credentials for a site. These credentials are used by the Altostrat platform to manage the device. # Get management server for a site Source: https://altostrat.io/docs/api/en/site-operations/get-management-server-for-a-site /api/en/control-plane.yaml get /control-plane/{siteId}/management-server Retrieves the hostname of the Altostrat management server currently responsible for the site's secure tunnel. This is useful for diagnostics. # Perform an action on a site Source: https://altostrat.io/docs/api/en/site-operations/perform-an-action-on-a-site /api/en/control-plane.yaml post /control-plane/{siteId}/action Sends a command to a site to perform a specific, predefined action. This is used for remote operations like rebooting or clearing firewall rules. Available actions: - `site.upgrade`: Triggers a software upgrade on the device. - `site.clear_firewall`: Clears the device's firewall rules. - `site.reboot`: Reboots the device. - `site.recreate_management_filter`: Re-applies the Altostrat management firewall rules. - `site.recreate_tunnel`: Tears down and rebuilds the secure tunnel to the platform. - `site.resend_api_user`: Pushes the current API user credentials to the device again. # Resend bootstrap scheduler Source: https://altostrat.io/docs/api/en/site-operations/resend-bootstrap-scheduler /api/en/control-plane.yaml post /control-plane/{siteId}/resend-scheduler Re-sends the SDX bootstrap scheduler to a managed router. Use this when the router is reachable but scheduled check-ins need to be repaired. # Rotate API credentials for a site Source: https://altostrat.io/docs/api/en/site-operations/rotate-api-credentials-for-a-site /api/en/control-plane.yaml post /control-plane/{siteId}/credentials Generates new API credentials for the specified site. The old credentials will be invalidated and replaced on the device. # Attach BGP Policy to a Site Source: https://altostrat.io/docs/api/en/site-security-configuration/attach-bgp-policy-to-a-site /api/en/utm-ips.yaml post /content/bgp/{siteId} Attaches a BGP Threat Intelligence policy to a specific site, activating IP reputation blocking for that site. # Attach DNS Policy to a Site Source: https://altostrat.io/docs/api/en/site-security-configuration/attach-dns-policy-to-a-site /api/en/utm-ips.yaml post /content/{siteId} Attaches a DNS Content Filtering policy to a specific site, activating its rules for all traffic from that site. # Detach BGP Policy from a Site Source: https://altostrat.io/docs/api/en/site-security-configuration/detach-bgp-policy-from-a-site /api/en/utm-ips.yaml delete /content/bgp/{siteId} Detaches the currently active BGP Threat Intelligence policy from a specific site, deactivating IP reputation blocking. # Detach DNS Policy from a Site Source: https://altostrat.io/docs/api/en/site-security-configuration/detach-dns-policy-from-a-site /api/en/utm-ips.yaml delete /content/{siteId} Detaches the currently active DNS Content Filtering policy from a specific site, deactivating its rules. # List All Site Security Configurations Source: https://altostrat.io/docs/api/en/site-security-configuration/list-all-site-security-configurations /api/en/utm-ips.yaml get /content/tunnel Retrieves a list of all sites (tunnels) associated with your account and their current security policy attachments. # Retrieve a Site's Security Configuration Source: https://altostrat.io/docs/api/en/site-security-configuration/retrieve-a-sites-security-configuration /api/en/utm-ips.yaml get /content/tunnel/{siteId} Retrieves the current DNS and BGP policy attachments for a specific site. # Delete a Site Source: https://altostrat.io/docs/api/en/sites/delete-a-site /api/en/mikrotik-api.yaml delete /sites/{siteId} Schedules a site for deletion. The device will be sent a command to remove its bootstrap scheduler, and after a grace period, the site record and all associated data will be permanently removed. # List Recent Sites Source: https://altostrat.io/docs/api/en/sites/list-recent-sites /api/en/mikrotik-api.yaml get /sites/recent Returns a list of the 5 most recently accessed sites for the authenticated user, ordered by most recent access. # List Sites Source: https://altostrat.io/docs/api/en/sites/list-sites /api/en/mikrotik-api.yaml get /sites Retrieves a paginated list of all MikroTik sites associated with the authenticated user's workspace. # List Sites (Minimal) Source: https://altostrat.io/docs/api/en/sites/list-sites-minimal /api/en/mikrotik-api.yaml get /sites/minimal Retrieves a condensed list of MikroTik sites, suitable for UI elements like navigation menus where only essential information is needed. # Retrieve a Site Source: https://altostrat.io/docs/api/en/sites/retrieve-a-site /api/en/mikrotik-api.yaml get /sites/{siteId} Retrieves the complete details of a specific MikroTik site by its unique identifier (UUID). # Update a Site Source: https://altostrat.io/docs/api/en/sites/update-a-site /api/en/mikrotik-api.yaml patch /sites/{siteId} Updates the mutable properties of a site, such as its name, location, or timezone. Only the fields provided in the request body will be updated. # Create SLA Report Schedule Source: https://altostrat.io/docs/api/en/sla-report-schedules/create-sla-report-schedule /api/en/reports.yaml post /reports/sla/schedules Creates a new SLA report schedule. This schedule defines a recurring report, including its frequency, site selection criteria, and SLA targets. The `id` for the schedule will be generated by the server. # Delete a Report Schedule Source: https://altostrat.io/docs/api/en/sla-report-schedules/delete-a-report-schedule /api/en/reports.yaml delete /reports/sla/schedules/{scheduleId} Permanently deletes an SLA report schedule. This action cannot be undone. # List SLA Report Schedules Source: https://altostrat.io/docs/api/en/sla-report-schedules/list-sla-report-schedules /api/en/reports.yaml get /reports/sla/schedules Retrieves a list of all configured SLA report schedules for the authenticated customer's workspace. # Retrieve a Report Schedule Source: https://altostrat.io/docs/api/en/sla-report-schedules/retrieve-a-report-schedule /api/en/reports.yaml get /reports/sla/schedules/{scheduleId} Retrieves the details of a single SLA report schedule by its unique ID. # Run a Report On-Demand Source: https://altostrat.io/docs/api/en/sla-report-schedules/run-a-report-on-demand /api/en/reports.yaml post /reports/sla/schedules/{scheduleId}/run Triggers an immediate, on-demand generation of a report for a specified date range. This does not affect the regular schedule. The report generation is asynchronous and the result will appear in the Generated Reports list when complete. # Update a Report Schedule Source: https://altostrat.io/docs/api/en/sla-report-schedules/update-a-report-schedule /api/en/reports.yaml put /reports/sla/schedules/{scheduleId} Updates the configuration of an existing SLA report schedule. # Cancel a subscription Source: https://altostrat.io/docs/api/en/subscriptions/cancel-a-subscription /api/en/workspaces.yaml delete /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/subscriptions/{subscriptionId} Cancels a subscription at the end of the current billing period. This operation cannot be performed if it would leave the workspace or billing account with insufficient capacity for its current resource usage. # Check trial eligibility Source: https://altostrat.io/docs/api/en/subscriptions/check-trial-eligibility /api/en/workspaces.yaml get /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/trial-eligibility Checks if a workspace is eligible for a 14-day free trial. A workspace is eligible if it has only one billing account and no existing subscriptions. # Create a subscription Source: https://altostrat.io/docs/api/en/subscriptions/create-a-subscription /api/en/workspaces.yaml post /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/subscriptions Creates a new Stripe subscription for a billing account. If the workspace is eligible for a trial, a 14-day trial subscription is created without requiring a payment method. Otherwise, a default payment method must be present on the billing account. # List subscriptions Source: https://altostrat.io/docs/api/en/subscriptions/list-subscriptions /api/en/workspaces.yaml get /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/subscriptions Returns a list of subscriptions associated with a billing account. # Retrieve a subscription Source: https://altostrat.io/docs/api/en/subscriptions/retrieve-a-subscription /api/en/workspaces.yaml get /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/subscriptions/{subscriptionId} Retrieves the details of a specific subscription. # Update a subscription Source: https://altostrat.io/docs/api/en/subscriptions/update-a-subscription /api/en/workspaces.yaml patch /workspaces/{workspaceId}/billing-accounts/{billingAccountId}/subscriptions/{subscriptionId} Updates a subscription. This endpoint supports multiple distinct operations. You can change product quantities, add or remove products, update metadata, or perform an action like `pause`, `resume`, or `sync`. Only one type of operation (e.g., `product_quantities`, `add_products`, `action`) is allowed per request. # Apply a tag to a resource Source: https://altostrat.io/docs/api/en/tag-values/apply-a-tag-to-a-resource /api/en/metadata.yaml post /tags/{tagId}/values Applies a tag with a specific value to a resource, identified by its `correlation_id` and `correlation_type`. If a tag with the same value (case-insensitive) already exists for this tag definition, the existing canonical value will be used. # Find resources by tag value Source: https://altostrat.io/docs/api/en/tag-values/find-resources-by-tag-value /api/en/metadata.yaml get /tags/{tagId}/resources Retrieves a list of all resources that have a specific tag applied with a specific value. This is a powerful query for filtering resources based on their classifications. # List tags for a resource Source: https://altostrat.io/docs/api/en/tag-values/list-tags-for-a-resource /api/en/metadata.yaml get /resources/{correlationId}/tags Retrieves all tags that have been applied to a specific resource. # List unique values for a tag Source: https://altostrat.io/docs/api/en/tag-values/list-unique-values-for-a-tag /api/en/metadata.yaml get /tags/{tagId}/values Retrieves a list of unique values that have been applied to resources using a specific tag definition. This is useful for populating dropdowns or autocomplete fields in a UI. # Remove a tag from a resource Source: https://altostrat.io/docs/api/en/tag-values/remove-a-tag-from-a-resource /api/en/metadata.yaml delete /tags/{tagId}/values/{correlationId} Removes a specific tag from a resource. This does not delete the tag definition itself. # Update a tag on a resource Source: https://altostrat.io/docs/api/en/tag-values/update-a-tag-on-a-resource /api/en/metadata.yaml put /tags/{tagId}/values/{correlationId} Updates the value of a tag on a specific resource. This is effectively the same as creating a new tag value, as it will overwrite any existing value for that tag on the resource. # Create a tag definition Source: https://altostrat.io/docs/api/en/tags/create-a-tag-definition /api/en/metadata.yaml post /tags Creates a new tag definition. A tag definition acts as a template or category (e.g., "Site Type", "Priority") that can then be applied to various resources. # Create Tag Source: https://altostrat.io/docs/api/en/tags/create-tag /api/en/radius.yaml post /radius/tags # Delete a tag definition Source: https://altostrat.io/docs/api/en/tags/delete-a-tag-definition /api/en/metadata.yaml delete /tags/{tagId} Permanently deletes a tag definition and all of its associated values from all resources. This action cannot be undone. # Delete Tag Source: https://altostrat.io/docs/api/en/tags/delete-tag /api/en/radius.yaml delete /radius/tags/{id} # Get Tag Source: https://altostrat.io/docs/api/en/tags/get-tag /api/en/radius.yaml get /radius/tags/{id} # List Accounts by Tag Source: https://altostrat.io/docs/api/en/tags/list-accounts-by-tag /api/en/radius.yaml get /radius/tags/{tagId}/accounts # List all tag definitions Source: https://altostrat.io/docs/api/en/tags/list-all-tag-definitions /api/en/metadata.yaml get /tags Retrieves a list of all tag definitions for your workspace. Each tag definition includes its key, color, and a list of all values currently applied to resources. This is useful for understanding the available classification schemes in your environment. # List Containers by Tag Source: https://altostrat.io/docs/api/en/tags/list-containers-by-tag /api/en/radius.yaml get /radius/tags/{tagId}/containers # List Groups by Tag Source: https://altostrat.io/docs/api/en/tags/list-groups-by-tag /api/en/radius.yaml get /radius/tags/{tagId}/groups # List Tags Source: https://altostrat.io/docs/api/en/tags/list-tags /api/en/radius.yaml get /radius/tags # Retrieve a tag definition Source: https://altostrat.io/docs/api/en/tags/retrieve-a-tag-definition /api/en/metadata.yaml get /tags/{tagId} Retrieves the details of a specific tag definition by its unique ID. This includes all the values that have been applied to resources using this tag. # Update a tag definition Source: https://altostrat.io/docs/api/en/tags/update-a-tag-definition /api/en/metadata.yaml put /tags/{tagId} Updates the properties of an existing tag definition, such as its key or color. # Update Tag Source: https://altostrat.io/docs/api/en/tags/update-tag /api/en/radius.yaml patch /radius/tags/{id} # List Available Topics Source: https://altostrat.io/docs/api/en/topics/list-available-topics /api/en/notifications.yaml get /notifications/topics Retrieves a list of all available notification topics. These are the event categories that notification groups can subscribe to. # Create a transient access session Source: https://altostrat.io/docs/api/en/transient-access/create-a-transient-access-session /api/en/control-plane.yaml post /control-plane/{siteId}/transient-accesses Creates a temporary, secure session for accessing a site via Winbox or SSH. The session is automatically revoked after the specified duration. # List transient accesses for a site Source: https://altostrat.io/docs/api/en/transient-access/list-transient-accesses-for-a-site /api/en/control-plane.yaml get /control-plane/{siteId}/transient-accesses Retrieves a list of all active and expired transient access sessions for a specific site. # Retrieve a transient access session Source: https://altostrat.io/docs/api/en/transient-access/retrieve-a-transient-access-session /api/en/control-plane.yaml get /control-plane/{siteId}/transient-accesses/{accessId} Retrieves the details of a single transient access session. # Revoke a transient access session Source: https://altostrat.io/docs/api/en/transient-access/revoke-a-transient-access-session /api/en/control-plane.yaml delete /control-plane/{siteId}/transient-accesses/{accessId} Immediately revokes an active transient access session, terminating the connection and preventing further access. # Create a transient port forward Source: https://altostrat.io/docs/api/en/transient-port-forwarding/create-a-transient-port-forward /api/en/control-plane.yaml post /control-plane/{siteId}/transient-forward Creates a temporary, secure port forwarding rule. This allows you to access a device (e.g., a server or camera) on the LAN behind your MikroTik site from a specific public IP address. # List transient port forwards for a site Source: https://altostrat.io/docs/api/en/transient-port-forwarding/list-transient-port-forwards-for-a-site /api/en/control-plane.yaml get /control-plane/{siteId}/transient-forward Retrieves a list of all active and expired transient port forwarding rules for a specific site. # Retrieve a transient port forward Source: https://altostrat.io/docs/api/en/transient-port-forwarding/retrieve-a-transient-port-forward /api/en/control-plane.yaml get /control-plane/{siteId}/transient-forward/{forwardId} Retrieves the details of a single transient port forwarding rule. # Revoke a transient port forward Source: https://altostrat.io/docs/api/en/transient-port-forwarding/revoke-a-transient-port-forward /api/en/control-plane.yaml delete /control-plane/{siteId}/transient-forward/{forwardId} Immediately revokes an active port forwarding rule, closing the connection. # List available node types Source: https://altostrat.io/docs/api/en/utilities/list-available-node-types /api/en/workflows.yaml get /workflows/node-types Retrieves a list of all available node types (triggers, actions, and conditions) that can be used to build workflows, along with their configuration schemas. # List available server regions Source: https://altostrat.io/docs/api/en/utilities/list-available-server-regions /api/en/managed-vpn.yaml get /vpn/servers/regions Retrieves a structured list of all available geographical regions where a VPN instance can be deployed. # List subnets for a site Source: https://altostrat.io/docs/api/en/utilities/list-subnets-for-a-site /api/en/managed-vpn.yaml get /vpn/site/{siteId}/subnets Retrieves a list of available subnets for a specific site, which is useful when configuring site-to-site peers. # Test a single node Source: https://altostrat.io/docs/api/en/utilities/test-a-single-node /api/en/workflows.yaml post /workflows/test-node Executes a single workflow node in isolation with a provided context. This is a powerful debugging tool to test a node's logic without running an entire workflow. # Create a vault item Source: https://altostrat.io/docs/api/en/vault/create-a-vault-item /api/en/workflows.yaml post /workflows/vault Creates a new item in the vault for storing sensitive information like API keys or passwords. The secret value is encrypted at rest and can only be used by workflows. # Delete a vault item Source: https://altostrat.io/docs/api/en/vault/delete-a-vault-item /api/en/workflows.yaml delete /workflows/vault/{vaultId} Permanently deletes a vault item. This action cannot be undone. Any workflows using this item will fail. # List vault items Source: https://altostrat.io/docs/api/en/vault/list-vault-items /api/en/workflows.yaml get /workflows/vault Retrieves a list of all secret items stored in your organization's vault. The secret values themselves are never returned. # Retrieve a vault item Source: https://altostrat.io/docs/api/en/vault/retrieve-a-vault-item /api/en/workflows.yaml get /workflows/vault/{vaultId} Retrieves the details of a single vault item by its prefixed ID. The secret value is never returned. # Update a vault item Source: https://altostrat.io/docs/api/en/vault/update-a-vault-item /api/en/workflows.yaml put /workflows/vault/{vaultId} Updates an existing vault item, such as its name, secret value, or expiration date. # Get CVEs by MAC Address Source: https://altostrat.io/docs/api/en/vulnerability-intelligence/get-cves-by-mac-address /api/en/cve-scans.yaml post /scans/cve/mac-address/cves Retrieves all discovered vulnerabilities (CVEs) associated with a specific list of MAC addresses across all historical scans. This is the primary endpoint for tracking a device's vulnerability history. Note: This endpoint uses POST to allow for querying multiple MAC addresses in the request body, which is more robust and secure than a lengthy GET URL. # Get Mitigation Steps Source: https://altostrat.io/docs/api/en/vulnerability-intelligence/get-mitigation-steps /api/en/cve-scans.yaml get /scans/cve/mitigation/{cve_id} Provides AI-generated, actionable mitigation steps for a specific CVE identifier. The response is formatted in Markdown for easy rendering. # List All Scanned MAC Addresses Source: https://altostrat.io/docs/api/en/vulnerability-intelligence/list-all-scanned-mac-addresses /api/en/cve-scans.yaml get /scans/cve/mac-address/cve/list Retrieves a list of all unique MAC addresses that have been discovered across all scans for your account. This can be used to populate a device inventory or to discover which devices to query for CVEs. # List CVE Statuses Source: https://altostrat.io/docs/api/en/vulnerability-management/list-cve-statuses /api/en/cve-scans.yaml get /scans/cve/mac-address/cve/status Retrieves a list of all managed CVE statuses. You can filter the results by MAC address, CVE ID, or status to find specific records. # Update CVE Status Source: https://altostrat.io/docs/api/en/vulnerability-management/update-cve-status /api/en/cve-scans.yaml post /scans/cve/mac-address/cve/status Updates the status of a specific CVE for a given MAC address. Use this to mark a vulnerability as 'accepted' (e.g., a false positive or acceptable risk) or 'mitigated' (e.g., a patch has been applied or a workaround is in place). Each update creates a new historical record. # Create a walled garden entry Source: https://altostrat.io/docs/api/en/walled-garden/create-a-walled-garden-entry /api/en/captive-portal.yaml post /captive/walled-garden/{siteId} Adds a new IP address or subnet to the walled garden for a specific site, allowing users to access it before authenticating. # Delete a walled garden entry Source: https://altostrat.io/docs/api/en/walled-garden/delete-a-walled-garden-entry /api/en/captive-portal.yaml delete /captive/walled-garden/{siteId}/{walledGardenEntryId} Removes an entry from the walled garden, blocking pre-authentication access to the specified IP address or subnet. # List walled garden entries for a site Source: https://altostrat.io/docs/api/en/walled-garden/list-walled-garden-entries-for-a-site /api/en/captive-portal.yaml get /captive/walled-garden/{siteId} Retrieves a list of all walled garden entries (allowed pre-authentication destinations) for a specific site. # Retrieve a walled garden entry Source: https://altostrat.io/docs/api/en/walled-garden/retrieve-a-walled-garden-entry /api/en/captive-portal.yaml get /captive/walled-garden/{siteId}/{walledGardenEntryId} Retrieves the details of a specific walled garden entry. # Update a walled garden entry Source: https://altostrat.io/docs/api/en/walled-garden/update-a-walled-garden-entry /api/en/captive-portal.yaml put /captive/walled-garden/{siteId}/{walledGardenEntryId} Updates the details of a walled garden entry, such as its name. The IP address cannot be changed. # Get Aggregated Ping Statistics Source: https://altostrat.io/docs/api/en/wan-tunnels-&-performance/get-aggregated-ping-statistics /api/en/monitoring-metrics.yaml post /metrics/wan/ping-stats Fetches aggregated time-series data for latency, jitter (mdev), and packet loss for one or more WAN tunnels over a specified time period. If no tunnels are specified, it returns an aggregated average across all tunnels. This endpoint is optimized for creating performance charts with a specified number of data points. # Get WAN tunnel ping statistics Source: https://altostrat.io/docs/api/en/wan-tunnels-&-performance/get-wan-tunnel-ping-statistics /api/en/monitoring-metrics.yaml post /metrics/wan-tunnels/{tunnelId}/ping-stats Fetches aggregated time-series data for latency, jitter (mdev), and packet loss for one or more WAN tunnels over a specified time period. If no tunnels are specified, it returns an aggregated average across all tunnels. This endpoint is optimized for creating performance charts with a specified number of data points. # List Site WAN Tunnels Source: https://altostrat.io/docs/api/en/wan-tunnels-&-performance/list-site-wan-tunnels /api/en/monitoring-metrics.yaml get /metrics/wan-tunnels/{siteId} Retrieves a list of all configured SD-WAN tunnels for a specific site. # Add a new WAN Tunnel Source: https://altostrat.io/docs/api/en/wan-tunnels/add-a-new-wan-tunnel /api/en/wan-failover.yaml post /failover/{site_id}/tunnels Creates a new, unconfigured WAN tunnel for the site, up to the maximum allowed by the subscription. After creation, use `PUT /failover/{site_id}/tunnels/{tunnel_id}` to configure properties like interface and gateway. # Add a new WAN Tunnel Source: https://altostrat.io/docs/api/en/wan-tunnels/add-a-new-wan-tunnel-1 /api/en/wan-failover.yaml post /wan/{site_id}/tunnel Creates a new, unconfigured WAN tunnel for the site, up to the maximum allowed by the subscription. After creation, use `PUT /failover/{site_id}/tunnels/{tunnel_id}` to configure properties like interface and gateway. # Configure a WAN Tunnel Source: https://altostrat.io/docs/api/en/wan-tunnels/configure-a-wan-tunnel /api/en/wan-failover.yaml put /failover/{site_id}/tunnels/{tunnel_id} Updates the configuration of a specific WAN tunnel. This is the primary endpoint for defining how a WAN connection operates, including its router interface, gateway, and connection type. # Delete a WAN Tunnel Source: https://altostrat.io/docs/api/en/wan-tunnels/delete-a-wan-tunnel /api/en/wan-failover.yaml delete /failover/{site_id}/tunnels/{tunnel_id} Permanently deletes a WAN tunnel from the failover configuration. The system will automatically re-prioritize the remaining tunnels. # Get a Specific Tunnel Source: https://altostrat.io/docs/api/en/wan-tunnels/get-a-specific-tunnel /api/en/wan-failover.yaml get /failover/{site_id}/tunnels/{tunnel_id} Retrieves the detailed configuration and status of a single WAN tunnel. # List Tunnels for a Site Source: https://altostrat.io/docs/api/en/wan-tunnels/list-tunnels-for-a-site /api/en/wan-failover.yaml get /failover/{site_id}/tunnels Retrieves a detailed list of all WAN tunnels configured for a specific site. # List Tunnels for a Site Source: https://altostrat.io/docs/api/en/wan-tunnels/list-tunnels-for-a-site-1 /api/en/wan-failover.yaml get /wan/{site_id}/tunnel Retrieves a detailed list of all WAN tunnels configured for a specific site. # List WAN tunnels across accessible sites Source: https://altostrat.io/docs/api/en/wan-tunnels/list-wan-tunnels-across-accessible-sites /api/en/wan-failover.yaml get /wan/tunnels Returns WAN tunnels across the sites available to the authenticated user. The portal uses this for live WAN health views. # List WAN tunnels across accessible sites Source: https://altostrat.io/docs/api/en/wan-tunnels/list-wan-tunnels-across-accessible-sites-1 /api/en/wan-failover.yaml get /failover/tunnels Returns WAN tunnels across the sites available to the authenticated user. The portal uses this endpoint for live WAN health views. # Update Tunnel Priorities Source: https://altostrat.io/docs/api/en/wan-tunnels/update-tunnel-priorities /api/en/wan-failover.yaml post /wan/{site_id}/failover/priorities Re-orders the failover priority for all tunnels associated with a site. This is an atomic operation; you must provide a complete list of all tunnels and their desired new priorities. The lowest number represents the highest priority. # Trigger a workflow via webhook Source: https://altostrat.io/docs/api/en/webhooks/trigger-a-workflow-via-webhook /api/en/workflows.yaml post /workflows/webhooks/{webhookToken} A public endpoint to trigger a workflow that has a `webhook_trigger`. Authentication is handled by the unique, secret token in the URL path. The entire request body will be available in the workflow's context. # Get workflow log statistics Source: https://altostrat.io/docs/api/en/workflow-logs/get-workflow-log-statistics /api/en/workflows.yaml get /workflows/{workflowId}/logs/stats Returns aggregate counts for a workflow log stream. # List recent workflow logs Source: https://altostrat.io/docs/api/en/workflow-logs/list-recent-workflow-logs /api/en/workflows.yaml get /workflows/logs/recent Returns recent workflow log entries across workflows available to the authenticated user. # List workflow logs Source: https://altostrat.io/docs/api/en/workflow-logs/list-workflow-logs /api/en/workflows.yaml get /workflows/{workflowId}/logs Returns logs for workflow executions. You can filter by level, node, run, or date range. # Execute a workflow Source: https://altostrat.io/docs/api/en/workflow-runs/execute-a-workflow /api/en/workflows.yaml post /workflows/{workflowId}/execute Manually triggers the execution of a workflow. The workflow will run asynchronously in the background. The response acknowledges that the execution has been accepted and provides the ID of the new workflow run. # List workflow runs Source: https://altostrat.io/docs/api/en/workflow-runs/list-workflow-runs /api/en/workflows.yaml get /workflows/{workflowId}/executions Retrieves a paginated list of all past and current executions (runs) for a specific workflow, ordered by the most recent. # Re-run a workflow Source: https://altostrat.io/docs/api/en/workflow-runs/re-run-a-workflow /api/en/workflows.yaml post /workflows/runs/{runId}/rerun Creates a new workflow run using the same initial trigger payload as a previous run. This is useful for re-trying a failed or completed execution with the original input data. # Resume a failed workflow Source: https://altostrat.io/docs/api/en/workflow-runs/resume-a-failed-workflow /api/en/workflows.yaml post /workflows/runs/{runId}/resume-from/{nodeId} Resumes a failed workflow run from a specific, successfully completed node. A new workflow run is created, inheriting the context from the original run up to the specified node, and execution continues from there. # Retrieve a workflow run Source: https://altostrat.io/docs/api/en/workflow-runs/retrieve-a-workflow-run /api/en/workflows.yaml get /workflows/runs/{runId} Retrieves the details of a single workflow run, including its status, trigger payload, error message (if any), and a complete, ordered log of every step that was executed. # Create a new workflow Source: https://altostrat.io/docs/api/en/workflows/create-a-new-workflow /api/en/workflows.yaml post /workflows Creates a new workflow definition, including its nodes and edges that define the automation graph. A valid workflow must have exactly one trigger node. # Delete a workflow Source: https://altostrat.io/docs/api/en/workflows/delete-a-workflow /api/en/workflows.yaml delete /workflows/{workflowId} Permanently deletes a workflow and all of its associated runs and logs. This action cannot be undone. A workflow cannot be deleted if it is being called by another workflow. # Execute a synchronous workflow Source: https://altostrat.io/docs/api/en/workflows/execute-a-synchronous-workflow /api/en/workflows.yaml post /workflows/sync/{workflowId} Executes a workflow that contains a `sync_request_trigger` and immediately returns the result. The workflow must be designed for synchronous execution, meaning it cannot contain long-running tasks like delays or iterators. The final node must be a `text_transform` node configured as the response. # List all workflows Source: https://altostrat.io/docs/api/en/workflows/list-all-workflows /api/en/workflows.yaml get /workflows Retrieves a list of all workflows belonging to your organization. This endpoint is useful for dashboard displays or for selecting a workflow to execute or edit. # List triggerable workflows Source: https://altostrat.io/docs/api/en/workflows/list-triggerable-workflows /api/en/workflows.yaml get /workflows/triggerable-workflows Returns active workflows that can be triggered by another workflow or selected as a subflow target. # Retrieve a workflow Source: https://altostrat.io/docs/api/en/workflows/retrieve-a-workflow /api/en/workflows.yaml get /workflows/{workflowId} Retrieves the complete details of a single workflow by its prefixed ID, including its full node and edge configuration. # Update a workflow Source: https://altostrat.io/docs/api/en/workflows/update-a-workflow /api/en/workflows.yaml put /workflows/{workflowId} Updates an existing workflow. You can update any property, including the name, description, active status, schedule, or the entire graph of nodes and edges. # Validate a workflow definition Source: https://altostrat.io/docs/api/en/workflows/validate-a-workflow-definition /api/en/workflows.yaml post /workflows/validate Validates a workflow graph before you create or update it. Use this to catch missing triggers, invalid node configuration, and graph errors. # Add a member to a workspace Source: https://altostrat.io/docs/api/en/workspace-members/add-a-member-to-a-workspace /api/en/workspaces.yaml post /workspaces/{workspaceId}/members Adds a new user to a workspace with a specified role. Only workspace owners and admins can add new members. A workspace cannot have more than 100 members. # List workspace members Source: https://altostrat.io/docs/api/en/workspace-members/list-workspace-members /api/en/workspaces.yaml get /workspaces/{workspaceId}/members Returns a list of users who are members of the specified workspace, including their roles. # Remove a member from a workspace Source: https://altostrat.io/docs/api/en/workspace-members/remove-a-member-from-a-workspace /api/en/workspaces.yaml delete /workspaces/{workspaceId}/members/{memberId} Removes a member from a workspace. A user can remove themselves, or an owner/admin can remove other members. The last owner of a workspace cannot be removed. # Update a member's role Source: https://altostrat.io/docs/api/en/workspace-members/update-a-members-role /api/en/workspaces.yaml patch /workspaces/{workspaceId}/members/{memberId} Updates the role of an existing member in a workspace. Role changes are subject to hierarchy rules; for example, an admin cannot promote another member to an owner. # Archive a workspace Source: https://altostrat.io/docs/api/en/workspaces/archive-a-workspace /api/en/workspaces.yaml delete /workspaces/{workspaceId} Archives a workspace, preventing any further modifications. A workspace cannot be archived if it contains organizations with active resource usage or billing accounts with active subscriptions. This is a soft-delete operation. Only workspace owners can perform this action. # Create a workspace Source: https://altostrat.io/docs/api/en/workspaces/create-a-workspace /api/en/workspaces.yaml post /workspaces Creates a new workspace, which acts as a top-level container for your resources, users, and billing configurations. The user creating the workspace is automatically assigned the 'owner' role. # List workspaces Source: https://altostrat.io/docs/api/en/workspaces/list-workspaces /api/en/workspaces.yaml get /workspaces Returns a list of workspaces the authenticated user is a member of. # Retrieve a workspace Source: https://altostrat.io/docs/api/en/workspaces/retrieve-a-workspace /api/en/workspaces.yaml get /workspaces/{workspaceId} Retrieves the details of an existing workspace. You must be a member of the workspace to retrieve it. # Update a workspace Source: https://altostrat.io/docs/api/en/workspaces/update-a-workspace /api/en/workspaces.yaml patch /workspaces/{workspaceId} Updates the specified workspace by setting the values of the parameters passed. Any parameters not provided will be left unchanged. Only workspace owners and admins can perform this action. # Architecture and Scale Source: https://altostrat.io/docs/radius/en/architecture Understand how ArcRadius uses a global RadSec data plane, management control plane, analytics plane, multi-region data stores, deterministic sharding, and streaming imports. ArcRadius is the distributed RADIUS service behind Altostrat Radius. It is built as three separate planes: a data plane for live RADIUS traffic, a control plane for management and configuration, and an analytics plane for accounting, logs, triggers, and insights. This matters operationally because authentication needs to stay fast while the rest of the platform can scale independently for logs, metrics, imports, quota checks, API calls, workflows, and dashboards. ```mermaid theme={null} flowchart LR NAS["NAS device"] -->|"RadSec mTLS"| GA["Global anycast ingress"] GA --> NLB["Regional Network Load Balancer"] NLB --> Proxy["RadSec proxy on ECS"] Proxy -->|"Access-Request"| Core["RADIUS server tasks on ECS"] Core -->|"Internal REST"| API["Region-local API on Lambda"] API -->|"PrivateLink"| Data["DynamoDB Global Tables"] Proxy -->|"Accounting and post-auth events"| Stream["Kinesis stream"] Stream --> Analytics["Timestream analytics"] API --> Logs["Logs and auth outcomes"] Logs --> UI["Live View and dashboards"] UI -->|"Manual disconnect / quota action"| Control["Dynamic authorization sender"] Control -->|"PoD / CoA"| NAS ``` ## Platform Planes | Plane | What it handles | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Data plane | RadSec ingress, TLS termination, NAS identity, Access-Request handling, Accounting-Request handling, and dynamic authorization packet flow. | | Control plane | Web UI, REST API, users, folders, groups, realms, NAS devices, certificates, quotas, metadata, workflows, and configuration changes. | | Analytics plane | Authentication logs, accounting data, usage metrics, accounting triggers, search, dashboards, and insight queries. | ## Request Flow A NAS device starts a RadSec connection to the global service endpoint. Global routing sends the connection to the nearest healthy regional deployment rather than waiting on DNS propagation. The connection reaches a regional Network Load Balancer, which forwards the TCP flow to the RadSec proxy layer running on containerized infrastructure. The RadSec edge uses mutual TLS and validates the NAS certificate against the client CA issued for the workspace. The certificate identifies the workspace, organization, and NAS. The edge rewrites the `NAS-Identifier` to the registered NAS identity, so authorization and logs rely on the trusted certificate identity instead of a mutable packet field. Access requests are handled by horizontally scalable RADIUS server tasks and translated into secure, region-local API calls for policy evaluation, password handling, check attributes, realm logic, quota state, and reply attributes. Accounting and post-authentication data are streamed into the analytics plane so accounting load does not block authentication throughput. Authentication results, accounting usage, session markers, quota state, and admin requests are processed by background workers and metrics pipelines. ## Authentication Behavior The policy service supports common access patterns used by broadband, Wi-Fi, VPN, and network-access devices: * PAP-style password authentication. * CHAP authentication when the NAS sends CHAP attributes. * MS-CHAP and MS-CHAPv2, including NT password material needed by FreeRADIUS. * EAP challenge handling where the upstream RADIUS flow needs to continue the exchange. * MAC-based lookup using Calling-Station-Id or MAC-like usernames. * Optional auto-registration for unknown MAC-based users when the NAS allows it. Access still depends on the user, NAS, customer boundary, account status, realm, check attributes, password, and quota state. A device cannot bypass policy just by sending a different `NAS-Identifier`; RadSec traffic is normalized to the NAS identity from the client certificate. ## Why The Architecture Scales | Layer | Scaling behavior | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Global ingress | Routes RadSec traffic to the nearest healthy regional deployment and can fail over across regions without waiting for DNS changes. | | Network load balancing | Uses high-performance Layer 4 regional load balancing for TCP/RadSec traffic. | | RadSec edge | Uses a concurrent Go runtime with a goroutine per NAS connection and per-client UDP backend handling to avoid contention between devices. | | RADIUS core | Runs as horizontally scalable container tasks so authentication capacity can grow with live traffic. | | Internal API | Uses serverless regional API workers for elastic policy evaluation and management operations. | | Device identity | Uses mTLS certificate validation so the platform can trust which workspace, organization, and NAS produced the traffic. | | Policy lookup | Caches NAS devices, authentication profiles, and group profiles for short windows to reduce repeated database reads during busy authentication periods. | | Data storage | Uses DynamoDB-backed records, global replication, write sharding, sharded counters, and deterministic username sharding for fast lookups and hot-partition protection. | | Logs | Uses sharded log access patterns so recent operational views can page through high-volume NAS logs without loading broad time ranges into memory. | | Analytics | Streams accounting and post-auth events independently of the authentication path, then stores time-series data for dashboards, triggers, and insight queries. | | Quotas | Reads quota status from a DynamoDB quota table during authorization, while scheduled workers refresh quota state from accounting usage data. | | Imports | Large migration jobs stream CSV rows in chunks instead of loading entire files into memory, with lookup data prefetched once for the batch. | The current migration worker design is validated for large imports of 300,000 or more records with flat memory usage and O(1) lookup query growth for shared group and tag data. In the reviewed architecture notes, the 300,000-record path moved from multi-gigabyte memory pressure and thousands of repeated lookups to chunked processing, roughly 50 MB memory use, and two shared lookup queries for group and tag data. ## Data Plane Responsibilities The RadSec edge handles: * Global and regional ingress for RadSec traffic. * TLS termination for RadSec. * Client certificate authentication. * Registered NAS identity extraction. * RADIUS packet framing and forwarding. * `NAS-Identifier` normalization. * Accounting response generation. * Accounting metric extraction. * Session start, stop, usage, and last-IP metric publishing. * Dynamic authorization metric extraction for Disconnect and CoA packets when observed. ## Control Plane Responsibilities The RADIUS service handles: * NAS registration and certificate material. * User, folder, group, realm, tag, and metadata management. * Check and reply attribute validation. * Password storage and reset flows. * PAP, CHAP, MS-CHAP, and MS-CHAPv2 handling. * EAP challenge pass-through behavior where applicable. * Realm matching and optional NAS-to-realm locking. * MAC-based lookup and optional auto-registration. * Quota status checks and top-ups. * Manual session disconnects. * Authentication metrics and NAS logs. ## Control Plane The control plane is the management surface used by operators and integrations. The web UI and REST API manage configuration changes through authenticated and authorized API calls. Use the control plane for: * Creating and updating users, folders, groups, realms, and NAS devices. * Managing certificate material and RadSec device configuration. * Updating check attributes, reply attributes, metadata, tags, quotas, and account status. * Connecting provisioning, billing, identity management, and workflow systems through the API. * Searching operational records and reviewing logs. The control plane scales independently from live RADIUS packet handling. That separation keeps authentication traffic isolated from operator activity, bulk imports, and integration traffic. ## Analytics Plane The analytics plane receives accounting and post-authentication events from the data plane. It is designed for high-throughput ingestion and fast time-series queries across historical RADIUS events. Use the analytics plane for: * Authentication logs and 12-month log retention. * Accounting data and 12-month accounting retention. * Usage charts, sessions, quotas, and top-ups. * Accounting triggers, such as usage-threshold automation. * Dashboards, Live View, and insight queries. * Full-text operational search. Because analytics is decoupled from the authentication path, accounting bursts should not slow down Access-Request processing. ## Quota And Session Control Path Quota enforcement is deliberately split: 1. Groups define quota attributes such as `X-Octet-Quota` and reset behavior. 2. Accounting packets update usage metrics. 3. Scheduled quota workers calculate current usage, apply active top-ups, and write quota state. 4. Authorization reads the current quota state during login. 5. When a user first crosses quota, the platform can dispatch a disconnect workflow for the active session. This keeps the authentication path short while still supporting quota-aware replies, top-ups, and Packet of Disconnect workflows for devices that support dynamic authorization. ## Multi-Tenant Isolation The platform uses several layers of isolation: * NAS traffic is tied to a certificate identity. * Authorization rejects unknown NAS devices. * Users must belong to the same customer as the NAS. * Realms can limit which group attributes apply for a matching username suffix. * NAS devices can be locked to a realm when that behavior is configured. If a request cannot be tied to a known NAS or the user belongs to a different customer, it is rejected. ## Metrics And Observability RADIUS operations feed the monitoring views with: * Access-Accept, Access-Reject, and Access-Challenge counters. * Reject reasons when available. * Accounting packets by status type. * Input and output bytes, including 64-bit Gigawords accounting. * Input and output packets. * Session time. * Session start and stop timestamps. * Last observed framed IP address. * Admin request events for Disconnect and CoA. Accounting and post-authentication events are streamed independently from live authentication. Authentication outcomes and logs are published by the RADIUS service and background metrics pipeline. Together they power Live View, user dashboards, device dashboards, quota checks, top-ups, disconnect workflows, accounting triggers, search, and troubleshooting. ## Operational Implications * Use RadSec certificates from the NAS detail page rather than sharing credentials between devices. * Keep accounting enabled when you rely on usage, sessions, quotas, top-ups, or disconnect workflows. * Use groups for policy because group profiles are cache-friendly and reusable. * Use realms when username suffixes should constrain policy. * Use CoA and PoD only on devices that support dynamic authorization and allow the configured source address. * Review [Limits and Availability](./limits-and-availability) before large migrations, high-rate authentication deployments, or multi-region planning. # CoA and PoD Source: https://altostrat.io/docs/radius/en/coa-and-pod Configure Change of Authorization and Packet of Disconnect for RADIUS NAS devices, manual session disconnects, and quota-triggered disconnects. CoA and PoD are dynamic authorization controls for active RADIUS sessions. Use them when Altostrat needs to change or terminate a user's current session after authentication has already succeeded. * **CoA** means Change of Authorization. It asks the NAS to update an active session's authorization. * **PoD** means Packet of Disconnect. It sends a Disconnect-Request to terminate an active session. In the RADIUS UI, both are configured on the NAS device as **CoA and PoD Replies**. Dynamic authorization uses a different path from ordinary authentication. Access requests come from the NAS to Altostrat. CoA and PoD requests are sent from Altostrat toward the NAS, so the NAS must expose an inbound dynamic-authorization listener and accept the configured source, port, and secret. ## Prerequisites Before you enable CoA or PoD, confirm that: * The NAS supports dynamic authorization. * The NAS can receive dynamic authorization traffic on the configured inbound port. * The NAS firewall allows the message source address shown on the device page. * The CoA and PoD shared secret matches between Altostrat and the NAS. * Accounting is enabled so active sessions include the identifiers needed for disconnect workflows. ## Configure CoA And PoD On A NAS Go to **Settings**, select **Devices**, and open the NAS device. Select **Edit** and enable **CoA and PoD Replies**. Use the address where the NAS accepts dynamic authorization requests. Use the port configured on the NAS. The UI defaults to `3799`. Enter or generate the shared secret used for CoA and PoD messages. Configure the NAS firewall to accept messages from the source address shown in the device page. The current UI shows `18.214.81.214` as the message source address for CoA and PoD. Use the value in the live device page if it differs. ## Manual Disconnect The user detail page can show **Disconnect Session** when a user has an active or recent session. When you disconnect a user, Altostrat: 1. Finds the user. 2. Looks up the user's most recent NAS log. 3. Resolves the NAS device and its CoA/PoD reply settings. 4. Builds a Disconnect-Request using available session attributes such as `User-Name`, `NAS-IP-Address`, and `Acct-Session-Id`. 5. Sends the request to the NAS using the configured NAS IP, port, and secret. 6. Writes the disconnect attempt to NAS logs. If recent session attributes are missing, the disconnect request may fail even when CoA and PoD are enabled. ## CoA Versus PoD | Control | RADIUS packet | What you use it for | | ----------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Packet of Disconnect | `Disconnect-Request` | Terminate a user's active session so the NAS forces the client off or requires a new login. | | Change of Authorization | `CoA-Request` | Ask the NAS to change authorization for an active session, such as applying a different role, filter, or rate limit when the NAS supports it. | The NAS answers dynamic authorization requests with an acknowledgement or a negative acknowledgement. Use the NAS dashboard, user dashboard, and device-side logs together when you need to tell whether the packet was sent, accepted, rejected, or ignored by the device. ## Quota-Triggered Disconnects When quota attributes are configured on groups, the quota worker checks usage against accounting data. If a user crosses the effective quota, Altostrat can dispatch a disconnect job for that user. Top-ups increase the user's effective allowance. If a top-up brings the user back within allowance, the quota marker is recalculated. Use quota-triggered disconnects only when: * Accounting is reliable. * The NAS sends interim updates often enough for your enforcement window. * CoA and PoD settings are configured on the NAS. * Operators understand how top-ups affect the allowance. If the user has multiple quota-enabled groups, the lowest group quota is the effective quota. Top-ups add allowance on top of that effective quota and recalculate whether the user is still exceeded. ## Monitoring Dynamic Authorization Dynamic authorization activity appears in logs and metrics as admin request activity. Where packet details are available, the platform records Disconnect and CoA request type, username, workspace, organization, and NAS context. Use: * The NAS dashboard to review device-scoped logs. * The user dashboard to confirm the session state. * Live View to inspect nearby authentication and accounting events. ## Troubleshooting If manual disconnect or quota disconnect does not work: * Confirm the NAS IP address is reachable from the message source address. * Confirm the inbound port is open. The default is `3799`. * Confirm the secret matches exactly. * Confirm accounting is sending `Acct-Session-Id`. * Confirm accounting Start, Stop, and Interim-Update packets are enabled if you rely on session and quota enforcement. * Confirm the user has a recent NAS log. * Confirm the NAS supports Disconnect-Request for the access technology in use. * Confirm the NAS supports CoA-Request before expecting an in-place authorization change. * Confirm the NAS firewall allows the source address shown in the UI. CoA and PoD are live session controls. Test on one device and one user before enabling them broadly. # Folders and Users Source: https://altostrat.io/docs/radius/en/containers-and-users Organize RADIUS users with folders, bulk actions, user profiles, credentials, status controls, sessions, logs, and metadata. The main RADIUS workspace combines folders and users in one operational view. You can add users directly at the root, build nested folders for hierarchy, and open detail dashboards for a user or folder as your deployment grows. ## Prerequisites Before you manage users, confirm that: * At least one NAS device is registered if you want to test authentication immediately. * Groups exist for any reusable access policy you want to assign. * Realms exist if usernames should use suffixes such as `tim@example.com`. * You know whether users should live at the root or inside folders. ## Folders Folders are containers for users and nested folders. They are useful when you need to organize users by customer, site, region, department, plan, tenant, or operational ownership. Each folder can have: * A name. * A description. * A priority from 1 to 5, where 1 is highest and 5 is lowest. * A pinned state for quick access. * Nested folders and users. The workspace shows folder and user counts, supports pagination, and preserves list state such as page size, page cursor, sort field, sort direction, group filters, and tag filters in the URL. ## Create Folders Go to `/radius` in the RADIUS app. Use the add menu to create one folder or add multiple folders at once. Enter a clear name and optional description. Choose a priority and pin the folder if it should stay prominent. The folder appears alongside users in the current workspace location. ## Folder Actions From the folder list, you can: * Open a folder to work inside it. * Edit the folder name, description, priority, or pinned state. * Pin or unpin one or more folders. * Change priority for selected folders. * Move selected folders to another folder. * Merge selected folders. * Delete a folder when it is no longer needed. Deleting or merging folders changes the organizational structure for nested folders and users. Confirm the destination before performing bulk moves or destructive actions. ## Users Users are individual RADIUS identities. A user can live at the root or in a folder, belong to one or more groups, inherit attributes from groups and realms, and carry user-specific attributes and metadata. When creating a user, the form supports: * Username. * Optional realm suffix through the realm picker. * Password or generated password. * Display name. * Folder assignment. * Group membership. * Custom check attributes. * Custom reply attributes. * Metadata. ## Create Users Go to the root workspace or the folder where the user should live. Use the add menu to create one user or add multiple users. Enter a username and password. Use the password generator when you want the UI to create a credential. Use the `@` selector for realm-backed usernames, or paste a username that already includes a realm. Add groups so the user inherits the intended check and reply attributes. Authenticate from a NAS device, then review the user detail page or Live View. ## Bulk User Creation The bulk user workflow lets you add multiple users in one pass. Each row can include a username, password, display name, folder, group assignment, and advanced fields. Use this for first imports, customer onboarding, or batches of temporary accounts. Recommended checks before saving a bulk set: * Usernames are unique. * Passwords are present or generated. * Display names are readable for operators. * The folder is correct. * The selected groups match the intended policy. For very large migrations, use the migration workflow instead of building a massive manual batch. The RADIUS backend is designed for streaming, chunked imports so large onboarding jobs can validate shared group and tag data once and process records without loading an entire file into memory. ## MAC-Based Users And Auto Registration Some NAS devices authenticate by MAC address rather than by a human-entered username and password. When the NAS sends a Calling-Station-Id or a MAC-like username, Altostrat can resolve the user by normalized MAC identity. If auto registration is enabled on the NAS, an unknown MAC-based user can be created automatically and assigned to the NAS device's configured auto-registration group. Use this only for networks where unknown device onboarding is intentional, such as controlled MAC-auth deployments. ## User Detail Page Open a user to review and operate the account. The dashboard includes: * Display name and username. * Folder link and move-to-folder action. * Group membership and group management. * Realm link when the username matches a configured realm. * Credentials popover for copying username and password. * Status controls for active, disabled, suspended, and re-enabled states shown by the UI. * Edit, delete, and suspend/enable actions. * Time range selection for user metrics. * Latest session, active sessions, usage, and monthly activity where data is available. * Effective check and reply attributes, including inherited group attributes. * User logs with links back to devices. * Metadata fields and shortcuts. If quota features are used in your environment, user dashboards can also show top-up and usage context from the RADIUS data model. ## Move Users You can move a user from the user detail page or select users in the workspace and choose a destination folder. Use moves when operational ownership changes, a customer migrates, or a user was created in the wrong folder. ## Status And Access Controls Use status controls carefully: * **Active** users can authenticate if their credentials and policy are valid. * **Disabled** users are marked inactive in the user form. * **Suspended** users are blocked until re-enabled through the user action menu. * **Disconnect Session** terminates the current active session when session control is available for that user and NAS. ## Metadata Metadata is custom key-value context on the user. The UI treats `display_name` specially by showing it as the user's friendly name. The `site_id` key uses the Altostrat site picker where available. Use metadata for operator context such as customer identifiers, billing references, help desk IDs, or ownership fields. Do not store shared secrets or passwords in metadata. # Getting Started with RADIUS Source: https://altostrat.io/docs/radius/en/getting-started Configure your first RADIUS device, group, user, and test authentication from the Altostrat Radius UI. Use this guide when you are setting up a RADIUS workspace for the first time. It follows the same order shown by the empty-state workflow in the app: add a device, create a group, add users, then organize and monitor. ## Prerequisites Before you begin, confirm that: * You can sign in to the Altostrat Radius UI at [radius.altostrat.app](https://radius.altostrat.app). * You have permission to create NAS devices, groups, users, and realms in the workspace. * Your network device supports RADIUS or RadSec and can be configured with the values shown in the device detail page. * You know the first policy attributes you need to return or check, or you have an existing RADIUS configuration to translate into groups. * If you plan to use CoA or PoD, the NAS can accept control messages from the source address shown in the UI. ## First Setup Go to [radius.altostrat.app](https://radius.altostrat.app) and select the workspace you want to configure. Open **Settings** and select **Devices**. Create a NAS device with a device name, type, and optional description. After the device is created, open its detail page. Use the RadSec configuration values and certificate downloads shown there when configuring the network device. Open **Settings** and select **Groups**. Create a group for the first reusable access policy, then add check or reply attributes as needed. Return to the main RADIUS workspace and add a user. Enter the username, generate or set a password, add an optional display name, choose a folder, and assign groups. Authenticate from the configured NAS device. Open **Live View** or the relevant user/device dashboard to confirm whether the request was accepted or rejected. ## Device Setup Notes When you add a NAS device, the form supports: * Device name or NAS identifier. * Device description. * Device type: router, switch, access point, VPN gateway, firewall, wireless controller, or other. * Auto user registration, optionally tied to a default group. * CoA and PoD replies, including NAS IP address, inbound port, and shared secret. * Metadata fields for local context. After saving the device, the detail page exposes RadSec configuration values and downloads for the NAS certificate, client CA certificate, and private key. Use the values shown in the current device page as the source of truth. The UI currently shows RadSec service values for `aaa.altostrat.io`, port `2083`, and IP addresses `75.2.67.221` and `166.117.188.111`. Use RadSec where the device supports it. RadSec gives each NAS its own mutual-TLS identity, and Altostrat normalizes requests to that registered NAS identity before policy is evaluated. ## Group Setup Notes Groups are where you define reusable RADIUS policy. Add: * Check attributes for values evaluated during authentication. * Reply attributes for values returned after successful authentication. * Metadata when your team needs operational context. Users can inherit attributes from multiple groups. When you edit a user, the UI shows inherited attributes by group so you can see where an effective policy came from. If you are migrating from an existing FreeRADIUS deployment, start with one group per reusable plan, role, VLAN, rate limit, or access tier. Then recreate attributes through the picker so the operator, input type, and vendor dictionary are validated before you test on a live NAS. ## User Setup Notes When you create a user, the form supports: * Username. * Optional realm suffix selected through the `@` realm picker. * Password entry or generated password. * Optional display name. * Folder selection. * Group membership. * Custom check and reply attributes. * Metadata fields. The credentials popover on an existing user lets you copy the username and password. The user detail page also lets you edit the user, reset credentials, suspend or enable access, delete the user, and review sessions and logs. ## Confirm The First Authentication Open **Live View** after the NAS sends a request. Use the filters to narrow the view by status type, user, device, folder, timeframe, or failures only. Healthy first-run signs: * The NAS device appears in logs. * The username matches the expected user. * The status is success or an intentional policy rejection. * The user detail page shows the latest session and recent logs. * The device dashboard shows requests, success rate, active sessions, and rejects. If the first request is rejected, start with [Troubleshooting](./troubleshooting) before changing multiple objects at once. ## What To Read Next Learn how RadSec, policy lookup, metrics, quotas, logs, and imports are designed to scale. Review the supported attributes, operators, input types, and validation limits before building broad policy. Configure dynamic authorization when active sessions need manual or quota-triggered disconnects. # Groups and Attributes Source: https://altostrat.io/docs/radius/en/groups-and-attributes Use RADIUS groups to manage reusable check attributes, reply attributes, inherited policy, members, metadata, and quota-aware presence modes. Groups are the main policy layer in the RADIUS UI. You attach attributes to a group, then assign users to that group directly or through a realm. This keeps user records simple while giving you a consistent place to manage shared access behavior. ## Prerequisites Before you build groups, confirm that: * You know the RADIUS attributes your NAS devices expect. * The required attributes are available in the attribute picker. * You understand whether an attribute belongs in the authentication check or the successful authentication reply. * You have at least one user or realm ready for testing. ## What A Group Contains A group includes: * Group name. * Check attributes. * Reply attributes. * Member users. * Metadata. The group dashboard lets you rename the group inline, edit check and reply attributes, add or remove members, update metadata, and delete the group. ## Check Attributes Check attributes are used during authentication. Use them for conditions or values that must be evaluated before the RADIUS server accepts the request. The group dashboard describes check attributes as attributes sent to the RADIUS server during authentication. ## Reply Attributes Reply attributes are returned after successful authentication. Use them for values the NAS needs after access is granted, such as session behavior, authorization hints, network policy, or vendor-specific values. The group dashboard describes reply attributes as attributes sent back from the RADIUS server upon successful authentication. ## Attribute Rows Each attribute row has: * **Attribute**: selected from the RADIUS attribute dictionary. * **Operator**: limited to the operators allowed for that selected attribute. * **Value**: rendered with the correct input style for the attribute, such as text, number, password, IP address, select option, duration, bandwidth, storage, or URL. * **Presence**: shown when quota-aware behavior is available. The UI fetches the attribute dictionary and uses it to show descriptions, allowed operators, validation hints, vendor grouping, and value input types. Use the picker rather than typing attribute names from memory. The current dictionary includes 51 attributes across Standard, MikroTik, WISPr, Ubiquiti, Cisco, Aruba, Ruckus, Juniper, Microsoft, and Altostrat System attributes. See [Supported Dictionaries](./supported-dictionaries) for the full vendor breakdown. ## Presence Modes Presence controls when an attribute is sent. The UI supports these modes: | Mode | When the attribute is sent | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Always | Sent regardless of usage or status. | | Normal (within quota) | Sent only if the user has not reached quota and is not suspended. | | Quota exceeded | Sent only when quota has been reached or exceeded. | | Suspended | Available for policy modeling in the UI. Suspended users are normally rejected before ordinary success reply attributes are returned. | Presence modes are especially useful when you need different reply behavior for normal access and quota exhaustion. For manual suspension, expect the account status to block access rather than grant a normal success reply. ## Quota Attributes Quota behavior is configured with System attributes on groups: * `X-Octet-Quota` * `X-Quota-TTL` * `X-Quota-Reset-After` * `X-Quota-Carry-Over-Cycles` * `X-Quota-Expire-TTL` Quota attributes are group policy, not user-specific policy. During authorization, Altostrat checks whether the user belongs to quota-enabled groups and reads the current quota state. Scheduled quota workers refresh usage from accounting metrics, factor in active top-ups, and can trigger disconnect workflows when a user first exceeds quota. When multiple assigned groups define quota, the lowest quota is used as the effective limit. If no reset schedule is configured, quota calculations default to a monthly period. Top-ups add temporary allowance and cause the exceeded flag to be recalculated. ## Create A Group Go to **Settings**, then select **Groups**. Add a group and enter a clear group name. Add only the authentication-time attributes required for the policy. Add the values the NAS should receive after successful authentication. Add operational context when it helps operators understand the group. Add users from the group dashboard, from a user detail page, or through a realm. ## Inheritance Users inherit attributes from their groups. When you open a user, inherited attributes are displayed with their source group so you can trace policy back to the object that defined it. Realms can also apply groups automatically. If a user authenticates with a username that matches a realm, the selected realm groups are applied in addition to directly assigned user groups. Group reply attributes are merged first, then user-specific reply attributes are applied. User-specific attributes are best for exceptions because they override group values unless the operator is `+=`, which appends another value for multi-value attributes such as routes. When a user has multiple groups, review the effective attribute display on the user detail page before assuming the final policy. The UI is the best place to confirm what will be applied for that user. ## Recommended Practices * Keep common policy on groups instead of repeating user-specific attributes. * Give groups operational names that describe intent, not only implementation details. * Use user-specific attributes for exceptions and short-lived overrides. * Review inherited attributes on a test user before assigning a group broadly. * Use metadata to connect groups to billing, CRM, support, or customer records. * Keep quota-exceeded behavior explicit when those users should receive different reply attributes, and document suspension behavior as an access block. * Use [CoA and PoD](./coa-and-pod) when quota exhaustion should disconnect active sessions instead of only changing future reply attributes. # RADIUS Overview Source: https://altostrat.io/docs/radius/en/introduction Learn how the Altostrat Radius web UI organizes devices, users, groups, realms, attributes, live logs, and operational settings. Altostrat Radius is the managed access-control workspace for networks that authenticate users through RADIUS or RadSec. You use it to register the network devices that send authentication requests, create the users who sign in, apply policy through groups and attributes, and monitor authentication outcomes in real time. Open the RADIUS UI at [radius.altostrat.app](https://radius.altostrat.app). The UI is organized around the same operational objects you manage day to day: folders, users, groups, devices, realms, live logs, and settings. ## What You Manage Create RADIUS identities, reset credentials, assign groups, place users in folders, suspend access, and review per-user sessions and usage. Organize users into nested containers, pin important folders, set priority, move users, merge folders, and manage bulk onboarding. Define reusable check and reply attributes, then assign those policy sets directly to users or automatically through realms. Pick from the Standard, MikroTik, WISPr, Ubiquiti, Cisco, Aruba, Ruckus, Juniper, Microsoft, and System attributes surfaced by the UI. Register routers, switches, access points, VPN gateways, firewalls, wireless controllers, and other RADIUS clients. Configure dynamic authorization for manual disconnects, quota-triggered disconnects, and supported session control workflows. Understand the global RadSec data plane, mTLS device identity, control plane, analytics plane, multi-region storage, and streaming imports. Review feature coverage, retention, availability targets, throughput limits, migration limits, and default account limits. Match usernames such as `tim@example.com` and automatically apply group attributes to users in that realm. Watch authentication volume, failures, active sessions, device logs, and per-user behavior from the Live View and entity dashboards. ## App Map | Area | Route in the RADIUS UI | What it is for | | -------------- | ----------------------- | -------------------------------------------------------------------------------------------------------- | | Main workspace | `/radius` | Browse folders and users, create identities, create folders, move users, and perform bulk actions. | | Folder detail | `/radius/container/...` | Work inside a nested folder while preserving the same folder and user controls. | | User detail | `/radius/users/{id}` | Review credentials, status, group membership, inherited attributes, sessions, usage, logs, and metadata. | | Devices | `/radius/nas` | Register and manage NAS/RADIUS clients and open per-device dashboards. | | Groups | `/radius/groups` | Create policy groups, edit attributes, and manage group members. | | Realms | `/radius/realms` | Create realm suffixes and apply groups automatically to matching usernames. | | Live View | `/radius/live` | Filter live authentication data by status, user, device, folder, timeframe, and failures. | | Settings | `/radius/settings` | Customize labels and manage metadata shortcuts. | ## Platform Architecture Altostrat Radius separates live packet handling from policy management and analytics. The ArcRadius data plane uses global ingress, regional load balancing, RadSec mutual TLS, and horizontally scalable RADIUS workers to process authentication close to the nearest healthy regional deployment. The control plane stores and evaluates users, folders, groups, realms, NAS devices, quotas, metadata, and logs. The analytics plane streams accounting and post-authentication events into time-series storage for dashboards, triggers, search, quotas, and reporting. This separation keeps authentication traffic isolated from operator activity, imports, accounting bursts, and long-running queries. See how RadSec, mTLS identity, caching, sharding, quotas, metrics, and imports fit together. Review the current Standard, MikroTik, WISPr, Ubiquiti, Cisco, Aruba, Ruckus, Juniper, Microsoft, and System attributes. See availability targets, authentication throughput limits, migration ceilings, retention, and object limits. ## Recommended Setup Order Start by registering the router, VPN gateway, access point, wireless controller, or other RADIUS client that will send authentication requests. Build groups for the common policies you want to reuse, such as access tiers, device roles, customer plans, or operational exceptions. Create users manually or in bulk, generate credentials, assign groups, and place users in folders when you need hierarchy. Create realms for suffix-based policy, such as `example.com`, so matching usernames automatically inherit selected group attributes. Configure CoA and PoD settings on NAS devices when active sessions must be disconnected manually or after quota enforcement. Use Live View and entity dashboards to confirm accepts, rejects, missing attributes, bad passwords, suspended accounts, and active sessions. ## Terminology | Term | Meaning in Altostrat Radius | | --------------- | -------------------------------------------------------------------------------------------------------------------------------- | | User | An account that authenticates to the RADIUS service. The UI can also show a display name from user metadata. | | Folder | A container for organizing users and nested folders. Your workspace may relabel folders as containers or another local term. | | Group | A reusable policy object that carries check attributes, reply attributes, metadata, and member users. | | Check attribute | An attribute used during authentication checks. | | Reply attribute | An attribute returned after successful authentication. | | NAS device | A Network Access Server or RADIUS client, such as a router, VPN gateway, access point, switch, firewall, or wireless controller. | | Realm | A normalized suffix used with usernames such as `tim@example.com` to apply groups automatically. | | Metadata | Custom key-value context on users, groups, realms, or NAS devices. | | RadSec | RADIUS over TLS. Altostrat uses RadSec with mutual TLS for device identity and secure transport. | | CoA | Change of Authorization, used when a NAS supports changing an active session after login. | | PoD | Packet of Disconnect, used to terminate an active session through a Disconnect-Request. | | Dictionary | The supported attribute catalog that drives the attribute picker, validation, operators, and input types. | The UI lets admins customize labels for users, folders, devices, and groups. If your workspace uses different labels, the workflows are the same even when the nouns differ. ## Where To Go Next Follow the first-run path from NAS registration through test authentication. Learn how to create users, use folders, bulk add records, and manage user details. Understand check attributes, reply attributes, inheritance, and quota-aware presence modes. Enable dynamic authorization for manual disconnects, quota-triggered disconnects, and session control. Use Live View, logs, metrics, sessions, and dashboards for day-two operations. Check availability targets, retention, throughput, migration, and object limits before a rollout. # Limits and Availability Source: https://altostrat.io/docs/radius/en/limits-and-availability Review ArcRadius feature coverage, availability targets, retention, performance limits, migration limits, and default account limits. Use this page to plan capacity, onboarding, and operational expectations for Altostrat Radius. The limits below are default account limits. Where a row is marked adjustable, contact Altostrat before you design around the higher value. This page covers feature coverage, availability, retention, and operational limits. ## Feature Coverage | Capability | Support | Notes | | ----------------------------------- | --------- | -------------------------------------------------------------------------------------------- | | RadSec TLS | Supported | Use RadSec for encrypted RADIUS transport and NAS identity. | | EAP-PEAP | Supported | Used for Wi-Fi and 802.1X environments where the NAS and client stack support it. | | EAP-TTLS | Supported | Used for tunneled EAP deployments. | | PAP, CHAP, MS-CHAP, and MS-CHAPv2 | Supported | Common for broadband, VPN, PPP, and access-network devices. | | External identity providers for EAP | Supported | Examples include Microsoft Azure, Google Workspace, and Okta. | | Custom attributes | Supported | Attribute names, operators, and value types must pass validation. | | Webhook events | Supported | Use events for external automation and operational workflows. | | Full-text search | Supported | Search is designed for operational lookup across RADIUS data. | | Authentication logs | Supported | Retained for 12 months. | | Accounting data storage | Supported | Retained for 12 months. | | Accounting triggers | Supported | Use triggers for usage-based actions, such as taking action after a monthly usage threshold. | | Management interface | Web based | Operators manage users, groups, NAS devices, realms, logs, and settings through the web UI. | | REST API integration | Supported | Use the API for provisioning and external systems integration. | | Altostrat Workflows integration | Supported | Use workflows to automate follow-up actions from RADIUS events. | ## Security And Data Protection | Control | Coverage | | ---------------------- | -------------------------------------------- | | Encryption in transit | Supported. | | Encryption at rest | Supported. | | Point-in-time recovery | Per-second recovery granularity for 15 days. | | DDoS protection | Supported. | ## Availability Targets | Target | Value | Notes | | ----------------------------- | ------------: | ------------------------------------------ | | RADIUS availability guarantee | 99.999% | SLA-backed. | | Data durability | 99.999999999% | 11 nines, SLA-backed. | | Service IP availability | 99.99% per IP | SLA-backed. | | Authentication time | At most 80 ms | Target authentication processing time. | | Service IP addresses | 2 | Exposed for service reachability. | | Availability Zones per region | 3 | Each always-on region uses multiple AZs. | | AZ failover | Yes | Designed to fail over within milliseconds. | | Always-on regions | 3 | Virginia, Sydney, and Cape Town. | | Regional failover | Yes | Designed to fail over within minutes. | ## Performance Limits | Limit | Default | Adjustable | | --------------------------------------------------------- | ----------------------: | ---------- | | Maximum concurrent authentication attempts per NAS device | 1,000 per second | No | | Maximum concurrent authentication attempts per workspace | 12,000 per second | No | | Minimum accounting data frequency | 300 seconds | No | | Management API rate limit | 600 requests per minute | Yes | The minimum accounting data frequency means NAS devices should not send interim accounting updates more frequently than every 300 seconds unless Altostrat has explicitly advised otherwise. ## Migration Limits Migration limits apply individually to customer records, RADIUS accounts, attribute groups, and NAS devices. | Limit | Default | Adjustable | | --------------- | ------: | ---------- | | CSV import size | 500 MB | No | For large migrations, use chunked imports and validate a smaller sample before importing the full file. See [Folders and Users](./containers-and-users) for the user onboarding workflow and [Architecture and Scale](./architecture) for how large imports are processed. ## Customer Record Limits | Limit | Default | Adjustable | | ----------------------------------- | ------: | ---------- | | Customer records | 500,000 | Yes | | Metadata pairs per customer record | 20 | No | | Tags per customer record | 10 | No | | RADIUS accounts per customer record | 25,000 | Yes | ## RADIUS Account Limits | Limit | Default | Adjustable | | ----------------------------------- | --------: | ---------- | | RADIUS accounts | 1,000,000 | Yes | | Attribute groups per RADIUS account | 5 | No | | Check attributes per RADIUS account | 5 | No | | Reply attributes per RADIUS account | 10 | No | | Metadata pairs per RADIUS account | 20 | No | | Tags per RADIUS account | 10 | No | ## NAS Device Limits | Limit | Default | Adjustable | | ----------------------------- | ------: | ---------- | | NAS devices | 25,000 | Yes | | Metadata pairs per NAS device | 20 | No | ## Attribute Group Limits | Limit | Default | Adjustable | | ------------------------------------- | --------: | ---------- | | Attribute groups | 15,000 | Yes | | Check attributes per group | 15 | No | | Reply attributes per group | 25 | No | | RADIUS accounts in an attribute group | 1,000,000 | Yes | | Metadata pairs per attribute group | 20 | No | | Tags per attribute group | 10 | No | ## Design Guidance * Use groups for reusable policy so account-level attributes stay small and easy to reason about. * Keep metadata focused on operational lookup fields; avoid storing secrets in metadata. * Use tags for coarse filtering, ownership, and lifecycle state rather than high-cardinality data. * Keep accounting interim updates at or above the supported minimum interval when usage, sessions, quotas, and triggers depend on accounting. * Ask Altostrat about adjustable limits before a migration, reseller model, or large customer deployment depends on higher ceilings. # Live Monitoring and Logs Source: https://altostrat.io/docs/radius/en/live-monitoring Use RADIUS Live View, log filters, user dashboards, device dashboards, metrics, sessions, and failure categories to operate authentication. Live monitoring is the day-two operations surface for RADIUS. Use it to see whether authentication is working, isolate failures, inspect sessions, and jump from a log entry to the affected user or NAS device. ## Prerequisites Before you use Live View effectively, confirm that: * At least one NAS device is sending authentication traffic. * Users and groups exist for the traffic you expect to see. * You know the approximate time range for the issue or test. * You have permission to view logs and entity dashboards. ## Live View Open **Live View** from the RADIUS navigation. The page combines metrics and a full log table, with filters for common operational questions. Use Live View to answer: * Are authentications succeeding? * Which users are being rejected? * Which NAS device is sending bad or unexpected traffic? * Are failures concentrated in one folder, device, or timeframe? * Are suspended users attempting to authenticate? * Are requests missing attributes or other required information? ## Filters The log card supports: * Status type filters. * Failures-only toggle. * User filter. * Folder filter. * Device filter. * Timeframe filter. * Search by log ID. * Sort field and sort direction. * Refresh. The global RADIUS filter model supports timeframes including 1 hour, 3 hours, 6 hours, 12 hours, 24 hours, and 7 days. User dashboards also include user-focused ranges such as last 24 hours, last 7 days, and last 30 days. ## Status Categories The monitoring UI groups authentication outcomes into practical categories: | Category | What it means | | ------------ | --------------------------------------------------------- | | Success | Successful authentications and authorizations. | | Missing | Users missing required attributes or information. | | Bad Password | Users who attempted to log in with incorrect credentials. | | Rejected | Users rejected during the authentication process. | | Suspended | Users blocked from accessing the network. | The raw RADIUS message types available in filters include Access-Accept, Access-Reject, and Access-Challenge. ## Accounting Metrics When accounting is enabled on the NAS, Altostrat can use accounting data for sessions, usage, quotas, and dashboards. The RadSec edge publishes accounting data asynchronously so the NAS receives an Accounting-Response without waiting on the metrics pipeline. The monitoring pipeline tracks: * Input and output bytes, including Gigawords for 64-bit counters. * Input and output packets. * Session duration. * Accounting packet count. * Session start time. * Session stop time. * Last framed IP address. * Accounting status type such as Start, Stop, Interim-Update, Accounting-On, and Accounting-Off. Authentication results are also counted with labels for workspace, organization, NAS, username, and reject reason when available. The accounting path and authentication path are intentionally separate. Accounting and post-authentication events stream into the analytics plane after packets are handled, while authentication outcomes and NAS logs are produced by the RADIUS service and background metrics jobs. This keeps live packet handling responsive while still giving operators a joined view in the UI. Authentication logs and accounting data are retained for 12 months. For capacity and retention planning, see [Limits and Availability](./limits-and-availability). ## Accounting Triggers Accounting triggers let you automate follow-up actions from usage data, such as acting when a user exceeds a monthly data threshold. Use them when an operational response should be driven by accounting events rather than by a manual dashboard review. Triggers depend on reliable accounting. Configure Start, Stop, and Interim-Update packets on the NAS, and keep interim update frequency at or above the supported minimum interval documented in [Limits and Availability](./limits-and-availability). ## Admin Request Metrics CoA and PoD events are tracked as admin request activity when dynamic authorization packets are sent or observed by the platform. Use this with NAS logs and device-side logs when you are validating manual disconnects, quota-triggered disconnects, or CoA behavior. ## Log Table Expanded logs show: * Status or reply message. * Execution time in milliseconds. * User, with a link to the user detail page when available. * Device, with a link to the NAS detail page when available. * Folder or container when present. * IP address when present. * Timestamp. Click a log row to inspect the request and response details. Use the user and device links to continue the investigation from the most relevant entity dashboard. ## User Dashboard The user detail page is the best place to investigate one account. It includes: * Time range selector. * Usage and session charts where data is available. * Latest session. * Active session state. * Latest IP address. * Group membership. * Realm link. * Effective check and reply attributes. * Logs scoped to the user. * Actions for edit, suspend or enable, delete, move, reset credentials, and disconnect session. Use this page when the same user repeatedly fails, consumes unexpected usage, or needs an active session disconnected. ## Device Dashboard The NAS detail page is the best place to investigate one device. It includes: * Logs scoped to the NAS. * Total requests. * Success rate. * Active sessions. * Reject count. * RadSec configuration values. * Certificate downloads. * CoA and PoD settings. * Device metadata. Use this page when many users behind the same NAS fail at the same time, or when you are validating a new router, access point, VPN gateway, firewall, or wireless controller. ## Operational Workflow Open Live View and set the timeframe around the incident or test. Turn on failures only, then narrow by status category if needed. Use the log row to identify the user, NAS device, folder, and response. Jump to the user or NAS dashboard for scoped logs and related metrics. Fix the credential, status, group, realm, NAS setting, or attribute issue you found. Authenticate again and confirm the new log entry has the expected outcome. # NAS Devices Source: https://altostrat.io/docs/radius/en/nas-devices Register and manage RADIUS clients, RadSec configuration, certificates, CoA and PoD settings, auto registration, device metrics, and NAS logs. NAS devices are the network devices that send RADIUS authentication requests to Altostrat. In the UI, this includes routers, switches, access points, VPN gateways, firewalls, wireless controllers, and other RADIUS-capable clients. ## Prerequisites Before you register a device, confirm that: * The network device can be configured as a RADIUS or RadSec client. * You know the device identifier you want operators to recognize in logs. * The device can reach the RADIUS service values shown in its device detail page. * You have access to upload certificates or configure RadSec when using secure transport. * If you use CoA or PoD, the device can accept control messages from the source address and secret shown in the UI. ## Add A Device In the RADIUS app, open **Settings** and select **Devices**. Enter the device name or NAS identifier, choose the device type, and add an optional description. Enable auto user registration only if unknown users should be created automatically. Select a default group when those users should inherit policy immediately. Enable CoA and PoD replies if you want RADIUS to disconnect users or send change-of-authorization messages. After saving, open the device detail page to copy RadSec values and download certificates. ## Device Fields | Field | Purpose | | ----------------------------- | ----------------------------------------------------------------------------------- | | Device name or NAS identifier | The identifier shown in device lists, logs, and dashboards. | | Description | Operator-facing context for the device. | | Device type | Router, switch, access point, VPN gateway, firewall, wireless controller, or other. | | Auto user registration | Allows the device flow to create users automatically when enabled. | | Auto registration group | Optional group assigned to automatically registered users. | | CoA and PoD replies | Enables disconnect and change-of-authorization behavior. | | NAS IP address | Device address used for CoA and PoD replies. | | NAS inbound port | Device port for CoA and PoD replies. The UI defaults to `3799`. | | Secret | Shared secret used for CoA and PoD replies. | | Metadata | Custom operational fields for this device. | ## RadSec Configuration The device detail page shows the current RadSec configuration and certificate downloads. Use the values shown there when configuring the NAS. The UI currently displays: * FQDN: `aaa.altostrat.io` * IP addresses: `75.2.67.221`, `166.117.188.111` * Port: `2083` * NAS certificate download. * Client CA certificate download. * NAS private key download. Use the values shown on the live device page if they differ from this documentation. Network service endpoints can be updated over time, and the device page is the operator source of truth. RadSec uses mutual TLS. The NAS certificate identifies the workspace, organization, and NAS device, and the RadSec edge binds traffic to that registered identity. That means logs and authorization use the trusted NAS identity from the certificate rather than trusting a mutable `NAS-Identifier` supplied by the device. Use one certificate set per NAS device. Reusing certificate material across routers, access points, or controllers makes logs harder to trust and weakens device-level isolation. ## Auto Registration Auto registration is useful for MAC-based access flows where the NAS sends a Calling-Station-Id or a MAC-like username and you want unknown devices to become users automatically. When auto registration is enabled on the NAS: * Unknown MAC-based users can be created automatically. * The username is normalized from the MAC address. * The user can be assigned to the selected auto-registration group. * The user starts active unless your operating process changes status after creation. * The user is linked to the NAS that created it through metadata. Only enable auto registration on NAS devices where this behavior is intentional. For ordinary username/password access, leave it disabled and create users through the normal user workflow or bulk import. ## CoA And PoD Enable CoA and PoD replies when you need session control, such as manual disconnects or authorization changes. The UI collects: * NAS IP address. * NAS inbound port. * CoA and PoD secret. The device dashboard also displays the message source address for control messages. The current UI shows `18.214.81.214` as the source address and `3799` as the default inbound port. Configure the NAS to accept CoA and PoD traffic from the values shown in the device page. For the full dynamic authorization workflow, see [CoA and PoD](./coa-and-pod). ## Device Dashboard Open a device to view: * Authentication logs for that NAS. * Log status, execution time, user, container, IP address, and timestamp. * Total requests. * Success rate. * Active sessions. * Reject count. * RadSec configuration values. * Certificate, CA, and private key downloads. * CoA and PoD settings. * Metadata and shortcuts. Use the device dashboard when you are troubleshooting a specific router, access point, VPN gateway, or controller. It is faster than filtering global logs when you already know which NAS sent the request. ## Delete A Device Deleting a NAS device removes it from the RADIUS configuration. Existing authentication from that device will stop working once the device no longer matches an active RADIUS client configuration. Before deleting, confirm: * The device is decommissioned or replaced. * No active users depend on it. * You have exported or copied any certificate material you still need for migration. * Recent logs do not show unexpected authentication traffic. # Realms Source: https://altostrat.io/docs/radius/en/realms Use RADIUS realms to match username suffixes and automatically apply group attributes to matching users. Realms let you apply policy from the username itself. When a user authenticates with a username such as `tim@example.com`, the RADIUS UI can match `example.com` and apply the groups attached to that realm. ## Prerequisites Before you create a realm, confirm that: * You know the realm suffix users will authenticate with. * The groups you want to apply already exist. * The NAS sends usernames in the expected format. * You have a test user that can authenticate with the realm suffix. ## How Realms Work A realm is a normalized suffix. The form strips a leading `@`, removes whitespace, lowercases the value, and accepts letters, numbers, dots, and hyphens. Examples: * `example.com` * `staff.example.com` * `reseller-1.example.com` When users authenticate with matching usernames, the realm groups are applied automatically. The realm detail page shows assigned groups and metadata, and the user detail page links back to the matching realm when one is detected. ## Create A Realm In the RADIUS app, open **Settings** and select **Realms**. Enter the suffix, such as `example.com`. The UI displays the realm with an `@` prefix. Use the description to explain who owns the realm or why it exists. Select the groups that should apply to matching users. Authenticate with a username that includes the realm suffix, then review the user detail page and Live View. ## Assign Groups To A Realm Realm groups are applied automatically to matching users. Use them for policy that belongs to a domain, tenant, partner, or customer namespace rather than to a single user. Good realm group examples: * Default access policy for a customer domain. * Common vendor attributes for a partner-managed network. * Shared quota behavior for a tenant. * Standard reply attributes for a staff realm. ## User Creation With Realms When adding a user, the username field includes an `@` realm picker. You can select an existing realm or paste a username that already contains a realm suffix. The UI keeps the local username and selected realm aligned. If you create a user without selecting a realm, the user can still belong to groups directly. Realms are only needed when suffix-based policy should apply. ## Edit Or Delete A Realm From the realm detail page, you can: * Edit the realm name and description. * Add or remove groups. * Update metadata. * Delete the realm. Deleting a realm stops matching users from automatically inheriting that realm's group attributes. Users can still retain directly assigned groups. ## Troubleshooting Realm Matches If realm groups are not appearing where you expect: * Confirm the username includes the suffix. * Confirm the realm value is normalized without a leading `@`. * Confirm the NAS is not rewriting usernames before sending them. * Confirm the realm has groups assigned. * Open the user detail page and check whether the realm badge links to the expected realm. # Settings, Labels, Metadata, and Shortcuts Source: https://altostrat.io/docs/radius/en/settings-and-shortcuts Customize RADIUS labels, use metadata fields, and create global metadata shortcuts to external systems from the Radius UI. RADIUS settings let you tune the UI language and connect RADIUS records to external systems. The settings area covers label customization and metadata shortcuts, while individual users, groups, realms, and NAS devices each expose metadata fields on their detail pages. ## Prerequisites Before you change settings, confirm that: * You have permission to manage RADIUS settings. * Your team agrees on the vocabulary you want operators to see. * You know which metadata keys should be used consistently. * You have the external URL patterns needed for shortcuts. ## Labels Open **Settings** in the RADIUS app to customize labels for: * Users. * Folders or containers. * Devices. * Groups. Each label has singular and plural forms. The UI uses these labels throughout the RADIUS workspace, including navigation, list headers, empty states, buttons, and detail pages. Use label customization when your organization has established terms such as customers, subscribers, tenants, locations, clients, devices, or policies. The default UI label for containers is shown as folders in the app. The underlying behavior is the same: folders organize users and nested folders. ## Metadata Metadata is custom key-value data on RADIUS objects. You can add metadata to: * Users. * Groups. * Realms. * NAS devices. Metadata appears in the detail sidebar for each object. It can be edited, copied, and used as the basis for shortcuts. Special metadata behavior: * `display_name` is treated as the friendly user display name. * `site_id` uses the Altostrat site picker when the UI can resolve sites. * Empty keys or empty values are not saved. ## Metadata Shortcuts Metadata shortcuts create external links from metadata values. They are useful when operators need to jump from a RADIUS record to a CRM, billing platform, support case, monitoring page, or internal admin system. A shortcut includes: * Parent type, such as user, group, realm, or NAS. * Metadata key. * Label. * URL template. * Optional icon. The URL template uses `` as the placeholder for the metadata value. For example, a `customer_id` metadata field can link to an external customer profile by inserting the customer ID into the URL. ## Create A Shortcut From Metadata Open a user, group, realm, or NAS device that has metadata. In the metadata sidebar, hover or open the shortcuts control for the field. Enter a label and a URL template that includes ``. The shortcut becomes available for matching metadata keys on the same parent type. Open the shortcut from any matching metadata field to jump to the external system. ## Manage Shortcuts Globally Open **Settings** to review all configured metadata shortcuts. The settings page groups shortcuts by parent type and metadata key. From there you can edit labels and URL templates or delete shortcuts that are no longer needed. Shortcut changes apply globally across matching objects. ## Recommended Metadata Keys Use stable, predictable keys so shortcuts and filters remain useful over time: * `customer_id` * `site_id` * `ticket_id` * `billing_account_id` * `external_id` * `support_url` * `owner_team` Avoid storing secrets, passwords, private keys, or access tokens in metadata. Metadata is operational context, not a secret store. ## Label And Metadata Governance For larger RADIUS workspaces: * Decide labels before broad onboarding. * Keep metadata keys lowercase and consistent. * Use one key for one meaning. * Prefer IDs over names when linking to external systems. * Add shortcuts for common operator jumps. * Review global shortcuts when renaming metadata keys. # Supported Dictionaries Source: https://altostrat.io/docs/radius/en/supported-dictionaries Review the RADIUS attribute dictionaries, vendors, operators, value types, and quota attributes surfaced by the Altostrat Radius UI. The RADIUS attribute picker is driven by a curated dictionary that the UI fetches from the RADIUS service. It includes standard RFC attributes, common vendor-specific attributes, and Altostrat system attributes used for quota behavior. Use the picker in the UI as the source of truth. It shows the current attribute name, vendor, description, tags, input type, select options, validation type, and allowed operators. ## Dictionary Coverage The current dictionary exposes 51 attributes across these vendors: | Vendor | Count | Common uses | | --------- | ----: | --------------------------------------------------------------------------------------------------------------------------- | | Standard | 25 | Session timers, IP assignment, framed routes, service type, VLAN assignment, passwords, access control, and reply messages. | | MikroTik | 4 | Rate limits, address lists, MikroTik groups, and delegated IPv6 pools. | | WISPr | 2 | Bandwidth limits for wireless and hotspot environments. | | Ubiquiti | 1 | Egress VLAN assignment. | | Cisco | 1 | Cisco AVPair policy values. | | Aruba | 3 | User role, user VLAN, and captive portal URL. | | Ruckus | 3 | SSID and uplink/downlink rate limits. | | Juniper | 5 | Local usernames, DNS, ingress policy, and egress policy. | | Microsoft | 2 | Primary and secondary DNS server attributes. | | System | 5 | Altostrat quota attributes. | ## Standard Attributes Standard attributes include: * `Session-Timeout` * `Idle-Timeout` * `Acct-Interim-Interval` * `Termination-Action` * `Framed-IP-Address` * `Framed-IP-Netmask` * `Framed-Route` * `Framed-Pool` * `Delegated-IPv6-Prefix` * `Framed-Protocol` * `Framed-MTU` * `Service-Type` * `NAS-Port-Type` * `Port-Limit` * `Tunnel-Private-Group-Id` * `Tunnel-Type` * `Tunnel-Medium-Type` * `Filter-Id` * `Reply-Message` * `Class` * `Login-LAT-Service` * `User-Password` * `CHAP-Password` * `Cleartext-Password` * `Code` `Code` is a response-control attribute used by the platform response flow. Most customer policy work uses the session, IP, service, VLAN, filtering, and vendor-specific attributes rather than editing `Code` directly. ## Vendor Attributes | Vendor | Attributes | | --------- | -------------------------------------------------------------------------------------------------------------------------------------- | | MikroTik | `Mikrotik-Rate-Limit`, `Mikrotik-Address-List`, `Mikrotik-Group`, `Mikrotik-Delegated-IPv6-Pool` | | WISPr | `WISPr-Bandwidth-Max-Down`, `WISPr-Bandwidth-Max-Up` | | Ubiquiti | `Egress-VLANID` | | Cisco | `Cisco-AVPair` | | Aruba | `Aruba-User-Role`, `Aruba-User-Vlan`, `Aruba-Captive-Portal-URL` | | Ruckus | `Ruckus-SSID`, `Ruckus-Downlink-Rate-Limit`, `Ruckus-Uplink-Rate-Limit` | | Juniper | `Juniper-Local-User-Name`, `Juniper-Primary-DNS`, `Juniper-Secondary-DNS`, `Juniper-Ingress-Policy-Name`, `Juniper-Egress-Policy-Name` | | Microsoft | `MS-Primary-DNS-Server`, `MS-Secondary-DNS-Server` | ## System Quota Attributes Altostrat system attributes are used for quota-aware policy: * `X-Octet-Quota` * `X-Quota-TTL` * `X-Quota-Reset-After` * `X-Quota-Carry-Over-Cycles` * `X-Quota-Expire-TTL` Quota attributes belong on groups, not individual users. The quota service reads group attributes, uses the lowest quota when multiple groups define one, and applies top-ups when calculating the effective allowance. | Attribute | Purpose | | --------------------------- | ----------------------------------------------------------- | | `X-Octet-Quota` | Data quota in bytes. | | `X-Quota-TTL` | Hours after which a quota resets. | | `X-Quota-Reset-After` | Cron expression for the quota reset schedule. | | `X-Quota-Carry-Over-Cycles` | Number of cycles unused quota can carry over. | | `X-Quota-Expire-TTL` | Hours after usage begins before the quota expires entirely. | ## Operators The UI supports these RADIUS operators where allowed by the selected attribute: | Operator | Typical meaning | | -------- | --------------------------------------------- | | `:=` | Set or replace the attribute value. | | `==` | Match the request attribute value. | | `+=` | Add another value for multi-value attributes. | | `!=` | Match when a value is not equal. | | `>` | Match greater-than values. | | `>=` | Match greater-than-or-equal values. | | `<` | Match less-than values. | | `<=` | Match less-than-or-equal values. | The picker limits the operator list to what the selected attribute supports. ## Input Types Attributes render with an input type that matches their expected value: * Text. * Number. * Password. * IP address. * Select dropdown. * Duration in seconds. * Bandwidth in bps or kbps. * Storage in bytes. * URL. For enumerated attributes such as `Service-Type`, `NAS-Port-Type`, `Tunnel-Type`, and `Tunnel-Medium-Type`, the UI shows friendly labels while storing the configured value. ## Validation Limits The picker and API enforce type checks and selected range checks. Current notable limits include: | Attribute | Accepted range | | ----------------------------------------------------------------- | -------------------------- | | `Session-Timeout` | 60 to 604800 seconds. | | `Idle-Timeout` | 60 to 7200 seconds. | | `WISPr-Bandwidth-Max-Up` and `WISPr-Bandwidth-Max-Down` | 8000 to 1000000000 bps. | | `Ruckus-Uplink-Rate-Limit` and `Ruckus-Downlink-Rate-Limit` | 8 to 1000000 kbps. | | `Tunnel-Private-Group-Id`, `Aruba-User-Vlan`, and `Egress-VLANID` | VLAN ID 1 to 4094. | | `X-Octet-Quota` | 0 to 10995116277760 bytes. | | `X-Quota-TTL` and `X-Quota-Expire-TTL` | 1 to 8760 hours. | | `X-Quota-Carry-Over-Cycles` | 0 to 12 cycles. | ## Tags Attributes are tagged for filtering and discovery. Current tags include session, accounting, ISP, IP, DHCP, routing, IPv6, network, service, authentication, NAS, access, limitation, Wi-Fi, VLAN, filtering, user experience, bandwidth, policy, firewall, hotspot, QoS, DNS, and quota. ## Attribute Validation The API validates attributes before saving users or groups. If an attribute is not in the supported dictionary, uses an unsupported operator, or has a value that does not match the expected type, the save request is rejected. Password-related attributes are supported for RADIUS protocol compatibility, but normal user credential changes should use the credential fields and reset flows in the UI. Do not use metadata or ad hoc attributes as a shared secret store. When translating an existing FreeRADIUS deployment, create one group per reusable policy first. Then use the picker to recreate the check and reply attributes with the correct vendor dictionary and operator. # RADIUS Troubleshooting Source: https://altostrat.io/docs/radius/en/troubleshooting Troubleshoot RADIUS rejects, bad passwords, missing attributes, suspended users, device setup issues, realms, CoA and PoD, RadSec, and missing logs. Use this page when RADIUS authentication does not behave as expected. Start in Live View, identify the user and NAS device, then inspect the smallest object that can explain the failure. ## Prerequisites Before troubleshooting, collect: * Approximate time of the failed authentication. * Username used by the client. * NAS device that sent the request. * Expected group or realm policy. * Whether this is first setup, a regression, or a single-user issue. ## First Checks 1. Open **Live View**. 2. Set the timeframe to cover the test or incident. 3. Turn on **Failures only** if there are many logs. 4. Filter by user, folder, device, or status type. 5. Open the matching user or NAS device from the log row. 6. Change one setting at a time, retest, and confirm the next log entry. ## User Is Rejected Check: * The user exists in the expected workspace. * The username in the log matches the stored username exactly. * The user is active or enabled. * The user belongs to the expected groups. * The realm is matching when the username includes a suffix. * Required check attributes are present. * Reply attributes are valid for the NAS device. * The NAS is sending the request from the registered device configuration. * The authentication protocol matches the device configuration: PAP, CHAP, MS-CHAP, MS-CHAPv2, EAP continuation, or MAC-based access. Open the user detail page and review effective check and reply attributes before editing multiple groups. ## Bad Password Check: * The password stored on the user is the current password. * The client is not caching an old credential. * The username includes the intended realm suffix. * The NAS is not rewriting the username before sending the request. Use **Reset Credentials** on the user detail page when you need to issue a new password, then retest with a fresh login. ## Missing Attributes Check: * The user has at least one group with the required attributes. * Realm groups are applied when the username uses a realm. * The attribute is in the correct section: check attributes for authentication-time checks, reply attributes for successful replies. * The selected operator is valid for that attribute. * The value matches the input type and expected format. * Presence mode is not preventing the attribute from being sent. * The attribute exists in [Supported Dictionaries](./supported-dictionaries). Unsupported or misspelled attributes are rejected before save. * Quota attributes are on groups, not individual users. If an attribute appears on a group but not on the user, inspect the user's inherited attribute display to confirm group membership and inheritance. ## Suspended Or Disabled User Check: * The user status in the user form. * Whether the user was manually suspended from the dashboard. * Whether operators expected suspended users to receive a normal success reply. Suspended users are normally blocked before ordinary reply attributes are returned. * Whether an active session should be disconnected after suspension. Use **Enable User** when the suspension is intentional but should be lifted. ## No Logs Appear Check: * The Live View timeframe. * Whether filters are hiding results. * Whether the NAS device was created in the expected workspace. * Whether the NAS can reach the RadSec or RADIUS service values shown on its device page. * Whether device certificates or shared secrets are installed correctly. * Whether the NAS is configured to send accounting or authentication traffic to the expected destination. If the device was just created, open the NAS detail page and confirm that configuration values and certificates are available. ## Device Cannot Authenticate Check: * Device name or NAS identifier. * Device type. * RadSec FQDN, IP addresses, and port shown on the device page. * NAS certificate, client CA certificate, and private key. * Local firewall rules between the NAS and the RADIUS service. * Device clock and certificate validity assumptions. * Whether the device is reusing another NAS certificate. Each NAS should use its own certificate downloads. * Whether traffic is reaching the service by checking Live View and the NAS dashboard. * Whether the `NAS-Identifier` in logs maps to the registered NAS. RadSec traffic is bound to the certificate identity and normalized by the edge. Use the NAS dashboard to isolate whether all users behind one device are failing or only one account is failing. ## CoA Or PoD Does Not Work Check: * CoA and PoD replies are enabled on the NAS record. * NAS IP address is correct. * NAS inbound port is correct. The UI defaults to `3799`. * CoA and PoD secret matches the device. * The NAS firewall allows the message source address shown on the device page. * The user has an active session before you try to disconnect it. * Accounting sends `Acct-Session-Id` and, where possible, Start, Stop, and Interim-Update packets. * The NAS supports Disconnect-Request for the access technology in use. * The NAS supports CoA-Request before you expect an in-place authorization change. The current UI shows `18.214.81.214` as the CoA and PoD message source address. Use the live device page if it shows a different value. ## Realm Policy Is Not Applied Check: * The username includes the realm suffix, such as `tim@example.com`. * The realm exists without a leading `@`. * The realm value contains only letters, numbers, dots, and hyphens. * The realm has groups assigned. * The NAS is not stripping or rewriting the suffix. * The user detail page shows the expected realm link. If you change realm groups, retest and review the user's effective attributes. ## Group Changes Do Not Affect A User Check: * The user is a direct member of the group, or the user matches a realm that assigns the group. * You edited the intended group. * The attribute was saved in the correct check or reply section. * The presence mode applies to the user's current state. * You are reviewing a new authentication attempt after the policy change. Use the group dashboard to confirm members, then use the user detail page to confirm inherited attributes. ## Escalation Details When escalating to Altostrat support or an internal platform owner, include: * Workspace name. * Username. * NAS device name or identifier. * Approximate timestamp and timezone. * Log ID if visible. * Response status or reply message. * Expected group and realm policy. * Recent changes to users, groups, realms, NAS settings, or certificates. # Api base instructions Source: https://altostrat.io/docs/scripts/api-base-instructions # **LLM Prompt: A Blueprint for Stripe-Quality OpenAPI Specifications** ## **Your Mission: To Craft a World-Class Developer Experience** You are an AI Architect specializing in creating world-class, Stripe-quality API documentation. Your mission is not merely to list endpoints, but to craft a developer experience that is clear, intuitive, and empowering. Every description, parameter, and example you write must be guided by the principle of reducing developer friction and accelerating their time-to-first-successful-call. ## **Core Philosophy: The Stripe Standard** Before you write a single line of YAML, internalize these guiding principles derived from the industry's best: * **Developer-Centricity:** Structure everything from the developer's point of view. Anticipate their questions, understand their goals, and provide clear, unambiguous answers. * **Problem-First Approach:** The `info` description must frame the API as a solution to a specific set of problems. A developer should immediately understand *why* they need this service. * **Meticulous Detail:** Every parameter, field, and schema must be documented with absolute clarity. There is no room for ambiguity. Provide helpful context and examples wherever possible. * **Errors as a Feature:** Treat error responses as a core, solvable part of the API. They must be predictable, well-documented, and guide the user toward a solution. ## **Your Core Task & Critical Output Requirement** Your task is to generate a complete and accurate OpenAPI 3.0.3 specification in **YAML format** for a specific Altostrat microservice. I will provide you with the name of the microservice and details about its endpoints. **CRITICAL: Your entire response MUST be a single YAML code block.** Do **NOT** include any introductory text, explanations, or concluding remarks. Your output must begin with `openapi: 3.0.3` and end with the last line of the specification. ## **Global Context & Rules** 1. **Base URL:** All API endpoints must use the base URL `https://api.altostrat.io`. 2. **Product Context:** Altostrat SDX is a platform delivering SD-WAN, network automation, and agentic AI for MikroTik networks, built on a microservices architecture. 3. **Microservice Focus (IMPORTANT):** Your documentation must be laser-focused on the **single microservice provided**. While you will reference its role within the broader Altostrat SDX platform for context, the description and endpoints must exclusively detail the problems this service solves and the resources it manages. *** ## **Blueprint for the `info:` Block** This section is your opening statement. It must be elegant and informative, following this precise four-part formula: * `title:` Must follow the format: `Altostrat [Microservice Name] API`. * `version:` Use `1.0.0`. * `description:` Use a multi-line string (`|-`) structured as follows: 1. **Service Definition:** A single, clear sentence defining the microservice's primary responsibility. * *Example:* "The Altostrat Workspaces API is the microservice responsible for tenancy, billing, and user identity management." 2. **Strategic Context:** Explain its specific role and contribution to the overall Altostrat SDX platform. * *Example:* "It serves as the foundational layer for all multi-tenancy and subscription logic, enabling the secure separation of customer data and resources." 3. **Core Resources (Bulleted List):** A bulleted list of the 2-4 key resources or concepts this **specific API** manages, each with a concise explanation. * *Example:* ``` This API allows you to programmatically manage: - **Workspaces:** The top-level containers for all tenant resources, users, and billing configurations. - **User Access:** The members and their specific roles (Owner, Admin) within a workspace. ``` 4. **Developer's Goal:** A concluding sentence that frames the API's purpose from the developer's perspective. * *Example:* "Developers use this API to build the structural foundation upon which all other Altostrat SDX automation and AI features operate." *** ## **Blueprint for Endpoints, Parameters, and Schemas** * **RESTful Principles:** Endpoints must use plural nouns for resources and a clear hierarchy (e.g., `/workspaces/{workspaceId}/members`). * **Clarity in Summaries:** Each endpoint (`summary`) and parameter (`description`) must have a concise, human-readable explanation. * **Meticulous Schemas:** For every parameter and response field, provide a `description` and a realistic `example`. The description should explain the *purpose* of the field, not just what it is. * **Rich Descriptions:** The endpoint's main `description` field should explain not just *what* it does, but *why* a developer would use it and any important nuances or side effects. *** ## **Blueprint for Error Handling** Every endpoint that can modify state (POST, PUT, PATCH, DELETE) **must** include a documented `4xx` client error and `5xx` server error in its `responses` section. The error schema should be consistent, pointing to a reusable component. * **Example Error Response (`400`):** ```yaml theme={null} responses: "400": description: Bad Request - The request was malformed or invalid. content: application/json: schema: $ref: "#/components/schemas/ErrorResponse" ``` * **Error Schema Component:** ```yaml theme={null} components: schemas: ErrorResponse: type: object properties: type: type: string description: A broad category for the error (e.g., 'invalid_request_error'). example: "invalid_request_error" code: type: string description: A short, unique string identifying the specific error. example: "parameter_missing" message: type: string description: A human-readable description of what went wrong. example: "The 'name' parameter is required for this request." doc_url: type: string description: A direct link to the documentation page for this specific error code. example: "https://docs.altostrat.io/errors/parameter_missing" ``` # Billing and Subscriptions Source: https://altostrat.io/docs/sdx/en/account/billing-and-subscriptions Review billing accounts, subscriptions, license allocation, usage, and limits for your SDX workspace. Billing and subscription data helps you understand what your workspace can use, how licenses are allocated, and whether growth will run into account limits. The exact billing options available to you depend on your workspace and account configuration in the portal. ## Prerequisites * You have permission to view billing or subscription settings. * You know which workspace or organization you are reviewing. * You know whether the question is about current usage, future growth, or finance review. ## What to Review | Area | Use it for | | ---------------- | ----------------------------------------------------------------- | | Billing accounts | Business and billing ownership for the workspace or organization. | | Subscriptions | Active subscription state and what it permits. | | Licenses | Allocation of purchased or available capacity. | | Usage | Current resource consumption against available capacity. | | Limits | Guardrails that can affect onboarding or expansion. | ## Before Onboarding Sites 1. Open the billing or subscription area for the workspace. 2. Confirm the active subscription state. 3. Review available licenses and current usage. 4. Confirm whether the planned onboarding fits within current limits. 5. Resolve billing or license questions before a large rollout. ## Operational Use Cases Use subscription views before bulk onboarding, customer migration, or regional expansion. Use usage views during account review to understand whether growth is tracking with expectations. Use license allocation when different teams, customers, or service tiers need capacity managed deliberately. ## Good Practices Review billing and usage before major site adoption waves. Subscription limits are easier to handle before a field team is waiting to bring routers online. Keep account administrators and finance stakeholders aligned on who owns billing review, who owns license allocation, and who approves expansion. If you are designing customer or department boundaries, start with [Workspaces and Organizations](./workspaces-and-organizations) before tuning billing and subscription allocation. # Account & Billing Source: https://altostrat.io/docs/sdx/en/account/introduction Understand the account structures that organize SDX workspaces, teams, users, roles, billing, subscriptions, and auditability. Account structure determines who can see resources, who can make changes, how teams collaborate, and how subscriptions and usage are organized. In Altostrat SDX, this foundation is built from workspaces, teams, users, roles, billing accounts, subscriptions, API keys, and audit logs. ```mermaid theme={null} flowchart TD Workspace["Workspace"] --> Teams["Teams"] Teams --> Users["Users and roles"] Teams --> Resources["Sites, policies, workflows, and reports"] Workspace --> Billing["Billing accounts and subscriptions"] Workspace --> Audit["Audit logs"] Workspace --> Keys["API keys"] ``` ## What to Configure First Model your operating structure so resources, teams, and customer or business boundaries are clear. Review billing accounts, subscriptions, license allocation, usage, and workspace limits. Add people, assign teams, use roles, and create notification-only users where appropriate. ## Recommended Setup Order 1. Confirm the workspace and organization structure. 2. Create teams around operational boundaries, such as customer, region, department, or support tier. 3. Assign roles that match each person's responsibility. 4. Review subscription and usage state before onboarding many sites. 5. Create API keys only for integrations that need them. 6. Use audit logs to review sensitive changes. Keep teams aligned with how work is actually performed. A clean team model makes policy assignment, reporting, notifications, and incident response easier to reason about. # User and Team Management Source: https://altostrat.io/docs/sdx/en/account/user-and-team-management Add users, organize teams, assign roles, and use notification-only users for alert and report recipients. User and team management controls who can access your SDX resources and what they can do. A clean access model keeps operations fast while reducing unnecessary privilege. ## Prerequisites * You have permission to manage users, teams, or roles. * You know which team the user should belong to. * You know what level of access the user needs. ## Core Concepts | Concept | Purpose | | ---------------------- | --------------------------------------------------------------------------- | | User | A person or recipient record associated with the workspace. | | Team | A group that owns or operates resources. | | Role | A permission set that controls what a user can do. | | Notification-only user | A recipient that can receive alerts or reports without portal login access. | ## Add a User 1. Open **Settings** and select **Teams** or the relevant user management area. 2. Choose the team the user should join. 3. Add the user with the correct email address. 4. Assign a role that matches the work they need to perform. 5. Save the change. 6. Confirm the user appears in the intended team. ## Create a Notification-Only Recipient Use notification-only users when someone needs alerts or reports but should not sign in to the portal. 1. Create or edit the user record. 2. Disable portal login access when the form exposes that option. 3. Add the recipient to the relevant [Notification Groups](../monitoring/notifications). 4. Send or wait for a test notification through the group workflow. ## Role Assignment Assign the least privilege that still lets the user do their job. Operators who manage sites may need different access from billing administrators, security reviewers, workflow builders, or report recipients. Review roles when a person changes responsibility. Removing stale access is just as important as granting new access. ## Offboarding When someone leaves or no longer needs access: 1. Remove them from teams where they should no longer operate. 2. Reassign ownership of workflows, reports, notification groups, or API keys if needed. 3. Revoke or rotate credentials that were used by integrations. 4. Review [Audit Logs](../security/audit-logs) for recent sensitive activity if the departure is security-sensitive. Prefer named users over shared accounts. Named access makes audit review and incident investigation much clearer. # Workspaces and Organizations Source: https://altostrat.io/docs/sdx/en/account/workspaces-and-organizations Model your business or customer structure with workspaces, organizations, teams, and resource ownership. Workspaces and organizations define the operating boundary for your SDX environment. They help you separate customers, business units, teams, subscriptions, and managed resources. ## Prerequisites * You know whether your structure should follow customers, regions, departments, brands, or operating teams. * You know who should administer each area. * You understand which sites and policies belong together. ## Core Concepts | Concept | Purpose | | ------------ | ---------------------------------------------------------------------------------------------------------- | | Workspace | The main portal context where teams, users, resources, subscriptions, billing, and audit logs are managed. | | Organization | A business or customer structure used to organize ownership and account hierarchy. | | Team | An access and ownership boundary for users and resources. | | Role | A permission set assigned to users so they can perform the right actions. | ## Design a Structure 1. Start from the way your operations team works today. 2. Identify boundaries that require separate access, reporting, or billing visibility. 3. Create teams for those boundaries. 4. Keep resource ownership consistent: sites, policies, workflows, reports, and notification groups should live where the responsible team can manage them. 5. Review the model after your first few sites are onboarded. ## Common Patterns Use a customer-based structure when you are an MSP or operator managing separate customer environments. Use a region-based structure when operational responsibility follows geography. Use a department-based structure when internal IT, guest networks, security, and operations need different access boundaries. Use a service-tier structure when policies, reporting, and response expectations differ by contract or support level. ## Good Practices Avoid creating a new workspace or team for every small exception. Too much fragmentation makes reporting, access review, and policy rollout harder. Use tags for flexible grouping inside a team. Tags are often better than extra teams when you only need filtering, reporting, or policy targeting. See [Metadata and Tags](../fleet/metadata-and-tags) for resource grouping that does not require changing ownership boundaries. # Generative AI Source: https://altostrat.io/docs/sdx/en/automation/generative-ai Use AI-assisted features in Altostrat SDX for workflow text transforms, script drafting, diagnostics, and operational support. Altostrat SDX includes AI-assisted surfaces that help operators move faster. AI can draft RouterOS scripts, transform text in workflows, support diagnostics, and help turn operational intent into a first version of an action. AI assistance does not replace operator review. Treat generated output as a draft that must be checked against the site, policy, and change window. ## Where AI Appears Describe a RouterOS task and use AI to create a starting script for review and testing. Use the **AI Text Transform** node to rewrite, summarize, or structure text inside a workflow. Use AI-assisted product surfaces to speed up investigation, explanation, and repetitive operator work. ## Good Uses * Draft a RouterOS script from a precise change request. * Summarize a fault or run payload before sending a notification. * Convert raw JSON or log text into a human-readable incident summary. * Generate first-pass documentation for an internal procedure. * Explain a planned workflow before you activate it. ## Risky Uses Avoid using AI output directly when the action can: * Remove management access. * Change routing, WAN priority, firewall policy, or VPN reachability. * Delete configuration or data. * Touch many sites at once. * Grant access to users or external systems. Use scheduled script testing, workflow node testing, and human approval for these cases. ## Prompting Guidance Give the AI enough operational context: * The site or device role. * The RouterOS version or feature constraint, if relevant. * The exact desired state. * What must not change. * How you want the result formatted. For example, ask for a script that adds a specific firewall rule only if it does not already exist, and state that management access must not be changed. ## Review Checklist Before using AI-generated output: * Confirm every command or field matches your intent. * Remove secrets from prompts and outputs. * Test against a representative non-critical site. * Check whether the change is idempotent. * Use workflow or scheduled script logs to confirm the result. ## Related Pages Test and authorize RouterOS scripts before rollout. Review the AI Text Transform node and other workflow actions. # Automation and AI Source: https://altostrat.io/docs/sdx/en/automation/introduction Use workflows, scheduled scripts, templates, and AI-assisted tools to automate Altostrat SDX operations. Altostrat SDX automation is built for network operations teams that need repeatable work without losing control. You can design visual workflows, run RouterOS scripts through the device job plane, store workflow secrets, and use AI-assisted surfaces to speed up diagnostics or script drafting. The key idea is simple: use the lightest automation tool that still gives you the right safety, auditability, and operational visibility. ## Automation Surfaces Build node-based automations with triggers, actions, conditions, loops, workflow chaining, logs, runs, and authorizations. Execute RouterOS scripts across sites through the SDX job model, with testing, scheduling, authorization, and per-site outcomes. Use AI to draft scripts, transform text in workflows, and accelerate operator tasks while keeping review and approval in your hands. ```mermaid theme={null} flowchart LR Event["Event, schedule, API request, or operator action"] --> Workflow["Workflow"] Workflow --> Action["API, notification, tag, policy, WAN, script, or data action"] Action --> Logs["Runs and logs"] Script["Scheduled script"] --> DeviceJob["Device job plane"] DeviceJob --> Site["Managed site"] AI["AI assistance"] --> Workflow AI --> Script ``` ## Choose The Right Tool | Need | Use | Why | | ---------------------------------------------- | -------------------- | -------------------------------------------------------------------------------------------------- | | React to site, WAN, schedule, or API events | Workflows | The workflow engine gives you branching, variables, conditions, and logs. | | Push RouterOS changes across one or more sites | Scheduled scripts | Scripts run through the platform's asynchronous device job model and can be tested before rollout. | | Transform payloads or create reports | Workflows | Data mapper, parser, text, PDF, notification, and integration nodes keep this work visible. | | Draft a RouterOS script faster | AI script generation | AI can create a starting point, but you still review and test before execution. | | Store tokens, passwords, or signing material | Workflow vault | Vault secrets are not exposed again after creation and can be referenced by workflow nodes. | ## Safety Model Automation in SDX should stay observable: * Give workflows clear names and descriptions. * Keep destructive or network-changing actions behind deliberate authorizations. * Test workflow nodes with representative context before activating the workflow. * Use vault secrets instead of hardcoding credentials in node inputs. * Use scheduled script test runs before multi-site execution. * Review runs, logs, and per-site outcomes after every meaningful automation change. ## Start Here Learn the workflow canvas, node types, context, testing, and logs. Choose between manual, scheduled, API, lifecycle, health, and workflow triggers. Store and reference sensitive values safely. Test, authorize, schedule, and monitor RouterOS scripts. # Script Management Source: https://altostrat.io/docs/sdx/en/automation/script-management Create, test, authorize, schedule, and monitor RouterOS scripts across Altostrat SDX managed sites. Script management is the right tool when you need direct RouterOS control across one or more sites. SDX wraps scripts in an operational lifecycle so changes can be tested, scheduled, authorized, delivered through the device job plane, and audited afterward. Use scripts for device configuration tasks that are easier or more precise in RouterOS than in a workflow node. ## Prerequisites Before you schedule a script, make sure you have: * Permission to create and manage scheduled scripts. * At least one adopted site that can receive jobs. * A script that has been reviewed for RouterOS version compatibility. * A test site for validation. * An authorization path for production execution. ## Script Lifecycle ```mermaid theme={null} stateDiagram-v2 [*] --> Draft Draft --> Test: Run test Draft --> Unauthorized: Save scheduled script Unauthorized --> Scheduled: Authorized Scheduled --> Launched: Launch time reached Launched --> Completed: Site outcomes complete Launched --> Failed: One or more outcomes fail Scheduled --> Canceled: Canceled before launch ``` ## Create And Run A Scheduled Script Go to **Scripts**, open **Scheduled Scripts**, then create a scheduled script. Give it a description that will still make sense in an audit trail later. Choose the sites that should receive the script. Keep the first rollout small unless the script is already proven. Write the RouterOS script directly or start from a template. Keep scripts idempotent so retries or partial rollout recovery do not create duplicate configuration. Set the launch time. For production changes, align it with your maintenance window. Run the script against a test site before scheduling the wider rollout. Move the script through the authorization flow before production execution. Watch each site outcome after launch. Investigate failed outcomes through site logs and orchestration history. ## Templates Templates help you standardize repeatable scripts. Use templates for tasks your team performs more than once, such as: * Adding common firewall rules. * Updating service settings. * Capturing diagnostic state. * Applying a known workaround. * Building version-aware script fragments. Treat templates like production code. Name them clearly, review changes, and test before broad deployment. ## AI-Assisted Script Drafting AI can help draft RouterOS scripts from a natural-language prompt. Use it to speed up first drafts, not to skip review. Before running an AI-generated script: 1. Read every command. 2. Check whether it could remove access, disable services, delete configuration, or change routing. 3. Test it on a non-critical site. 4. Confirm the resulting device state is what you intended. 5. Use the normal authorization flow for production rollout. Never deploy an AI-generated RouterOS script directly to production without human review and a test run. ## Best Practices Check whether objects already exist before adding them. Avoid scripts that fail or duplicate state on a second run. Prove behavior on one test site, then a small cohort, before a fleet-wide launch. Templates reduce copy-paste drift and make operational procedures easier to review. A launched script is not the same as a successful script. Review each site result. ## Related Pages Create rollback points and compare device state before or after script changes. Understand how SDX delivers jobs to routers. # Workflow Authorizations Source: https://altostrat.io/docs/sdx/en/automation/workflows/authorizations Understand how workflow authorizations let SDX workflows perform actions on behalf of users. Workflow authorizations let workflows and AI-assisted operations perform SDX actions on behalf of an authorized user. An authorization stores delegated access for a user in your organization, then workflows can reference it when they need to call protected SDX capabilities. Use authorizations deliberately. They define whose access is being used when a workflow makes platform changes. ## Prerequisites Before you create or assign an authorization, make sure you have: * Permission to create workflows and workflow authorizations. * A user account with the scopes needed by the workflow. * A clear owner for the workflow. * A review process for workflows that change network state. ## How Authorizations Work ```mermaid theme={null} flowchart LR User["Authorized user"] --> Auth["Workflow authorization"] Auth --> Workflow["Workflow"] Workflow --> API["SDX action"] API --> Logs["Workflow runs and logs"] ``` An authorization records: * The user identity. * The email shown in the workflow authorizations table. * The creation date. * The workflows currently using the authorization. Tokens are handled by the workflow service. If an access token expires, the service refreshes it with the stored refresh token when possible. ## Create An Authorization Go to **Automation**, open **Workflows**, then open **Authorizations**. Click **Add**. SDX creates an authorization URL for the login flow. Sign in as the user whose access the workflow should use. The resulting authorization is stored for the organization. When creating or editing a workflow, select the authorization that matches the workflow's operational owner and permissions. ## Revoke An Authorization You can revoke authorizations that are no longer needed. If workflows are still using an authorization, SDX shows the affected workflows and blocks deletion until you remove those dependencies or assign a different authorization. Before revoking: * Check how many workflows use the authorization. * Replace it on active workflows. * Test at least one workflow run with the replacement authorization. * Revoke the old authorization after dependent workflows are updated. ## Authorization Versus Vault | Use | Choose | | ---------------------------------------------------------------- | ----------------------------------------------------------------- | | A workflow needs to call SDX as a user | Workflow authorization | | A workflow needs an external API token, password, or signing key | Workflow vault | | An inbound synchronous workflow needs JWT validation | Authorizer configuration backed by JWKS or vault signing material | ## Best Practices * Create authorizations for service-owned operator accounts when possible, not personal accounts that may leave the organization. * Keep workflow permissions as narrow as your role model allows. * Review authorizations during offboarding. * Watch workflow logs after changing authorizations. * Do not reuse a powerful authorization for unrelated workflows. # Build Workflows Source: https://altostrat.io/docs/sdx/en/automation/workflows/building-workflows Design Altostrat SDX workflows with triggers, actions, conditions, variables, testing, and execution logs. Workflows are visual automation graphs. A trigger starts the run, actions perform work, conditions branch the path, and logs show what happened at each node. Use workflows when you need repeatable operational logic that spans SDX services, external systems, notifications, scripts, policies, tags, reports, or data transformation. ## Prerequisites Before you build a workflow, make sure you have: * Permission to view and create workflows. * A workflow authorization for actions that call SDX on behalf of a user. * Vault secrets for any external API credentials, tokens, passwords, or signing keys. * A sample payload or test context for the event you expect the workflow to handle. ## The Workflow Shape ```mermaid theme={null} flowchart LR Trigger["Trigger"] --> Condition{"Condition"} Condition -->|true| ActionA["Action"] Condition -->|false| ActionB["Action"] ActionA --> Logs["Run logs"] ActionB --> Logs ``` Every workflow should answer four questions: 1. What starts it? 2. What context does it receive? 3. What decisions does it make? 4. What side effects can it create? ## Build A Workflow Go to **Automation**, open **Workflows**, then create a workflow. Give it a name and description that explain the operational intent, not just the implementation. Choose the trigger that matches the source event. For example, use a scheduled trigger for recurring checks, a WAN trigger for failover events, or an API trigger when an external system needs a response. Add nodes that perform the work. Common actions include Altostrat API calls, notifications, tag updates, WAN priority updates, external webhook calls, data transforms, and MikroTik script execution. Use conditions when the workflow should branch based on status, tags, numbers, dates, booleans, arrays, or switch cases. Test nodes with representative input. A node test is most useful when the context matches the event shape the workflow will receive in production. Activate the workflow only after the graph, authorization, and secrets are correct. Watch the first real run and inspect logs for each node. ## Passing Data Between Nodes Workflow nodes can use output from earlier nodes as variables in later node fields. Use this for things like: * Passing a `site_id` from a site trigger into a **Get Site** action. * Using a WAN tunnel ID from a WAN event in a **Get WAN Tunnel** action. * Sending transformed text into a notification. * Mapping an external payload into the exact shape another API expects. Keep variable paths readable. If a payload is complex, use **JSON Parser**, **Data Mapper**, or **Text Transform** nodes to normalize the shape before later actions depend on it. ## Design Patterns Start from a platform event, enrich it with site or WAN data, then notify the right group or create an external ticket. Run on a schedule, fetch site state, filter by tags or conditions, and produce a notification or report artifact. Put common logic in a workflow-triggered workflow, then call it from multiple parent workflows. Check tags, policy state, or service status before making a network-changing call. ## Validation And Loops SDX validates workflow structure before saving. Workflows that trigger other workflows cannot create circular dependencies, and a workflow cannot trigger itself. For lists, use **Loop / Iterator** carefully. Keep the loop body small, constrain the item list, and make downstream actions idempotent so a retried run does not duplicate work. ## Related Pages Compare trigger types and event sources. Review the current trigger, action, condition, and loop node catalog. # Workflow Node Reference Source: https://altostrat.io/docs/sdx/en/automation/workflows/node-reference A practical reference for the trigger, action, condition, and loop nodes available in Altostrat SDX workflows. This reference summarizes the workflow nodes exposed by the SDX workflow builder. Use it while designing a workflow or reviewing whether a task belongs in workflows, scripts, or another SDX feature. ## Trigger Nodes | Node | Use it for | | --------------------------- | -------------------------------------------------------------------- | | Manual Trigger | Start a workflow from the UI or an explicit operator action. | | Scheduled Trigger | Run a workflow on a recurring schedule. | | API Trigger (Synchronous) | Accept an API request and return a workflow-generated HTTP response. | | Trigger by Another Workflow | Make a workflow callable from another workflow. | | Subflow Trigger | Start a workflow as an internal subflow. | | Site Added | React when a new site is added. | | Site Removed | React when a site is removed. | | Site Offline | React when a site stops checking in. | | Site Online | React when a site resumes heartbeats. | | WAN Interface Offline | React when a WAN failover interface goes offline. | | WAN Interface Online | React when a WAN failover interface comes online. | | WAN Packet Loss | React when WAN packet loss is detected. | | WAN Packet Loss Resolved | React when packet loss recovers. | ## Altostrat And MikroTik Actions | Node | Use it for | | --------------------- | ------------------------------------------------------------- | | Altostrat API Call | Call SDX API endpoints from a workflow. | | Get Site | Retrieve site details and configuration. | | Get WAN Tunnel | Retrieve WAN tunnel details and status. | | Get Resource Tags | Read tags from a resource. | | Set Resource Tags | Add or update tags on a resource. | | Attach Policy | Attach a policy to a site. | | Detach Policy | Remove a policy from a site. | | Update WAN Priorities | Change WAN failover priority order for a site. | | MikroTik API | Run a real-time command against a site. | | MikroTik Script | Dispatch a RouterOS script or configuration change to a site. | ## Integration Actions | Node | Use it for | | ------------------------ | ---------------------------------------------------------------- | | Webhook/API Call | Send HTTP requests to external APIs. | | SOAP Request | Call legacy SOAP services. | | SSH Command | Execute commands on a remote server over SSH. | | Send Email (SMTP) | Send an email through a configured SMTP server. | | Send Notification | Send SDX notifications through configured notification channels. | | Trigger Another Workflow | Start another workflow from the current workflow. | ## Data And Document Actions | Node | Use it for | | ----------------- | ------------------------------------------------------ | | AI Text Transform | Use an AI prompt to transform text or structured data. | | Text Transform | Render text from workflow data using templates. | | JSON Parser | Parse JSON input for later nodes. | | Data Mapper | Map values into a new object or array shape. | | Date Transform | Add, subtract, or format dates. | | String Transform | Apply string operations to a value. | | Validate Data | Validate data using rules before continuing. | | Filter Array | Keep only array items that match conditions. | | Markdown to PDF | Convert Markdown content into a PDF artifact. | | Shorten Link | Create a shortened link from a long URL. | | Ingest Metrics | Send custom metrics for monitoring and analysis. | ## Network And Security Tools | Node | Use it for | | ----------------------- | ------------------------------------------------------ | | IPv4 Address Tool | Analyze an IPv4 address or CIDR range. | | WireGuard Key Generator | Generate a WireGuard key pair or derive a public key. | | CVE Scan Multiple IPs | Start an immediate CVE scan for multiple IP addresses. | ## Conditions And Flow Control | Node | Use it for | | ---------------------- | -------------------------------------------------------- | | String Condition | Branch on text values. | | Number Condition | Branch on numeric comparisons. | | Date Condition | Branch on date or time logic. | | Boolean Condition | Branch on true or false values. | | Array Condition | Branch on array contents or count. | | Resource Has Tags | Branch based on resource tags. | | Switch | Create multiple branches from cases. | | Logical Group (AND/OR) | Combine multiple rules into one decision. | | Loop / Iterator | Process each item in a list. | | Terminate | Stop the workflow and mark the path completed or failed. | ## Selection Guidance If the workflow needs site, tag, policy, WAN, notification, or script behavior, prefer built-in Altostrat nodes over generic HTTP calls. Normalize payloads before conditions. Clean data makes workflow paths easier to test and debug. External APIs, SMTP, SOAP, SSH, and signing keys should read credentials from vault items rather than plain node fields. Use loops for small, deliberate lists. For fleet-wide device changes, consider scheduled scripts or purpose-built SDX actions. # AI Text Transform Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/ai-text-transform Format text and data using AI prompts. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Summarize raw incident notes into a concise status update. * Normalize free-form user input into structured categories. ## Configuration Checklist 1. Provide a clear prompt and structured input data. 2. Constrain output format if downstream nodes depend on it. 3. Validate output using condition or validate action. 4. Store normalized text/object output for subsequent steps. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Use deterministic prompt instructions when the output feeds strict parsers. # API Call Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-api-call Make HTTP requests to Altostrat API endpoints. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Read/update records in Altostrat APIs during automation. * Integrate workflow logic with existing internal API endpoints. ## Configuration Checklist 1. Configure HTTP method and endpoint. 2. Map headers, query params, or payload fields from context. 3. Parse response data and pass important fields downstream. 4. Branch on status code or response body values. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Treat API response schemas as contracts and version them when possible. # Attach Policy Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-attach-policy Attach a policy to a site. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Apply security baseline policy to new sites. * Attach temporary lockdown policy during incident response. ## Configuration Checklist 1. Set site identifier and policy type. 2. Optionally fetch site metadata before attachment. 3. Attach policy and branch on API response status. 4. Log or notify outcomes for audit visibility. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Detach Policy Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-detach-policy Remove a policy from a site. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Remove temporary emergency controls after recovery. * Clean up old policy assignments during migration. ## Configuration Checklist 1. Set site identifier and target policy type. 2. Optionally validate policy currently exists on the site. 3. Detach policy and verify response success. 4. Notify stakeholders of policy state change. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Get Resource Tags Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-get-resource-tags Retrieve tags associated with a resource (site). Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Route alerts by `environment` or `region` tags. * Check if mandatory tags exist before deployment actions. ## Configuration Checklist 1. Set resource/site ID. 2. Retrieve current tag set. 3. Use tag conditions to drive branch logic. 4. Optionally pass tags into notifications or API calls. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Get Site Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-get-site Retrieve detailed site information and configuration. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Lookup site owner/team before sending alerts. * Fetch site state before policy or WAN changes. ## Configuration Checklist 1. Set site ID from trigger payload or upstream node output. 2. Execute action to fetch full site metadata. 3. Map returned fields into conditions or notifications. 4. Use data to enrich downstream decisions. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Get WAN Tunnel Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-get-wan Retrieve detailed WAN tunnel information and status. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Enrich WAN outage events with tunnel metadata. * Validate tunnel state before rerouting traffic. ## Configuration Checklist 1. Set both site ID and WAN tunnel ID. 2. Fetch tunnel details and current health status. 3. Evaluate values via conditions for branching. 4. Use outputs for escalation, remediation, or reporting. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # MikroTik Script Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-run-async-script Run scripts or config changes on a site. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Apply configuration change scripts to remote sites. * Run periodic maintenance scripts without blocking workflow runtime. ## Configuration Checklist 1. Set target site and script body or script reference. 2. Provide required script parameters from workflow context. 3. Trigger async execution and capture job metadata. 4. Add follow-up checks if script completion must be verified. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # MikroTik API Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-run-sync-command Run a real-time API command on a specific site. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Run read-only diagnostics on a failing edge router. * Collect immediate interface statistics during incidents. ## Configuration Checklist 1. Set target site and command to execute. 2. Use conservative command scopes for live systems. 3. Capture command output and branch on success indicators. 4. Record outputs needed for auditing or troubleshooting. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer read-only commands unless a clear change-control path exists. # Set Resource Tags Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-set-resource-tags Add or update tag key-value pairs for a resource. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Auto-tag newly discovered sites with onboarding metadata. * Stamp incident ticket IDs onto affected resources. ## Configuration Checklist 1. Set resource/site ID and key/value tags to apply. 2. Prepare tags from mapped context values when needed. 3. Execute update and verify tag count/result. 4. Optionally re-fetch tags to confirm final state. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Update WAN Priorities Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/altostrat-update-wan-priorities Update WAN failover link priorities for a site. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Promote backup link during prolonged degradation. * Revert WAN priorities after maintenance window completion. ## Configuration Checklist 1. Provide target site and WAN priority list. 2. Validate desired order before applying updates. 3. Execute update and verify resulting configuration. 4. Notify operations if changes affect critical traffic paths. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Filter Array Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/array-filter Create a new array with only the items that match your conditions. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Keep only critical alerts from a mixed event list. * Filter resources by status before batch operations. ## Configuration Checklist 1. Set input array path from context. 2. Define one or more filter conditions. 3. Execute and inspect resulting subset. 4. Pass filtered data into iterator or API action nodes. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Shorten Link Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/create-short-link Create a short link from a long URL. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Send compact links in SMS or chat notifications. * Share temporary runbook/report URLs in incident alerts. ## Configuration Checklist 1. Set target long URL (redirect destination). 2. Generate short link and capture returned short URL. 3. Embed short URL into notifications or reports. 4. Optionally track by attaching context metadata in message text. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # CVE Scan Multiple IPs Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/cve-scan-multiple-ips Initiate an immediate CVE scan for multiple IP addresses. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Launch immediate scans after threat intelligence updates. * Scan newly discovered assets in onboarding workflows. ## Configuration Checklist 1. Provide target site and list of IP addresses. 2. Optionally pre-filter IP list to keep scan scope focused. 3. Trigger scan and capture returned job/result identifiers. 4. Notify security teams with scan initiation or findings summary. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Data Mapper Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/data-mapper-action Create or modify objects and arrays by mapping data. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Normalize event payloads from multiple trigger sources. * Prepare a canonical object for downstream integrations. ## Configuration Checklist 1. Define target object/array schema. 2. Map source paths from trigger/action outputs to target fields. 3. Set defaults for optional fields. 4. Use mapped object in API calls or document generation. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Date Transform Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/date-transform-action Modify dates, add/subtract time, or change formats. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Calculate maintenance end time from start + duration. * Convert timestamps to human-readable local time for alerts. ## Configuration Checklist 1. Provide input date/time value and operation (format/add/subtract). 2. Set timezone/format expectations where relevant. 3. Generate transformed date output. 4. Use result for scheduling windows or message formatting. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Ingest Metrics Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/ingest-metrics Send custom metrics to Prometheus for monitoring and analysis. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Publish custom workflow KPIs to Prometheus. * Emit incident-related metrics for SLO tracking. ## Configuration Checklist 1. Define metric names, values, labels, and entity context. 2. Map dynamic values from workflow payloads. 3. Send metrics and confirm ingestion response. 4. Use dashboards/alerts to validate metric usefulness. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # IPv4 Address Tool Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/ipv4-address Analyze an IPv4 address or CIDR range. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Validate whether an IP belongs to an approved subnet. * Compute addressing details for onboarding automation. ## Configuration Checklist 1. Set IPv4 or CIDR input value. 2. Run analysis to extract network details. 3. Branch on subnet or host-level checks. 4. Use derived network values in downstream logic. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # JSON Parser Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/json-parser Parse JSON data and extract values. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Extract IDs and statuses from API response bodies. * Parse webhook payloads before branching logic. ## Configuration Checklist 1. Provide raw JSON string or object payload. 2. Configure extraction paths for required fields. 3. Use extracted values in downstream nodes. 4. Add validation/condition checks when payloads are unstable. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Markdown to PDF Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/markdown-pdf Convert Markdown content to PDF format. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Generate post-incident summary documents. * Create recurring compliance reports in PDF format. ## Configuration Checklist 1. Compose markdown content using workflow context variables. 2. Generate PDF output from markdown. 3. Store or forward the generated document reference. 4. Attach the result in email or ticketing workflows. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Overview Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/overview Reference for workflow action nodes, including action categories, typical use cases, and links to detailed per-action documentation. Action nodes are the execution steps in your workflow. They transform data, call APIs, notify people, and perform platform operations after a trigger has started the run. ## How To Use Action Nodes 1. Place actions after a trigger or branch decision. 2. Map input values from workflow context (for example `trigger.*` or prior node outputs). 3. Validate response shape before dependent downstream logic. 4. Add failure handling for operations with external side effects. ## Choosing The Right Action * Use **Advanced Actions** when orchestrating APIs and cross-workflow behavior. * Use **Data Processing** actions to parse, map, validate, and transform payloads. * Use **Communication** actions for human-facing notifications. * Use **Network/Security** actions for infrastructure tasks and key generation. * Use **Flow Control** actions to terminate or route execution intentionally. ## Action Types Start another workflow from this one. [View](./trigger-workflow-action) Make HTTP requests to Altostrat API endpoints. [View](./altostrat-api-call) Send HTTP requests to external APIs and webhook endpoints. [View](./webhook-api-call) Interact with legacy SOAP web services. [View](./soap-action) Format text and data using AI prompts. [View](./ai-text-transform) Attach a policy to a site. [View](./altostrat-attach-policy) Remove a policy from a site. [View](./altostrat-detach-policy) Update WAN failover link priorities for a site. [View](./altostrat-update-wan-priorities) Run a real-time API command on a specific site. [View](./altostrat-run-sync-command) Retrieve detailed site information and configuration. [View](./altostrat-get-site) Retrieve detailed WAN tunnel information and status. [View](./altostrat-get-wan) Retrieve tags associated with a resource (site). [View](./altostrat-get-resource-tags) Add or update tag key-value pairs for a resource. [View](./altostrat-set-resource-tags) Run scripts or config changes on a site. [View](./altostrat-run-async-script) Format text and data using custom templates. [View](./text-transform) Parse JSON data and extract values. [View](./json-parser) Create a short link from a long URL. [View](./create-short-link) Convert Markdown content to PDF format. [View](./markdown-pdf) Send notifications via email or WhatsApp. [View](./send-notification) Create or modify objects and arrays by mapping data. [View](./data-mapper-action) Modify dates, add/subtract time, or change formats. [View](./date-transform-action) Perform a series of transformations on a string. [View](./string-transform) Validate an object or array using Laravel rules. [View](./validate) Analyze an IPv4 address or CIDR range. [View](./ipv4-address) Generate a new key pair or derive a public key. [View](./wireguard-key-generator) Create a new array with only the items that match your conditions. [View](./array-filter) Stop the workflow with a "Completed" or "Failed" status. [View](./terminate-action) Send an email via a custom SMTP server. [View](./smtp-action) Execute commands on a remote server via SSH. [View](./ssh-action) Initiate an immediate CVE scan for multiple IP addresses. [View](./cve-scan-multiple-ips) Send custom metrics to Prometheus for monitoring and analysis. [View](./ingest-metrics) ## Action Design Best Practices * Keep each action focused on one responsibility. * Normalize and validate data before branching or calling external systems. * Treat API responses as contracts and guard against missing fields. * Use retries and fallback paths for critical notifications and integrations. # Send Notification Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/send-notification Send notifications via email or WhatsApp. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Send outage notifications to on-call groups. * Deliver daily success/failure summaries to operations. ## Configuration Checklist 1. Choose notification channel and recipients/user tags. 2. Build message body using context values. 3. Set priority/severity metadata if supported. 4. Use conditions to reduce noise for low-impact events. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Send Email (SMTP) Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/smtp-action Send an email via a custom SMTP server. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Send branded email alerts through organization SMTP. * Deliver periodic PDF reports to distribution lists. ## Configuration Checklist 1. Configure SMTP server credentials and sender details. 2. Set recipients, subject, and body with context variables. 3. Send and inspect delivery response/errors. 4. Add retries or fallback channels for critical alerts. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Use secret storage for SMTP credentials. # SOAP Request Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/soap-action Interact with legacy SOAP web services. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Integrate with legacy ticketing or ERP services. * Submit provisioning requests to older SOAP-only systems. ## Configuration Checklist 1. Set WSDL URL and target SOAP operation. 2. Build SOAP input payload from workflow context. 3. Execute and parse result for downstream conditions/actions. 4. Handle SOAP faults explicitly with error branches. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # SSH Command Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/ssh-action Execute commands on a remote server via SSH. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Run remote diagnostics on an external appliance. * Execute controlled remediation commands during incidents. ## Configuration Checklist 1. Set SSH host, port, auth method, and command list. 2. Inject context values carefully into commands. 3. Capture stdout/stderr and evaluate command exit behavior. 4. Branch to rollback/escalation steps when command execution fails. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Treat SSH commands as high-risk side effects and test on non-prod first. # String Transform Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/string-transform Perform a series of transformations on a string. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Normalize hostnames/labels before API updates. * Sanitize user-provided strings for reporting output. ## Configuration Checklist 1. Set input string and define transformation pipeline. 2. Apply operations like trim/replace/case conversion. 3. Validate output before using in strict APIs. 4. Pass cleaned value to downstream actions. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Terminate Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/terminate-action Stop the workflow with a 'Completed' or 'Failed' status. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Fail fast when validation or prechecks do not pass. * Mark workflow complete after final success notification. ## Configuration Checklist 1. Add Terminate where the workflow should stop explicitly. 2. Choose final status (`completed` or `failed`). 3. Optionally set context fields used by reporting/response. 4. Use in both happy and error paths for predictable endings. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Text Transform Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/text-transform Format text and data using custom templates. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Format alert messages consistently across channels. * Build dynamic JSON payload fragments from context data. ## Configuration Checklist 1. Provide input text/object and transformation template. 2. Render output and validate expected format. 3. Reuse transformed values in notifications or API payloads. 4. Keep templates versioned for repeatability. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Trigger Another Workflow Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/trigger-workflow-action Start another workflow from this one. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Call a shared alerting workflow from many event workflows. * Chain onboarding workflow stages across separate owners. ## Configuration Checklist 1. Select the target workflow configured with Workflow Trigger. 2. Map and pass required variables to the target workflow. 3. Define behavior for success/failure of the child workflow call. 4. Use this for reusable building-block workflows. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Validate Data Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/validate Validate an object or array using Laravel rules. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Reject malformed API-trigger payloads early. * Validate mapped data before provisioning actions. ## Configuration Checklist 1. Provide input object/array to validate. 2. Define Laravel-style validation rules. 3. Branch on validation success/failure. 4. Return detailed errors through notifications or API response nodes. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Prefer small, composable actions over one large action with many responsibilities. # Webhook API Call Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/webhook-api-call Send HTTP requests to external APIs and webhook endpoints. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Push event data to third-party webhook endpoints. * Read or update records in external REST APIs. * Trigger downstream automations in other platforms. ## Configuration Checklist 1. Select HTTP method: `GET`, `POST`, `PUT`, `PATCH`, or `DELETE`. 2. Enter a full HTTPS URL (variables supported). 3. Add required headers (static text, workflow variables, or `vlt_...` vault references). 4. For `POST`, `PUT`, or `PATCH`, define a valid JSON request body. 5. Add error handling branches for non-2xx responses and timeouts. ## Field Behavior * **Method:** Controls request type and whether the body editor is shown. * **Webhook URL:** Must be a full HTTPS endpoint. * **Headers:** Dynamic key/value list. Add or remove headers as needed. * **Request Body (JSON):** Available only for `POST`, `PUT`, and `PATCH`. * **Body Reset Rule:** If method changes to `GET` or `DELETE`, body is cleared. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor (`method`, `url`, `headers`, `body`). * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds HTTP response data to the workflow context for downstream nodes. * Can produce external side effects in third-party systems. * Can emit data used by downstream conditions and actions. ## Failure Modes * Invalid or non-HTTPS URL. * Missing/invalid authentication headers. * External API failures (4xx/5xx responses, DNS/TLS issues, timeouts, rate limits). * Invalid JSON body for write methods (`POST`, `PUT`, `PATCH`). ## Best Practices * Store secrets in Vault and reference them via `vlt_...` in headers. * Keep payloads minimal and validate required fields before sending. * Use idempotency keys for retry-safe write operations where supported. * Treat `DELETE` calls as high-risk and add explicit approval logic upstream. # WireGuard Key Generator Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/actions/wireguard-key-generator Generate a new key pair or derive a public key. Actions do the actual work in a workflow: API calls, transformations, notifications, flow control, and integrations. Use this action when your workflow needs to perform an operation, call an external service, or transform data for downstream nodes. ## When To Use * Generate WireGuard credentials during site onboarding. * Derive missing public keys from pre-existing private keys. ## Configuration Checklist 1. Choose mode: generate new key pair or derive public key. 2. Provide private key when deriving only. 3. Capture output keys and route securely. 4. Store sensitive values in vault/secret management flows. ## Inputs * Required `node.data` metadata: `uiId`, `componentId`, and `operation` (for actions that define an operation). * Action-specific configuration fields from the node editor. * Upstream context values from triggers or previous nodes (for example `trigger.*` or prior action outputs). ## Outputs * Adds action result data to the workflow context for downstream nodes. * May produce external side effects (API updates, notifications, scripts, SSH commands, etc.). * Can emit structured values consumed by conditions or subsequent actions. ## Failure Modes * Missing required configuration or invalid parameter values. * Missing/invalid context variable references from upstream nodes. * External dependency failures (HTTP errors, auth failures, timeouts, rate limits). * Payload validation/parsing errors during request or response handling. ## Best Practices * Do not expose private keys in plain-text notifications or logs. # Array Condition Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/conditions/array-condition Check conditions on arrays and their elements. Conditions evaluate context data and branch execution into true/false paths. This condition evaluates runtime data and routes execution based on whether the configured logic matches. ## When To Use * Proceed only when affected-sites list is non-empty. * Branch when required tags are missing from an array. ## Configuration Checklist 1. Set input array path. 2. Choose array operator (contains, empty, length checks, etc.). 3. Configure operator-specific values. 4. Use branches to handle empty vs non-empty outcomes. ## Inputs * `node.data` metadata (`uiId`, `componentId`) and condition-specific operands/operators. * Context values from trigger/action outputs to evaluate. * Optional array/object inputs depending on the condition type. ## Outputs * Routes execution through `true` and `false` branches. * Optionally emits evaluation details for debugging (implementation-dependent). * Determines which downstream path executes next. ## Failure Modes * Missing operand values or invalid operator selection. * Data type mismatches (for example string vs number vs date). * Misconfigured complex expressions (switch/logical group cases). * Unconnected branches creating dead-end workflow paths. ## Best Practices * Connect this where branching is required and make sure downstream edges use true/false handles. * Always wire both branches to avoid dead ends in production runs. # Boolean Condition Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/conditions/boolean-condition Check conditions on boolean values. Conditions evaluate context data and branch execution into true/false paths. This condition evaluates runtime data and routes execution based on whether the configured logic matches. ## When To Use * Continue only when `is_approved` is true. * Branch into remediation when `health_ok` is false. ## Configuration Checklist 1. Provide boolean input path. 2. Choose expected boolean state. 3. Route true/false to explicit next actions. 4. Use after validation/check actions that return boolean flags. ## Inputs * `node.data` metadata (`uiId`, `componentId`) and condition-specific operands/operators. * Context values from trigger/action outputs to evaluate. * Optional array/object inputs depending on the condition type. ## Outputs * Routes execution through `true` and `false` branches. * Optionally emits evaluation details for debugging (implementation-dependent). * Determines which downstream path executes next. ## Failure Modes * Missing operand values or invalid operator selection. * Data type mismatches (for example string vs number vs date). * Misconfigured complex expressions (switch/logical group cases). * Unconnected branches creating dead-end workflow paths. ## Best Practices * Connect this where branching is required and make sure downstream edges use true/false handles. * Always wire both branches to avoid dead ends in production runs. # Date Condition Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/conditions/date-condition Check conditions on dates and times. Conditions evaluate context data and branch execution into true/false paths. This condition evaluates runtime data and routes execution based on whether the configured logic matches. ## When To Use * Trigger renewal reminders before certificate expiry. * Skip disruptive actions during business hours. ## Configuration Checklist 1. Set date/time input and date comparison operator. 2. Choose reference date (fixed or computed). 3. Branch by maintenance window or expiry logic. 4. Ensure timezone handling matches your policy. ## Inputs * `node.data` metadata (`uiId`, `componentId`) and condition-specific operands/operators. * Context values from trigger/action outputs to evaluate. * Optional array/object inputs depending on the condition type. ## Outputs * Routes execution through `true` and `false` branches. * Optionally emits evaluation details for debugging (implementation-dependent). * Determines which downstream path executes next. ## Failure Modes * Missing operand values or invalid operator selection. * Data type mismatches (for example string vs number vs date). * Misconfigured complex expressions (switch/logical group cases). * Unconnected branches creating dead-end workflow paths. ## Best Practices * Connect this where branching is required and make sure downstream edges use true/false handles. * Always wire both branches to avoid dead ends in production runs. # Logical Group (AND/OR) Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/conditions/logical-group-condition Combine multiple conditions with complex AND/OR logic. Conditions evaluate context data and branch execution into true/false paths. This condition evaluates runtime data and routes execution based on whether the configured logic matches. ## When To Use * Escalate only when multiple risk signals are all present. * Allow progression when any one of several prerequisites is met. ## Configuration Checklist 1. Add multiple rules inside one logical group. 2. Choose group logic (`AND` or `OR`). 3. Nest groups if you need more complex expressions. 4. Test with representative payload combinations. ## Inputs * `node.data` metadata (`uiId`, `componentId`) and condition-specific operands/operators. * Context values from trigger/action outputs to evaluate. * Optional array/object inputs depending on the condition type. ## Outputs * Routes execution through `true` and `false` branches. * Optionally emits evaluation details for debugging (implementation-dependent). * Determines which downstream path executes next. ## Failure Modes * Missing operand values or invalid operator selection. * Data type mismatches (for example string vs number vs date). * Misconfigured complex expressions (switch/logical group cases). * Unconnected branches creating dead-end workflow paths. ## Best Practices * Connect this where branching is required and make sure downstream edges use true/false handles. * Always wire both branches to avoid dead ends in production runs. # Number Condition Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/conditions/number-condition Check conditions on numbers and numeric values. Conditions evaluate context data and branch execution into true/false paths. This condition evaluates runtime data and routes execution based on whether the configured logic matches. ## When To Use * Escalate when packet loss exceeds threshold. * Branch based on retry count or risk score. ## Configuration Checklist 1. Set numeric input path and operator (`>`, `<`, `==`, etc.). 2. Provide threshold value. 3. Connect true branch for escalation, false for normal flow. 4. Test boundary values to avoid off-by-one behavior. ## Inputs * `node.data` metadata (`uiId`, `componentId`) and condition-specific operands/operators. * Context values from trigger/action outputs to evaluate. * Optional array/object inputs depending on the condition type. ## Outputs * Routes execution through `true` and `false` branches. * Optionally emits evaluation details for debugging (implementation-dependent). * Determines which downstream path executes next. ## Failure Modes * Missing operand values or invalid operator selection. * Data type mismatches (for example string vs number vs date). * Misconfigured complex expressions (switch/logical group cases). * Unconnected branches creating dead-end workflow paths. ## Best Practices * Connect this where branching is required and make sure downstream edges use true/false handles. * Always wire both branches to avoid dead ends in production runs. # Overview Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/conditions/overview Condition nodes branch workflow execution by evaluating expressions against the current context. # Condition Nodes Condition nodes add decision logic to your workflow. They evaluate runtime values and route execution based on whether the configured rule matches. ## How To Use Condition Nodes 1. Configure comparison inputs and operators. 2. Connect explicit branch handles (`true`/`false` or case handles for switch). 3. Keep branch outcomes intentional (for example escalate vs continue). 4. Test all branch paths before enabling in production. ## Choosing The Right Condition Type * **String/Number/Date/Boolean** for single-value checks. * **Array** for list membership and count-based checks. * **Switch** for multi-path routing based on ordered case matching. * **Logical Group** for nested AND/OR expression trees. ## Condition Types Check conditions on strings and text. [View](./string-condition) Check conditions on numbers and numeric values. [View](./number-condition) Check conditions on dates and times. [View](./date-condition) Check conditions on boolean values. [View](./boolean-condition) Check conditions on arrays and their elements. [View](./array-condition) Create multiple branches based on different conditions. [View](./switch-condition) Combine multiple conditions with complex AND/OR logic. [View](./logical-group-condition) Check if a resource has specific tags or any tags at all. [View](./resource-has-tags-condition) ## Condition Design Best Practices * Align operand types before comparison (string vs number vs date). * Prefer explicit thresholds and named handles for readability. * Always connect every branch to avoid dead-end paths. * Add observability actions on critical false/error branches. # Resource Has Tags Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/conditions/resource-has-tags-condition Check if a resource has specific tags or any tags at all. Conditions evaluate context data and branch execution into true/false paths. This condition evaluates runtime data and routes execution based on whether the configured logic matches. ## When To Use * Enforce that production resources carry mandatory tags. * Route to different teams based on ownership tag presence. ## Configuration Checklist 1. Set the target resource identifier. 2. Choose check mode (any tags, key exists, key/value, tag count). 3. Configure mode-specific fields. 4. Branch based on tag policy compliance. ## Inputs * `node.data` metadata (`uiId`, `componentId`) and condition-specific operands/operators. * Context values from trigger/action outputs to evaluate. * Optional array/object inputs depending on the condition type. ## Outputs * Routes execution through `true` and `false` branches. * Optionally emits evaluation details for debugging (implementation-dependent). * Determines which downstream path executes next. ## Failure Modes * Missing operand values or invalid operator selection. * Data type mismatches (for example string vs number vs date). * Misconfigured complex expressions (switch/logical group cases). * Unconnected branches creating dead-end workflow paths. ## Best Practices * Connect this where branching is required and make sure downstream edges use true/false handles. * Always wire both branches to avoid dead ends in production runs. # String Condition Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/conditions/string-condition Check conditions on strings and text. Conditions evaluate context data and branch execution into true/false paths. This condition evaluates runtime data and routes execution based on whether the configured logic matches. ## When To Use * Route alerts by environment prefix in resource names. * Skip workflow path when message contains ignore tokens. ## Configuration Checklist 1. Select input string and comparison operator. 2. Set target comparison value or pattern. 3. Wire true/false branches to different follow-up actions. 4. Test with mixed-case and edge input values. ## Inputs * `node.data` metadata (`uiId`, `componentId`) and condition-specific operands/operators. * Context values from trigger/action outputs to evaluate. * Optional array/object inputs depending on the condition type. ## Outputs * Routes execution through `true` and `false` branches. * Optionally emits evaluation details for debugging (implementation-dependent). * Determines which downstream path executes next. ## Failure Modes * Missing operand values or invalid operator selection. * Data type mismatches (for example string vs number vs date). * Misconfigured complex expressions (switch/logical group cases). * Unconnected branches creating dead-end workflow paths. ## Best Practices * Connect this where branching is required and make sure downstream edges use true/false handles. * Always wire both branches to avoid dead ends in production runs. # Switch Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/conditions/switch-condition Create multiple branches based on different conditions. Conditions evaluate context data and branch execution into true/false paths. This condition evaluates runtime data and routes execution based on whether the configured logic matches. ## When To Use * Route by event type to different remediation paths. * Choose notification channel based on severity class. ## Configuration Checklist 1. Define a source value to evaluate. 2. Add cases for expected values and a default branch. 3. Connect each case to the corresponding action path. 4. Keep case values mutually exclusive when possible. ## Inputs * `node.data` metadata (`uiId`, `componentId`) and condition-specific operands/operators. * Context values from trigger/action outputs to evaluate. * Optional array/object inputs depending on the condition type. ## Outputs * Routes execution through `true` and `false` branches. * Optionally emits evaluation details for debugging (implementation-dependent). * Determines which downstream path executes next. ## Failure Modes * Missing operand values or invalid operator selection. * Data type mismatches (for example string vs number vs date). * Misconfigured complex expressions (switch/logical group cases). * Unconnected branches creating dead-end workflow paths. ## Best Practices * Connect this where branching is required and make sure downstream edges use true/false handles. * Always wire both branches to avoid dead ends in production runs. # Loop / Iterator Node Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/loop-iterator/README Reference for the Loop / Iterator node, including when to use it, how it processes arrays, and practices for reliable per-item execution. Loop / Iterator is a flow-control node used for per-item processing. It runs a nested workflow for each element in an input array, then returns control to the main workflow path. ## When To Use Loop / Iterator * You need to perform the same action for each item in a list. * You need per-item branching logic before continuing the main flow. * You need to aggregate results from repeated operations. ## Configuration Checklist 1. Map an input path that resolves to an array. 2. Define nested steps that run for each item. 3. Reference item-scoped variables inside nested nodes. 4. Validate behavior with small and large sample arrays. ## Inputs * Node metadata (`uiId`, `componentId`) for iterator runtime. * Input array path sourced from trigger or upstream action output. * Nested sub-workflow steps that execute for each item. ## Outputs * Executes nested nodes once for each array item. * Produces per-item outputs inside iterator scope. * Returns loop completion and resulting context to downstream nodes. ## Failure Modes * Input path is missing or does not resolve to an array. * Per-item node failures interrupt or fail loop execution. * Very large arrays causing long execution time or timeout risk. * Missing item field references in nested iterator logic. ## Best Practices * Pre-filter arrays before iteration when possible. * Keep nested workflows small and single-purpose. * Capture and log per-item failures for easier troubleshooting. * Avoid heavy nested loops; prefer pre-filtering arrays first. # Overview Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/overview Reference for workflow trigger nodes, including scheduling, event-driven triggers, and synchronous API-triggered execution. Trigger nodes start workflow execution. Every workflow must define exactly one trigger that determines when and how a run begins. ## How To Use Trigger Nodes 1. Choose one trigger only for the workflow entry point. 2. Configure trigger-specific parameters (schedule, event source, or API mode). 3. Connect trigger output to the first processing step. 4. Test with representative payloads and verify downstream context values. ## Choosing The Right Trigger * Use **Scheduled Trigger** for recurring maintenance and reporting. * Use **API Trigger (Synchronous)** when another system must invoke workflow execution directly. * Use **SNS-based lifecycle/health triggers** for event-driven automation from platform signals. * Use **Workflow Trigger** to create reusable callable sub-workflows. ## Trigger Types Start this workflow via an API call or the UI. [View](./trigger) Call this workflow from another workflow. [View](./workflow-trigger) Run this workflow on a recurring schedule. [View](./scheduled-trigger) Trigger this workflow via API call with synchronous execution. [View](./sync-request-trigger) Trigger this workflow when a new site is added. [View](./site-added) Trigger this workflow when a site is removed. [View](./site-removed) Trigger when a WAN interface from a WAN failover goes offline. [View](./wan-offline) Trigger when a WAN interface from a WAN failover experiences packet loss. [View](./wan-packet-loss) Trigger when a WAN interface from a WAN failover recovers from packet loss. [View](./wan-packet-loss-resolved) Trigger when a WAN interface from a WAN failover comes online. [View](./wan-online) Trigger when a site fails to check in with the management system for more than 5 minutes. [View](./site-offline) Trigger when a site comes back online and resumes sending heartbeats. [View](./site-online) ## Registry-Only Trigger Entries These exist in the automation registry but are excluded from prompt-assistant context (for example, subflow-only nodes). This trigger is activated when a subflow is called. [View](./workflow-trigger) ## Trigger Design Best Practices * Keep trigger configuration minimal and deterministic. * Validate expected input schema before downstream processing. * Add guard conditions early when trigger payloads can vary. * Monitor missed or delayed executions for schedules and external callbacks. # Scheduled Trigger Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/scheduled-trigger Run this workflow on a recurring schedule. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Nightly inventory synchronization and reporting. * Weekly policy compliance checks across all sites. ## Configuration Checklist 1. Select schedule type (daily, weekly, monthly, cron, or interval). 2. Set schedule value according to the selected type. 3. Connect the trigger to the workflow path and enable the workflow. 4. Confirm next run behavior from execution history after deployment. ## Inputs * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Avoid overlapping schedule windows for long workflows. # Site Added Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/site-added Trigger this workflow when a new site is added. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Run baseline tagging and policy attachment when a site is created. * Post a welcome/setup notification to operations channels. ## Configuration Checklist 1. Choose Site Added as the first node. 2. Add actions for bootstrap tasks (tags, policy, initial checks). 3. Add a notification action for audit visibility. 4. Test with a recently created site record. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep trigger payload shape stable so downstream mappings remain reliable. # Site Offline Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/site-offline Trigger when a site fails to check in with the management system for more than 5 minutes. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Open high-priority incidents for production sites. * Send lower-priority notifications for lab/dev sites. ## Configuration Checklist 1. Use Site Offline as the trigger for heartbeat-loss events. 2. Add context enrichment actions (site details, tags, ownership). 3. Route by impact level using conditions. 4. Escalate to on-call channels when criteria are met. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep trigger payload shape stable so downstream mappings remain reliable. # Site Online Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/site-online Trigger when a site comes back online and resumes sending heartbeats. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Auto-close outage alerts after site heartbeat recovery. * Kick off post-recovery validation checks. ## Configuration Checklist 1. Trigger on Site Online to process recovery automation. 2. Fetch site metadata and verify post-recovery state. 3. Resolve or annotate active incidents. 4. Notify stakeholders that service is restored. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep trigger payload shape stable so downstream mappings remain reliable. # Site Removed Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/site-removed Trigger this workflow when a site is removed. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Remove stale references in external systems after site deletion. * Notify billing or support teams that a site was removed. ## Configuration Checklist 1. Use Site Removed as the trigger for decommissioning flows. 2. Add cleanup actions to detach policies and archive metadata. 3. Send notifications to operational stakeholders. 4. Confirm teardown is safe for partially removed resources. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep trigger payload shape stable so downstream mappings remain reliable. # API Trigger (Synchronous) Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/sync-request-trigger Trigger this workflow via API call with synchronous execution. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Trigger validation and return immediate pass/fail results. * Provide an internal API endpoint that wraps multi-step automation. ## Configuration Checklist 1. Use this trigger to expose a synchronous HTTP entry point. 2. Map incoming request data to downstream action inputs. 3. Set a response node or termination path for clear API outcomes. 4. Test from an API client using realistic payloads and timeouts. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep synchronous flows short to avoid client timeout issues. # Manual Trigger Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/trigger Start this workflow via an API call or the UI. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Run a remediation workflow during an incident. * Manually trigger a one-time migration or cleanup flow. ## Configuration Checklist 1. Use Manual Trigger as the entry node for on-demand workflows. 2. Optionally add a human-readable description so operators know when to run it. 3. Connect downstream actions and execute from the workflow Run button. 4. Review execution logs and output payload for each run. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Design manual workflows to be idempotent so safe reruns are possible. # WAN Interface Offline Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/wan-offline Trigger when a WAN interface from a WAN failover goes offline. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Instantly alert NOC when a critical WAN path drops. * Capture troubleshooting snapshot data at outage start. ## Configuration Checklist 1. Set WAN Interface Offline as the entry node. 2. Add diagnostics actions (Get WAN, API call, SSH) to capture context. 3. Branch by severity and notify the right team. 4. Optionally trigger a fallback workflow for escalation. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep trigger payload shape stable so downstream mappings remain reliable. # WAN Interface Online Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/wan-online Trigger when a WAN interface from a WAN failover comes online. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Validate WAN performance immediately after link recovery. * Resume paused automations after connectivity returns. ## Configuration Checklist 1. Use WAN Interface Online to react to service restoration. 2. Add verification steps (health or latency checks). 3. Branch based on whether post-recovery checks pass. 4. Send success or follow-up troubleshooting notifications. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep trigger payload shape stable so downstream mappings remain reliable. # WAN Packet Loss Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/wan-packet-loss Trigger when a WAN interface from a WAN failover experiences packet loss. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Notify network engineers only when packet loss crosses SLA threshold. * Create incident payloads with tunnel and site identifiers. ## Configuration Checklist 1. Use WAN Packet Loss trigger with a threshold strategy. 2. Add enrichment actions to fetch tunnel/site metadata. 3. Use conditions to suppress low-impact spikes. 4. Send targeted alerts only for sustained degradation. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep trigger payload shape stable so downstream mappings remain reliable. # WAN Packet Loss Resolved Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/wan-packet-loss-resolved Trigger when a WAN interface from a WAN failover recovers from packet loss. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Automatically post incident recovery messages. * Track MTTR by pairing degradation and resolution events. ## Configuration Checklist 1. Place WAN Packet Loss Resolved as the first node. 2. Correlate with active incidents via API call or tag lookup. 3. Send recovery notifications and update status dashboards. 4. Close out escalation workflows if they are still active. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep trigger payload shape stable so downstream mappings remain reliable. # Trigger by Another Workflow Source: https://altostrat.io/docs/sdx/en/automation/workflows/nodes/triggers/workflow-trigger Call this workflow from another workflow. Triggers start workflow execution. A valid workflow should have exactly one trigger node. This trigger is the entry point for a workflow run and should be connected to the first downstream action or condition. ## When To Use * Centralize common notification logic into a shared sub-workflow. * Build reusable enrichment workflows called from multiple pipelines. ## Configuration Checklist 1. Set this as the trigger for workflows intended to be called by other workflows. 2. Define expected input variables on the called workflow. 3. From another workflow, use Trigger Another Workflow action and pass required values. 4. Validate contract changes whenever either workflow is updated. ## Inputs * Node metadata in `node.data`: `uiId` and `componentId`. * Trigger-specific configuration from the node form (for example schedule or API trigger settings). * No upstream node input is required because this is the workflow entrypoint. ## Outputs * Produces the initial workflow context (the `trigger` payload) for downstream nodes. * Exposes trigger/event data that subsequent actions and conditions can reference. * Starts execution flow for connected nodes. ## Failure Modes * Missing or invalid trigger configuration fields. * Workflow disabled/inactive, so the trigger does not execute. * Event payload missing fields expected by downstream nodes. * Permission/integration issues that prevent trigger invocation. ## Best Practices * Place this as the first node and connect it to the first action or condition. * Keep trigger payload shape stable so downstream mappings remain reliable. # Workflow Triggers Source: https://altostrat.io/docs/sdx/en/automation/workflows/triggers-and-webhooks Choose the right trigger for manual runs, schedules, API requests, site lifecycle events, WAN health events, and workflow chaining. A trigger decides when a workflow starts and what context enters the graph. Choose the trigger before you design the rest of the workflow; the trigger determines the first variables your actions and conditions can use. ## Prerequisites Before you configure triggers, make sure you have: * Permission to create or edit workflows. * A clear source event for the automation. * A sample payload or site/WAN event you can test against. * A workflow authorization if the workflow will call SDX APIs on behalf of a user. ## Trigger Categories | Category | Triggers | Use when | | --------------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | Operator and schedule | Manual Trigger, Scheduled Trigger | A user starts the workflow, or the workflow runs on a recurring schedule. | | Workflow composition | Trigger by Another Workflow, Subflow Trigger | You want reusable automation blocks or nested logic. | | API | API Trigger (Synchronous) | An external request needs a workflow-generated response. | | Site lifecycle | Site Added, Site Removed | Site onboarding or removal should trigger follow-up work. | | Site health | Site Offline, Site Online | A site health event should notify, enrich, or remediate. | | WAN health | WAN Interface Offline, WAN Interface Online, WAN Packet Loss, WAN Packet Loss Resolved | WAN failover or quality events should drive operations. | ## Manual Trigger Use **Manual Trigger** for operator-controlled workflows. This is the safest starting point for diagnostics, one-off reports, and workflows that need human intent before they run. Good uses: * Run a site health check on demand. * Generate a one-time operational summary. * Trigger a controlled workflow during an incident. ## Scheduled Trigger Use **Scheduled Trigger** for recurring work. Scheduled workflows are dispatched by the workflow service and are best for audits, cleanup, reports, and periodic synchronization. Good uses: * Daily inventory or metadata checks. * Weekly report generation. * Recurring checks for missing tags, offline sites, or policy drift. ## API Trigger (Synchronous) Use **API Trigger (Synchronous)** when an external system calls a workflow and expects an immediate HTTP response. Synchronous workflows: * Must be active before they accept requests. * Receive request payload, headers, query parameters, method, URL, user agent, and IP address in the initial context. * Can use JWT claims when an authorizer validates a request. * Should finish quickly enough for an HTTP caller. Keep synchronous workflows small and predictable. Long-running device jobs, multi-site loops, or human approval steps are better handled asynchronously. ## Site And WAN Event Triggers Use platform event triggers when the workflow should react to SDX telemetry: * **Site Offline:** a site has stopped checking in long enough to be marked offline. * **Site Online:** a site resumes heartbeats after being offline. * **WAN Interface Offline:** a WAN failover interface goes offline. * **WAN Interface Online:** a WAN failover interface comes online. * **WAN Packet Loss:** a WAN interface experiences packet loss. * **WAN Packet Loss Resolved:** packet loss recovers. * **Site Added** and **Site Removed:** the site lifecycle changes. These triggers are useful because the workflow starts with context from the event. Enrich that context with **Get Site**, **Get WAN Tunnel**, and **Get Resource Tags** before you decide what to do next. ## Workflow Chaining Use **Trigger by Another Workflow** when one workflow should be callable by another workflow. This keeps common logic centralized. Good uses: * A shared notification formatter. * A reusable tagging routine. * A common external ticket creation flow. SDX prevents self-triggering and circular workflow dependencies when workflows are saved. ## Webhook-Style Inbound Requests The workflow service supports system-generated inbound endpoints for workflows that are configured for external triggering. Treat those endpoints like credentials: * Store external caller secrets in the vault. * Validate payloads before taking action. * Prefer synchronous API workflows only when the caller needs an immediate response. * Use normal workflow logs to inspect accepted requests and failed nodes. ## Next Step Add actions, conditions, variables, and tests. Understand user-delegated workflow access. # Use The Workflow Vault Source: https://altostrat.io/docs/sdx/en/automation/workflows/using-the-vault Store workflow secrets, generated API keys, and signing material without exposing sensitive values in workflow definitions. The workflow vault stores sensitive values for workflows. Use it for API tokens, passwords, SMTP credentials, SSH material, webhook caller keys, or signing keys used by workflow authorizers. Vault values are returned as metadata after creation. The secret value itself is not exposed again through the API response. ## Prerequisites Before you create vault items, make sure you have: * Permission to manage workflow vault entries. * A clear owner and rotation plan for each secret. * The workflow or authorizer that will use the secret. * An expiry date for credentials that should rotate. ## Create A Secret Go to **Automation**, open **Workflows**, then open **Vault**. Add a secret with a name between 3 and 50 characters. Use a name that describes the service and environment. Paste the secret value. Regular vault secret values can be up to 2,000 characters. Add an expiry date for credentials that should not live forever. Save the item, then select it from workflow nodes that support vault-backed credentials. ## Generate A Workflow API Key For workflow API keys, create a vault item whose name starts with `api-key:`. SDX generates a key with the `wfk_` prefix and shows it once. Generated API keys cannot be retrieved again. Store the generated key in your organization's approved secret manager immediately after creation. ## Where Vault Items Are Used Common vault-backed workflow uses include: * Authorization headers for external HTTP calls. * SMTP passwords. * SSH credentials. * SOAP authentication material. * Static signing keys for authorizers. * Workflow API keys for inbound requests. ## Rotation And Deletion When rotating a credential: 1. Create or update the vault item. 2. Test the workflow node that uses it. 3. Run a controlled workflow test. 4. Watch the first production run after activation. 5. Delete stale vault items only after all workflows have moved to the new secret. Use environment-specific names such as `prod-ticketing-api-token` or `test-smtp-password`. Generic names make incident response slower. ## Related Pages Understand user-delegated workflow access. Use vault-backed secrets safely inside nodes. # Changelog Source: https://altostrat.io/docs/sdx/en/changelog/overview Weekly updates to Altostrat SDX — from launch in October 2024 through active maintenance. What's shipped in SDX. Entries are dated to the week they shipped, newest first. **Status update — May 2026.** SDX has moved into active maintenance through **March 2029**. New product work is now focused on [Altostrat Studio](/docs/studio/en/welcome). See the latest entry below for details. ## SDX moves into active maintenance until March 2029 We've stopped building new features for SDX. Roadmap focus has shifted to **[Altostrat Studio](/docs/studio/en/welcome)** — a new agentic AI experience for network operations that builds on top of the SDX platform. **What this means for you:** * **SDX continues to run.** All your sites, policies, workflows, dashboards, scheduled scripts, and reports keep working exactly as they are today, with full active maintenance through **March 2029**. Bug fixes, security patches, RouterOS compatibility, and operational stability work continue throughout that window. * **No new feature work in SDX.** New capability — AI Copilot improvements, new automation primitives, fleet operations features — is now landing in [Altostrat Studio](/docs/studio/en/welcome). * **Studio sits alongside SDX.** Your existing SDX fleet is fully usable from Studio, and you can adopt Studio at your own pace. See the [Studio changelog](/docs/studio/en/changelog/overview) for what's shipping in the new product. ## What's new * **AI Co-pilot diagnostic suite.** New named prompts — **Device Diagnostics**, **Fleet Health Dashboard**, **Investigate Fault**, **Security Audit**, and **Site Security Review** — guide you through systematic diagnostics, root-cause analysis, and security audits across one device or your entire fleet. * **Conversational automation.** Use the new **Automate Task** prompt to design event-driven workflows and generate RouterOS scripts from plain language. * **Configuration backup diffs.** Generate a diff between any two Configuration Backups for change management, troubleshooting, and audit trails. * **Dynamic tag-based SLA report selection.** Build SLA reports with tag rules (e.g. `Location: New York` OR `Customer: Acme Corp`) so new matching sites get included automatically as your network grows. * **Site grouping in SLA reports.** Group sites by any tag and compute aggregated uptime — Average, Minimum, Maximum, or Redundancy — invaluable for multi-tenant MSP reporting. * **Recent workflow logs API.** A new `GET /api/workflows/logs/recent` endpoint returns the most recent log entry for each workflow in your organization. ## Improved * **Rebuilt SLA report scheduling infrastructure.** A new cloud-native scheduler delivers scheduled reports more reliably as your reporting volume grows. * **Faster API across the board.** Workflow run listings and filtered log queries are dramatically faster, with new database indexes accelerating frequently accessed queries throughout the platform. * **Transient Access supports CIDR.** Grant temporary access to entire ranges (e.g. `192.168.1.0/24`) instead of single IPs — handy for whole offices or VPN subnets. * **Smarter device product search.** The MikroTik product catalog now understands complex product codes, identifies individual products inside hardware bundles, and matches against both names and model numbers. * **More reliable third-party integrations.** Slack, Microsoft Teams, and similar workflow integrations are more robust under load and fail faster with clearer errors when an account's authorization is revoked. * **Less event noise.** Refined event detection eliminates spurious "device rebooted" events on normal check-ins, so genuine reboots stand out. ## Fixed * Workflow execution logs now display in chronological order. * PDF download links for some historical SLA reports are no longer generated incorrectly. * MikroTik product codes containing `+` are now searchable. * Older manually created report schedules continue to work without migration. ## What's new * **CSV export from dashboard panels.** Export the underlying time-series for any panel for offline analysis, audit, or custom visualizations. * **SLA reports auto-organized by year and month.** Browsing report history is dramatically faster, especially for organizations with thousands of reports. * New API endpoints list dashboards by folder and reports filtered by year and month. ## Improved * **AI Co-pilot upgraded to a more capable model**, with faster responses and more accurate suggestions for diagnostics, RouterOS scripts, and workflow automation. * Dashboards adapt query resolution to the selected time window for faster, more predictable rendering. * WAN failover priority changes now take effect more quickly and predictably. * CSV exports use human-readable column headers and include a daily heartbeat point for each metric series. ## Fixed * Download links for some historical reports were incorrect after the move to hierarchical storage — now resolved. * Fixed a Managed VPN route calculation edge case that could destabilize client connections under specific topologies. * Site metadata used in SLA report calculations is now always read from the authoritative source. ## What's new * **Tags on RADIUS Users, Accounts, Containers, and Groups, plus Account Containers.** A new API endpoint lists every Account Container with a given tag, making fleet segmentation and dynamic policies easier to build. * **Batched Managed VPN status reporting.** VPN clients can report the state of multiple tunnels in a single API call, cutting overhead and speeding up failover synchronization. ## Improved * **Faster BGP Threat Mitigation.** The IP blocklist pipeline has been overhauled — threat feed updates apply substantially faster, even for very large lists, shrinking your exposure window. * Managed VPN tunnels recover from outages faster, automatically clear related alerts on reconnect, and include `workspace_id` in auth responses for monitoring integrations. ## Fixed * API key creation and rotation are now reliable; an intermittent failure has been resolved. * Duplicate IPs are no longer added to BGP threat mitigation blocklists. ## What's new * **Data quotas for user groups.** Define per-group data allowances and apply progressive enforcement (throttle, redirect to a notification portal) once a user exceeds their quota. Maximum quota raised to 10TB. * **Conditional policy enforcement.** Apply network access policies based on real-time user state, such as whether they're within or over their quota. * **Remote session termination.** A new API endpoint disconnects active user sessions, useful for incidents, policy violations, or troubleshooting. All admin disconnects are recorded in the Audit Log. ## Improved * Vulnerability scans can now run as often as weekly, up from a two-week minimum. * Network access policies from multiple groups can be combined rather than overwritten — for example, routing rules from two groups can be merged for a user in both. * User and group attribute API responses use a more consistent structure. ## Fixed * Restored the default upstream DNS resolvers that block malware and adult-content domains. * Legacy SLA report schedules created before the new engine now load correctly, and the full historical report list is visible again. ## Improved * **Customizable email notifications.** Workflow and system emails support custom headings, preview text, personalized greetings, and call-to-action buttons. * **Per-item workflow error reporting.** When a workflow processes multiple items and one fails, you now see exactly which item failed and why, instead of a single rolled-up error. * Authentication realms can be created and modified without an initial group assignment. ## Fixed * Email notifications send reliably even when optional metadata fields are missing from the payload. * Searching for an authentication realm by exact name now consistently returns a result. ## Improved * **RADIUS authentication log retention extended from 4 to 24 hours**, giving you a full day to investigate auth issues and access patterns. * User search now indexes RADIUS reply attributes, so you can locate users by VLAN assignment, bandwidth policy, or other configured attributes. * Custom metric labels accept a wider range of naming conventions and special characters. ## Fixed * System-managed labels (organization and workspace identifiers) are now always enforced on incoming metric data, keeping multi-tenant data properly isolated. ## Improved * **Faster DNS Content Filtering deployments.** Pushing policy changes to MikroTik routers is significantly quicker and more reliable, especially for large or complex policies. * Site health metrics (CPU, memory, uptime) are collected more frequently for fresher visibility into fleet health. * Upstream DNS resolvers are upgraded for better filtering accuracy and lower query latency. * Dynamic DNS handling is more tolerant of brief outages, reducing false-positive alerts. * The platform stats endpoint reports the total number of authentication realms, user details include a structured organizational path, and device details indicate auto-registration status. * RADIUS log device identifiers are now consistent and parseable. ## Fixed * User account merges include additional safeguards to maintain data integrity through the cleanup process. ## Improved * Behind-the-scenes platform stability work — no user-visible changes this week. ## Improved * Behind-the-scenes platform stability work — no user-visible changes this week. ## Improved * Behind-the-scenes platform stability work — no user-visible changes this week. ## Improved * Behind-the-scenes platform stability work — no user-visible changes this week. ## What's new * **User preferences API.** Store and retrieve per-user settings programmatically, useful for custom dashboards and saved report templates. ## Improved * Custom metric submissions no longer require an explicit timestamp, and metric names are normalized automatically. ## Fixed * SLA reports now complete even when a single MikroTik device returns incomplete data during collection. * Tag-based SLA report schedules with multiple AND/OR rules now select the correct sites. ## What's new * **Redundancy uptime calculation in SLA reports.** A group of sites counts as "online" if at least one is operational, useful for HA clusters and redundant VPN hubs. ## Improved * Dashboard graphs render more accurately when zoomed in, with query resolution adapting to the selected time range. * Vulnerability scans handle large networks and slow links more gracefully. * Managed VPN tunnel API responses now include a `username` field for monitoring integrations. * Performance metric collection (CPU, memory, uptime) is more efficient. ## Fixed * Older SLA report schedules continue working without migration. * Dashboard graph queries no longer fail at very tight zoom levels. * In-progress vulnerability scans can now be stopped reliably. ## Improved * **Dashboards now load in parallel** rather than sequentially, with substantial speed gains across all panels. * SLA report generation is faster, especially when WAN performance metrics are included. * Vulnerability scan API responses are noticeably faster thanks to smarter caching. * **Automatic site geolocation.** New sites have latitude, longitude, and timezone inferred from their public IP. * WAN throughput in SLA reports is now consistently displayed in Mbps. * Vulnerability scan control links remain valid for six hours, up from one. ## Fixed * Vulnerability scan schedules now respect organizational permissions and only show sites in your scope. * WAN performance metrics (latency, jitter, packet loss) now appear reliably in SLA reports. ## What's new * **Metrics and dashboard API.** Run custom queries against your time-series data, discover available metrics, and pull dashboard contents programmatically. * **Documentation search.** A dedicated endpoint searches product docs and API references. * **Detailed network interface stats.** SDX now collects per-interface traffic, error counters, link status, and uptime. * **Automatic logo onboarding.** Your organization's logo is detected from your email domain at signup. ## Improved * Vulnerability scan results include richer host info (manufacturer, standardized service names) and CVE entries now carry publication dates and reference links. * AI-generated scan summaries handle very large vulnerability lists more reliably. * Configuration deployments adapt to each device's RouterOS version. ## Fixed * VPN configuration files and QR codes download reliably again. * Hosts from different sites are no longer grouped together in scan results. * Subscriptions with mixed monthly/yearly products can be edited without errors. ## What's new * **API key management for service accounts.** Create, list, view, rotate, and delete keys for machine-to-machine integrations, with role-based permissions per key. * **AI Co-pilot diagnostic prompts.** New guided prompts let you investigate active faults, check WAN connectivity, inspect Configuration Backups, and run safe read-only commands on MikroTik devices. * **Metrics query API.** Run PromQL queries against your monitoring data with custom time ranges and resolution. * **Multi-currency billing.** Organizations can now operate in their local currency. ## Improved * The AI Co-pilot is faster and routes requests intelligently between models, distinguishing inline autocomplete from full script generation. * Recent fault lookups are dramatically faster, speeding up dashboards and monitoring integrations. * Notification delivery (email, webhooks, Slack/Teams) is more reliable. ## Fixed * SLA report schedules created in older formats now load correctly. * Workflows no longer fail when input data contains null bytes or other special characters. * Notifications now send for sites that lack metadata tags. * Closed an AI tool cache issue that could have leaked data between sessions. ## What's new * **Geolocation suggestions for onboarding.** A new API returns appropriate currency and locale based on geographic location, useful for MSPs creating new customer organizations. * **Subscription status endpoint.** Check programmatically whether an organization is on a paid plan or in trial. ## Improved * Subscriptions now accept custom metadata for CRM and billing integrations, and can be marked read-only to prevent edits to managed or white-label accounts. * The invoice preview endpoint handles monthly and yearly intervals more accurately. * Security Groups and Prefix Lists now auto-recover from transient sync errors, with clearer messages when intervention is needed. ## Fixed * AI Co-pilot conversations are more resilient to upstream model errors and recover more cleanly when issues occur. ## What's new * **`@foreach` loops in scheduled scripts.** Generate repetitive RouterOS commands (firewall rules, BGP prefix lists, VLAN assignments) by iterating over a data list from a single template. * **Australia service region.** Lower latency for Management VPN, API, and platform operations across Asia-Pacific. ## Improved * API responses, dashboard load times, and serverless cold-start times are noticeably faster across the platform. * Prefix List changes now consistently trigger updates to the Security Groups that depend on them, with better handling of concurrent admin edits. * Site reboot detection is more accurate, reducing false positives caused by brief network blips. * Script templates can now declare variables without using all of them. ## Fixed * Configuration Backup downloads no longer occasionally produce invalid links. * Concurrent Security Group edits from different sessions no longer collide. * Generated firewall rules now produce correct `accept` actions and handle protocols without ports (ICMP, IGMP). ## What's new * **Security Groups and Prefix Lists.** Define template-based stateful firewall rules and reusable IP/subnet collections, then apply them consistently across your MikroTik fleet. Reference endpoints help you discover supported protocols and services. * **WAN performance breakdowns in SLA reports.** Sites that breach uptime now include a per-WAN section with uptime percentage, ISP, fault count, and downtime totals. ## Improved * Site list loading and device check-in processing are noticeably faster. * The SLA report engine has been rebuilt for more reliable, accurate generation. * Dynamic DNS updates are more efficient and consistent for sites with frequently changing IPs. * Security Group rule validation now provides clearer feedback during configuration. ## Fixed * Tag-based SLA reports no longer show incorrect site counts in their summaries. * Grouped-site SLA reports now generate reliably. ## What's new * **PDF SLA reports with downtime root-cause analysis.** Multi-page reports cover uptime, performance against targets, and incident logs categorized by Power, Network, or Device cause. * **On-demand vulnerability scans against IP lists.** Target specific addresses without scanning entire subnets, ideal for validating patches or checking new devices before rollout. * **"Resource Has Tags" workflow condition.** Branch automation logic on whether a site or device has specific tag keys, values, or counts. ## Improved * Breached sites now appear at the top of SLA reports, with clickable links from the executive summary down to incident details. * Workflow synchronous timeouts increased from 15 to 30 seconds. * Workflow test triggers now use your input schema as the sample payload. * Recent Sites loads noticeably faster. * Dynamic DNS updates for Managed VPN failover propagate more quickly. ## Fixed * PDF SLA reports now show full site detail for grouped sites, the correct organization logo, and accurate WAN interface data in incident logs. * A site's "last seen from" IP now consistently reflects the most recent device communication. ## What's new * **Tag management API.** Create, update, and delete metadata tags programmatically, and query every resource sharing a given key:value pair (for example, all sites with `Region:Europe`). * **Tag-based SLA reporting.** Define a report once with tag rules (like `Priority:High`); new sites matching the criteria are picked up automatically. * **Site grouping and aggregated metrics in SLA reports.** Group sites by tag and view average, minimum, or maximum uptime for each group. * **RADIUS authentication logs in the API.** Pull detailed auth and authorization events for NAS devices and user accounts. ## Improved * Global search now covers Sites (name, address, IP, MikroTik model), Policies, Managed VPN instances, Notification Groups, Captive Portals, Workflows, and all schedule types, with typo tolerance and relevance scoring. * SLA report generation is faster, especially for reports spanning many sites with long incident histories. * Tag values are now case-normalized to prevent accidental duplicates like "new york" vs "New York". * Workflows hitting Slack, Microsoft Teams, and webhooks now refresh tokens and retry intelligently on failure. ## Fixed * Sites with multiple matching tags are no longer duplicated across groups in the same SLA report. * Search indexing for MikroTik hardware details and scheduled script metadata is corrected. ## What's new * **Custom organization branding.** New API endpoints let you set your organization's display name, logo, and brand colors for a consistent in-product experience. * **RadSec with automated Certificate Authority.** SDX now generates and manages RadSec client certificates for new devices, simplifying secure RADIUS-over-TLS deployments. * **EAP support for WPA2/3-Enterprise.** RADIUS now supports EAP for enterprise wireless authentication. ## Improved * Invoices now show clearer breakdowns for subtotal, taxes, and discounts, with safer handling of payment methods. * Schedule processing is faster and more reliable for accounts with many schedules. * WAN tunnel offline detection is more responsive. ## Fixed * Schedules with Sunday time slots now activate correctly. * You can remove an organization's profile picture again, and concurrent edits to organization limits no longer overwrite each other. * Coupon PDF generation no longer fails for very large coupon batches. ## What's new * **Bulk CSV import for Users, Groups, and NAS devices.** Upload a CSV, preview the contents, do a dry run, and download a failure log if rows don't import. Handles files with 300,000+ rows and supports tags and custom RADIUS attributes. * **Metered usage history API.** Pull aggregated usage for billing event types (like `sms_messages`) over any date range, grouped by day or hour. * **MS-CHAPv2 authentication.** RADIUS now accepts MS-CHAPv2 alongside CHAP. ## Improved * The workflow **Array Filter** node now supports nested AND/OR logic and can either include or exclude matching items. * SSH workflow action errors are more descriptive, making connection issues easier to diagnose. * Incident end times in PDF reports now respect the report's configured timezone. ## Fixed * A workflow validation bug that could prevent one workflow from triggering another is resolved. * The **Iterator** node now passes data correctly when it triggers a downstream workflow. * NAS log timestamps are accurate again. ## What's new * **SSH and SMTP workflow nodes.** Workflows can now run shell commands on remote servers (with key or password auth from Vault) and send email through any SMTP server, with attachments and custom headers. * **CHAP authentication for RADIUS.** RADIUS now accepts CHAP, broadening compatibility with legacy network gear. * **Transient Access auditing.** Each Transient Access session now records which user created it, visible in session details via the API. * **Reseller directory API.** A new endpoint returns paginated MikroTik reseller listings with location, contact details, and country filters. ## Improved * Notification groups now support up to 800 sites, up from 200. * Listing Transient Access sessions now includes expired sessions for a full historical record. * API error messages for auth and SMTP actions are more descriptive, and `401 Unauthorized` responses are standardized. * Cursor-based pagination is now available on key list endpoints. ## Fixed * Deleting a user now reliably removes all associated group memberships and related data. * Group membership listings no longer return slow or incomplete results. ## What's new * **Fault Management API.** Programmatically create, update, comment on, and delete faults for tighter integration with your monitoring and response workflows. ## Improved * **DNS policy lists tripled.** Custom DNS allow/blocklists now hold up to 150 domains, up from 50. * **Fewer false-positive WAN offline alerts.** A WAN tunnel must now be unreachable for 5 minutes (up from 3) before triggering an offline alert. * **Wider device support.** Lowered the minimum RouterOS to 6.47 (ROS6) and 7.8 (ROS7). * Faster queries for recent and unresolved faults; site `created_at` timestamps are now ISO 8601. * Stricter permission checks on API endpoints — unauthorized calls now correctly return 403. ## Fixed * Resolved an issue where alert notifications were not being delivered to channels like Slack. * Fault Management API now accepts fault IDs with or without the `flt_` prefix, and always includes the `comments` field in responses. ## What's new * **Real-time custom dashboards.** Build interactive dashboards with live widgets for your MikroTik fleet, with widgets that can trigger workflows — built for NOC displays and proactive monitoring. * **MSP organization branding.** Customize display names, colors, and login hints, and use new public endpoints to build fully white-labeled login experiences for clients. * **Expanded workflow actions.** New actions for filtering arrays, transforming dates, validating structures, generating random strings/passwords/UUIDs, generating WireGuard keys, and looking up IPv4 details — all directly inside a workflow. * **Multi-button forms with conditional fields.** Approval workflows can now have multiple action buttons ("Approve", "Reject") that route down different branches, with fields that show or hide based on user input. * **Fault data CSV export.** Export historical fault data for offline analysis, compliance reporting, and trend analysis. ## Improved * **Fault history extended to 14 months.** Up from 90 days, with fault filtering by type (site, device, service) and faster queries. * Better Captive Portal client connectivity detection (including Windows OS) so guests reliably see the portal. * Hardened deletion process for sites and Managed VPN instances to prevent orphaned resources. ## Fixed * Site-specific details and links are now included in alert notifications. * Cached site data no longer persists after a site is deleted. * Date range filters now apply correctly when querying site-specific faults. ## What's new * **Workflows as serverless APIs.** Turn a workflow into a real-time HTTP endpoint that accepts requests and returns responses — ideal for ticketing system, monitoring, and external platform integrations. Secure each endpoint with API keys or a custom JWT authorizer. * **Interactive forms and approval gates.** Build multi-step workflows with user approval steps for change management, provisioning, and onboarding. * **Workflow run resume.** Restart a failed workflow run from any successful checkpoint instead of starting over. * **Multi-channel Notification API.** Send email and WhatsApp notifications to addresses, phone numbers, or tagged user groups, including emails with attachments. * **Reusable script templates.** Build a central library of MikroTik RouterOS scripts you can reuse across deployments, kept private to your organization or shared publicly. * **SOAP request action.** Workflows can now call SOAP endpoints for legacy network management and billing integrations. ## Improved * Liquid templating is now available across all workflow nodes for richer conditional logic and data transformation. * Granular workflow error handling lets you treat expected errors (like a 404) differently from critical ones. * Faster network interface graphs and device statistics queries over long time ranges. * Backend event processing now triggers workflows nearly instantaneously. ## Fixed * Corrected timestamp display on aggregated performance graphs. ## What's new * **30 days of fault history and historical device stats.** Pull fault history and CPU, memory, and uptime data over arbitrary date ranges — useful for capacity planning, SLA reporting, and identifying recurring issues. * **`wan.packet_loss_started` and `wan.packet_loss_resolved` workflow events.** Trigger custom automations on WAN quality changes, like failing over to a backup link or opening a ticket. * **Fleet-wide tunnel inventory API.** Retrieve all configured WAN tunnels across your network in a single call for compliance audits and configuration review. ## Improved * Dashboard charts render significantly faster, especially over longer time ranges. * More accurate WAN tunnel status detection, with packet loss notifications now including the specific tunnel ID for faster troubleshooting. ## Fixed * Corrected timestamps in aggregated chart data. ## What's new * **Workflow chaining.** Trigger workflows from other workflows to build modular, reusable automations — for example, a "Provision VPN" workflow called by a higher-level onboarding flow. A new API endpoint lists triggerable workflows. * **Real-time site and tunnel events.** Site online/offline and WAN tunnel online/offline now fire as workflow triggers, so you can automate incident response the moment status changes. * **Proactive WAN packet loss alerts.** SDX now detects when packet loss on a WAN tunnel exceeds critical thresholds and notifies you immediately. ## Improved * Dependency protection blocks deletion of workflows referenced by other workflows, and circular dependency detection prevents infinite loops. * Workflow test editor now ships with sample event data for faster authoring of event-driven flows. * Tunnel API responses now include external IP addresses for each WAN link. ## Fixed * Resolved a critical issue that prevented event-triggered workflows from executing. * Fixed packet loss alert delivery configuration and notification delays for newly created sites. * Deleted sites no longer linger in site lists. ## What's new * **Scheduled Script email notifications.** Get email alerts when a scheduled script needs authorization, starts, or finishes — important for audit trails. * **Workflow date filters.** New `carbon_date` and `carbon_condition` Liquid filters let workflows parse, format, and compare dates with helpers like `is_today` and `within_7_days`. * **Human-readable workflow schedules.** Scheduled workflows now show their next run in plain language ("in 5 minutes", "tomorrow"). ## Improved * Email notifications now retry on temporary failures, dramatically improving delivery reliability for alerts and compliance traffic. * Scheduled script alerts are now sent over both email and your primary notification channel for redundancy. * Wider date format support and more accurate next-run calculation in workflow schedule triggers. ## Fixed * Scheduled script authorization emails now use the correct URLs and templates and deliver reliably. * Fixed inaccurate workflow run duration reporting and resolved special-character handling in workflow JSON payloads. ## What's new * **More email notifications.** Get notified for vulnerability scan start/completion, scheduled SLA report delivery, individual WAN interface up/down events, Captive Portal coupon generation (with PDF attached), and Managed VPN credential creation. * **Bulk Configuration Backup API.** Retrieve the latest backup for up to 50 sites in a single `POST /api/backups/latest` call — much faster for compliance and DR validation. ## Improved * Single IP addresses entered in Firewall Trusted Networks are now auto-converted to CIDR (`10.0.0.1` becomes `10.0.0.1/32`). * Key metrics endpoints accept GET as well as POST for conventional retrieval. ## Fixed * Pagination status now reports correctly on filtered API responses. * Corrected the Captive Portal coupon notification email subject and template. * Improved clarity of the "WAN Interface Down" alert subject line. ## What's new * **Advanced audit log filtering.** Filter audit logs by HTTP status category, method, or individual user, and see enriched entries with display names and emails — useful for security investigations and compliance audits. * **Proactive billing checks.** SDX now validates subscription health before service access and surfaces guidance to resolve issues before they cause interruptions. ## Improved * **Captive Portal sessions up to 7 days.** Maximum session duration extended from 24 hours to 7 days for hotels, conferences, and long-term guest access. * **95% faster audit searches.** Filtered audit log queries now return near-instantly. * Dashboard throughput, data-transfer, and MAC vendor endpoints now support both GET and POST. ## Fixed * Device re-registration no longer consumes an extra license seat. * Corrected Managed VPN peer seat counting for accurate billing. * Captive Portal custom assets (logos, icons) now load reliably, and portal preview URLs use the production domain. * Fixed organization profile picture clearing and audit log date-range accuracy. ## What's new * **Usage reporting and exports.** Export per-organization resource consumption to CSV or PDF for client billing, capacity planning, and compliance. * **Flexible resource limits.** Set "unlimited," "deny" (zero), or a specific number per organization, with SSO now tracked as a manageable resource alongside devices, VPNs, and sites. * **Automatic site resource accounting.** SDX now verifies seat availability before adopting a device and releases resources when a site is deleted. ## Improved * New organizations created via the API automatically receive default user roles and authentication connections. * More accurate user-count tracking for Managed VPN instances against subscription limits. * Comprehensive checks prevent setting resource configurations that exceed subscription, parent, or current usage limits. ## Fixed * Corrected user seat increment/decrement logic for accurate subscription tracking. * Available capacity calculations now reflect organization hierarchy correctly. ## What's new * **Expanded payment methods.** Billing now supports US ACH, AU BECS, SEPA Direct Debit, PayPal, and Link — important for international MSPs. * **Detailed invoice previews.** Previews now show line items, taxes, and discounts so you can reconcile against client billing before charges land. * **Organization resource usage API.** Retrieve current usage and configured limits per organization for capacity planning and quota management. * **Organization branding.** Upload custom logos and profile pictures for white-label MSP portals. ## Improved * Standardized JSON shape and pagination across list endpoints. * You can no longer accidentally delete the only payment method on a billing account, or lock yourself out by demoting the sole workspace owner. * Billing account creation auto-fills the address from IP geolocation when you don't provide one. ## Fixed * Resource limit enforcement now correctly respects subscription, organization, and parent-org limits when adding resources. * `trialing` and `past_due` subscriptions are now included in total quantity calculations. * Invoice endpoints consistently return arrays for line items. ## What's new * **Hierarchical organizations.** Build nested parent/child organization structures with per-org limits on user seats, sites, and storage — ideal for MSPs with multiple clients under one account. * **Workspace member roles over the API.** Assign and modify Owner, Admin, and Viewer roles programmatically, backed by consistent role-based authorization across resources. * **Bulk MAC vendor lookup.** Look up manufacturer info for up to 50 MAC addresses in a single request — handy for network discovery and inventory. ## Improved * Stronger input validation across Workspaces, Organizations, and billing accounts gives clearer errors and more predictable behavior. * Transient port API responses now include the management server IP. ## Fixed * Corrected Managed VPN peer seat checks so subscription limits apply accurately. * Fixed organization hierarchy data parsing. ## What's new * **Reports go to notification groups.** Scheduled SLA and other reports can now be delivered to notification groups instead of individual recipients, simplifying multi-stakeholder distribution for MSPs. ## Improved * Faster site validation when creating or updating scheduled scripts. ## What's new * **Aggregated network performance APIs.** New endpoints return fleet-wide throughput (bps) and total data transferred (bytes) across sites or site groups, with flexible time windows — built for capacity planning, NOC dashboards, and bandwidth billing. ## Improved * All API responses (reports, security scans, access, faults, Configuration Backups) now use ISO 8601 timestamps for easier integration. * Site serial numbers are now included in minimal API responses. * Configuration Backup listings now include a `created_at` field. ## Fixed * The Faults API now correctly returns `null` for unresolved faults instead of erroring on a missing resolution timestamp. ## Improved * **Faster interface graphs.** Network interface graphs and reports load significantly faster — useful for NOC displays and live monitoring. * Quicker initial config for newly provisioned MikroTik devices. * More responsive notification group create/update/detail views. * Adjusted the daily Configuration Backup schedule for better resource use. ## Fixed * Managed VPN client config files and QR code downloads now generate correctly. * Corrected CORS rules so front-end apps can reach the API cleanly. * Fixed broken deployment management links in device setup scripts. ## Improved * **Faster device provisioning.** Initial setup for new and reset MikroTik devices is now noticeably quicker. * Site offline/online and WAN tunnel alerts now include explicit UTC timestamps, removing timezone ambiguity for distributed teams. * Tighter validation of subscription limits during device provisioning prevents accidental seat overages. ## Fixed * Deployment management links after device adoption now correctly open the device overview page. * Notification delivery no longer errors out when a recipient is invalid. ## What's new * **WhatsApp notifications.** You can now send notification group alerts over WhatsApp — ideal for on-call engineers who need mobile-first delivery. WhatsApp replaces SMS for new and updated groups. ## Improved * Notification group recipients are now validated in real time against the user directory, so only active users appear. * Creating or updating a group now requires explicitly choosing the recipient and channel, preventing silent misconfigurations. * Faster, more reliable site provisioning when checking seat availability against billing. ## Fixed * Resolved false-positive "invalid recipient" errors when configuring notification groups. ## What's new * **Team management.** Add, invite, and remove team members, and define custom roles with specific permissions — built for MSPs managing technician access across multiple clients. * **Self-service MFA.** Users can enable MFA, regenerate recovery codes, or remove MFA from their own account. * **Login with organization context.** Login now remembers your organization and supports return URLs for faster multi-tenant access. ## Improved * Notification groups now validate recipients against the active user list, so alerts no longer fail because of stale members. * Team listings are now paginated and include richer user details over the API. ## Fixed * Corrected MFA status and login permission flags shown in user details. ## What's new * **Auth0 for Captive Portals.** You can now configure Auth0 as an OAuth2 identity provider on Captive Portal instances, useful for hotels, universities, and enterprises with existing Auth0 SSO. ## Improved * Behind-the-scenes platform updates across reporting, metrics, and admin services for better stability and performance. ## Improved * **Faster vulnerability views by device.** Significantly quicker performance when reviewing security findings across multiple scans and the full fleet. * **Better AI mitigation guidance.** An updated model delivers more relevant remediation steps for identified vulnerabilities. * **Smoother API integrations.** Improved CORS handling for clients calling the API from diverse environments. ## Fixed * Vulnerabilities are grouped correctly across multiple scans and hosts. * API-initiated Configuration Backups no longer fail, so automated backup workflows run reliably. ## What's new * **Bulk vulnerability scan API.** Pull vulnerability data for many MikroTik devices in a single request, streamlining security monitoring across large fleets. ## Improved * **Faster traffic reports.** DNS Content Filtering and BGP Threat Mitigation traffic reports load noticeably faster, now showing the last 24 hours for quicker incident review. * **Consistent timestamps in vulnerability responses** to simplify parsing in security automation. ## Fixed * Date formatting in vulnerability API responses is now consistent. ## Improved * **Login redirect from the root URL.** The main web URL now sends you straight to the login page. * **Longer background task windows.** Increased execution time for background jobs prevents long-running operations from being cut short. ## Fixed * Transient access and port forwards behave consistently under edge-case conditions. * BGP Threat Mitigation blocklist updates apply correctly so active threats are filtered as expected. ## Improved * **More reliable reports and notifications.** SLA report data collection retries on failure and email delivery is rate-limited for steadier throughput. * **Foundational platform upgrades.** Core framework and language updates lay groundwork for future features and improve baseline performance. ## Fixed * Device heartbeat processing now reports accurate online/offline status for monitoring and alerting. ## Improved * **Cascading cleanup on deletion.** Deleting a user removes them from notification groups and Managed VPN configurations; deleting a site cleans up Captive Portal config, scan schedules, and device configuration in one pass. * **Faster SLA report generation.** Multi-site reports build more quickly and reliably. * **Vulnerability scan rate limits.** API-triggered scans are capped at one per 24 hours per schedule, and recurring scheduled scans require a minimum two-week interval — preventing accidental over-scanning. ## Fixed * SLA report PDFs now show the correct site incident downtime cause. * Site API credential retrieval no longer fails intermittently. ## What's new * **Fleet-wide vulnerability view.** A new endpoint returns every device with vulnerabilities across recent scans, plus summary stats — useful for executive dashboards and fleet-wide risk assessment. ## Improved * **Faster Managed VPN credential fetching** and higher API request limits to support heavier integration use. * **Better AI mitigation formatting.** Remediation guidance is more readable and actionable. * **More reliable DNS Content Filtering.** Category-based filtering processes more consistently. ## What's new * **Per-device vulnerability status.** Mark individual CVEs on a device as Accepted or Mitigated to track remediation progress and document risk decisions for audits. * **AI remediation guidance.** Pull AI-generated mitigation steps for a specific vulnerability to accelerate response. * **Compliance framework mapping.** Vulnerability detail now lists relevant frameworks (PCI-DSS, HIPAA, GDPR, SOC2, ISO 27001, NIST) for compliance reporting. * **Shareable Captive Portal coupon links.** Generate a unique link for a valid coupon to hand out without giving the recipient API access. ## Improved * **Severity filtering on device vulnerabilities.** Filter by CVSS score so the most critical issues are easy to focus on. * **Cleaner vulnerability API responses.** Findings are grouped by CVE ID, with consistent ISO 8601 timestamps across the API. ## What's new * **Captive Portal coupon system.** Create coupon codes with custom rules, schedule recurring bulk generation, generate batches on demand for events, track usage, share secure temporary links, and print physical coupon sheets as PDFs. * **Dynamic DNS for Managed VPN tunnels.** Each tunnel gets a stable hostname that automatically follows public IP changes, simplifying remote access. * **Richer outage alert emails.** Network outage and coupon batch emails now include more context and direct download links. ## Improved * **Consistent coupon sessions.** Coupon-based access honors the portal's configured session duration. * **Reliable bulk coupon generation.** Large scheduled batches generate cleanly even at high volume. ## Fixed * Expired coupons no longer appear in active coupon API responses. * Coupon batches retain their schedule association and PDF download permissions. ## What's new * **Captive Portal session API.** Programmatically list and filter active guest sessions to power custom reporting, billing integrations, and automated session management. * **Targeted vulnerability scans.** Trigger an on-demand scan against one or more IPs inside a site, without running a full network scan. * **Historical device vulnerability lookup.** Query past findings for a device by MAC address to track remediation progress over time. ## Improved * **Better setup validation.** Captive Portal and Managed VPN setup return more precise feedback when configuration is invalid. * **Smoother guest authentication flow.** Network checks and authentication redirects are more reliable. ## Fixed * Captive Portal API no longer forces immediate site association during instance creation. * ARP data is properly cleaned up when Managed VPN tunnels are decommissioned. ## What's new * **ARP group API.** Create, view, update, and delete ARP groups inside a site to organize network devices by department, location, or tenant. ## Improved * **More reliable data collection.** Better handling of timeouts and intermittent connectivity for SNMP and WAN tunnel performance stats means more complete monitoring data. * **Vulnerability scan watchdog.** Stuck scans are now detected and terminated automatically, keeping the scanning service healthy. * **Sorted scan history.** Vulnerability scan lists default to most-recent-first. * **Reliable Dynamic DNS.** Hostname updates hold up better when device public IPs change. ## Fixed * You can now remove the final site from a Captive Portal instance. * ARP entries clean up correctly when sites are deleted. ## Improved * **Much faster SLA report loading.** Significant performance gains on report libraries with consistent sorting and pagination. * **Reliable firewall updates on Managed VPN.** Adding or removing tunnels now updates filtering rules correctly without manual cleanup. * **Clearer connection errors.** Better error messages when fetching details for offline tunnels. ## Fixed * Initial setup now completes reliably on freshly connected MikroTik devices. * Configuration Backup uploads no longer fail intermittently. ## Improved * **SLA reports default to newest-first.** Fresh client reports are at the top of the list, and the list itself loads faster. * **More accurate DNS Content Filtering.** Specific domain rules inside broader categories now apply exactly as configured. ## Fixed * SLA report generation no longer fails under specific data conditions. ## Improved * **Faster site and report lists.** Caching improvements make site lists and SLA report schedules noticeably quicker, especially when you manage dozens of sites. * **Accurate backup timestamps.** Configuration Backup lists now show real creation time with reliable sorting. * **License enforcement on adoption.** Adopting sites via runbook now respects your seat limits, preventing accidental overages. ## Fixed * Site provisioning reliably finishes critical setup steps, including network address assignment and firewall policy application. * Recent sites list refreshes properly for all users. * Subnet detection in Configuration Backups no longer includes internal management lines. ## Improved * **More resilient data collection.** Background metrics keep flowing even when sites have intermittent connectivity. * **Faster scan feedback.** Stuck vulnerability scans are detected and surfaced more quickly. * **More reliable Managed VPN provisioning.** New tunnels come up cleanly on first attempt. ## Fixed * Site provisioning now reliably completes the automatic setup steps for new MikroTik devices. * WAN ping statistics use the correct timezone and render data points correctly on graphs. * Manual vulnerability scan termination works again, and OpenVPN peer connection issues on Managed VPN are resolved. * Configuration Backup file dates respect timezone correctly. ## Improved * **Faster vulnerability scans.** Per-site scans start more quickly and scan results come back more reliably. * **Cleaner email notifications.** Refreshed branding and consistent links across alert and report emails. * **Richer site API.** Site responses now include device architecture and hardware hash for inventory work, and exclude internal management subnets from subnet lists. ## Fixed * Shared SLA report links are accessible again for stakeholders. * Managed VPN no longer assigns duplicate tunnel IPs during site setup. * Vulnerability scan completion emails point to the correct report. ## Breaking change * **SLA report schedule API.** `GET /sla/schedules/{id}` no longer returns `recipients`; use `notification_group` instead. ## Improved * **Faster site data.** Site lists and details load noticeably quicker across the dashboard and API. * **Smoother device adoption.** Adoption now avoids configuration conflicts on MikroTik devices that already have scheduled tasks. * **Sorted Configuration Backups.** Backup lists default to newest-first, so the most recent recovery point is always at the top. ## Fixed * Configuration Backup timestamps now show the actual creation time instead of the filesystem modification time. * Real-time notifications no longer go to inactive recipients. ## What's new * **Automated daily Configuration Backups.** Every online site now gets a daily backup, giving you regular recovery points for disaster recovery and compliance. * **Device health monitoring.** Track online/offline status, CPU, memory, disk, and uptime in real time across your fleet. * **Automatic site geo-location.** Sites pick up their address and timezone from the device IP, so you don't have to enter them by hand. * **CVE notification topic.** Subscribe teams to vulnerability scan results through the standard notification groups. * **Auto-expiring transient access.** Temporary WinBox/SSH credentials and port forwards now expire automatically, so forgotten access doesn't linger. ## Fixed * SLA report generation no longer fails on scheduled runs and report schedules save reliably. * Configuration Backup uploads land at the correct path, and notification group settings persist correctly. ## What's new * **Live device status across the fleet.** Online/offline tracking for every MikroTik device is now active across SDX, giving you instant fleet visibility. * **Performance metrics activated.** CPU, memory, uptime, and disk metrics now flow into SDX with historical trending for capacity and reliability planning. ## Improved * **Smoother device adoption.** The bootstrap flow and initial connectivity verification are more reliable. * Transient WinBox/SSH credentials and port forwards now apply consistently across management servers and respect their expiration. * Configuration Backup uploads land more reliably in secure storage. ## Fixed * Resolved metric ingestion and processing issues that were causing gaps in performance data. * Backup retrieval no longer fails on rare site-permission edge cases. ## Improved * Behind-the-scenes platform stability work, including more reliable Static IP / RADIUS credential synchronization — no user-visible changes this week. ## Improved * **Faster Managed VPN provisioning.** Server provisioning and teardown are quicker and more reliable. * **More efficient DNS and BGP filter generation.** Configuration generation for DNS Content Filtering and BGP Threat Mitigation rules is more consistent. ## What's new * **Aggregated WAN statistics API.** A new endpoint returns latency, packet loss, and jitter aggregated across multiple WAN tunnels for consolidated network performance views. * **BGP and DNS analytics.** Initial reporting on BGP traffic (top sources, top ports, blocklist hits) and DNS queries (top applications, categories, sources). ## Improved * WAN graphs now visualize collection gaps clearly — periods with missing data over 5 minutes show as 100% packet loss rather than appearing as silent dropouts. ## Improved * Behind-the-scenes platform stability work across authentication, device management, monitoring, and notifications — no user-visible changes this week. ## Improved * **Vulnerability scan reporting.** The full lifecycle is now in production — scans process to completion and produce JSON and PDF reports with notifications on delivery. * **SLA reports as PDF and JSON.** End-to-end report generation pulls from fault tracking, metrics, and schedules with notifications when reports are ready. ## What's new * **Vulnerability scanning.** SDX now runs scheduled or on-demand CVE scans against your sites, generates PDF reports, and notifies you when scans complete. Findings are enriched with MAC vendor data, service names, and CVE references from Vulners and MITRE. ## What's new * **Notification groups.** Build flexible groups linking users, sites, and event topics, with per-recipient channel preferences (email, WhatsApp). * **Scheduled SLA reports.** Schedule daily, weekly, or monthly SLA reports delivered as PDF and JSON. * **MikroTik product catalog.** Hardware specs and compatibility data are now exposed via API. ## Fixed * Organization site counts correctly reflect zero when all team sites are removed. ## What's new * **Captive Portal.** Full guest-network control with OAuth2 sign-in, coupon-based access, instance management, and Walled Garden rules. * **DNS Content Filtering.** Apply DNS-level content filtering to a site through a managed policy. * **BGP Threat Mitigation.** Block known-bad IPs at the routing layer with BGP blackholing. * **Static IP Management.** Allocate static IPs to subscribers with RADIUS auth and PTR records. * **Developer API.** Programmatic platform control with authenticated command execution and asynchronous job dispatch. ## Improved * Stricter Walled Garden validation ensures IPs and ranges fall within their network instance subnet. ## What's new * **Network Inventory.** SDX now tracks devices on each site's network from the router's ARP, DHCP, and CDP tables, giving you fleet-wide device visibility without extra agents. * **Scheduled Scripts.** A scripting framework with variable injection runs RouterOS commands on a schedule for repeat maintenance and config drift correction. * **Configuration Backup.** Daily MikroTik backups land in secure cloud storage with API access for retrieval. * **Slack via webhooks.** Forward platform notifications to Slack to keep your team in the loop. ## What's new * **Altostrat SDX is live.** The platform launches with end-to-end MikroTik fleet management — site adoption, heartbeat monitoring, queued device jobs, and live management access through outbound tunnels. * **Identity, organizations, and billing.** Sign-in with users, organizations, and teams; API tokens; and a billing account, all under a single identity layer. * **Notifications.** Multi-channel alert delivery over email, WhatsApp, and real-time websockets so on-call engineers see incidents the moment they happen. * **Networking foundations.** Managed VPN (WireGuard and OpenVPN), WAN failover, and Static IP with RADIUS-integrated allocation. * **Monitoring foundations.** SNMP, ping, and syslog collection with query APIs, plus centralized log search and fault tracking. # Configure Captive Portals Source: https://altostrat.io/docs/sdx/en/connectivity/captive-portals/configuration Create captive portal auth integrations, instances, site assignments, and coupon workflows. This guide covers the standard captive portal setup path: configure authentication, create an instance, apply it to a site subnet, and operate sessions or coupons. ## Prerequisites Before you begin, make sure you have: * Permission to manage captive portal instances. * An adopted SDX site with the guest subnet you want to control. * For OAuth2, an application created in your identity provider. * For coupon access, a process for generating and distributing codes. * A session lifetime policy for guests. ## Create An OAuth2 Auth Integration Skip this section if your portal will use coupons only. In the portal, go to **Captive Portal**, then open **Identity Providers** or **Auth Integrations**. Add an integration and choose the provider type: Google, GitHub, or Azure. Provide the OAuth2 client ID and client secret. For Azure, also provide the tenant value. Save the integration, then test the sign-in flow before attaching it to a production portal instance. OAuth2 portals must allow unauthenticated users to reach the identity-provider flow. If your guest subnet blocks the provider domains before login, users will not be able to complete authentication. ## Create A Portal Instance Open **Captive Portal**, go to **Instances**, and create a new instance. Select **OAuth2** or **Coupon**. OAuth2 instances require an auth integration. Set the session TTL. Supported values range from 1,200 seconds to 604,800 seconds, which is 20 minutes to 7 days. Configure theme colors, logo or icon assets where available, locale, and terms text. Keep terms concise enough that guests can make an informed decision on a phone. Add the site and the exact subnet or subnets the portal should control. ## Generate Coupons For coupon-based portals, you can generate access codes on demand or through schedules. ### On-Demand Coupons 1. Open the captive portal instance. 2. Go to **Coupons**. 3. Generate between 1 and 200 coupons. 4. Set how long the coupons remain valid. 5. Export or share the generated codes through your approved process. ### Scheduled Coupons Use schedules when your team needs a repeatable batch, such as daily front-desk codes or weekly event access. 1. Open the instance and go to **Coupon Schedules**. 2. Create a schedule with the desired count and validity period. 3. Add the notification group or delivery process your operators use. 4. Use **Run now** when you need an immediate batch outside the normal schedule. ## Monitor Sessions Use captive portal user views to check who has connected, when their session expires, and whether a session should be terminated manually. When investigating a guest access issue, check these in order: 1. The site is online in SDX. 2. The portal instance is attached to the correct subnet. 3. The authentication strategy matches the guest's login method. 4. OAuth2 provider access is reachable before login, if applicable. 5. The user's coupon is valid, unexpired, and not already redeemed. ## Related Pages Follow a general SDX troubleshooting path before escalating. Route operational events to the right team. # Captive Portals Source: https://altostrat.io/docs/sdx/en/connectivity/captive-portals/introduction Understand captive portal instances, OAuth2 identity providers, coupons, and guest sessions in Altostrat SDX. Captive portals let you control guest access on selected site subnets. A user connects to the guest network, reaches the portal, authenticates with OAuth2 or a coupon, and receives temporary access according to the portal session settings. Use captive portals for guest Wi-Fi, hospitality access, event access, shared workspaces, or any site where temporary internet access needs to be governed and auditable. ```mermaid theme={null} flowchart LR Guest["Guest device"] --> Site["Managed site subnet"] Site --> Portal["Captive portal instance"] Portal --> Auth{"Authentication strategy"} Auth --> OAuth["OAuth2 provider"] Auth --> Coupon["Coupon code"] Auth --> Session["Timed user session"] ``` ## Core Concepts The portal configuration: name, strategy, session lifetime, theme, terms text, linked sites, and subnets. A reusable OAuth2 identity provider configuration. SDX supports Google, GitHub, and Azure-style integrations, with Azure requiring a tenant value. A generated access code for guest sessions. Coupons can be created on demand or through schedules for repeatable access operations. ## Authentication Strategies | Strategy | Best for | Requirements | | -------- | -------------------------------------------------------------------------- | ---------------------------------------------------------------- | | OAuth2 | Corporate guest access, accountable visitor access, identity-backed access | Auth integration, client ID, client secret, and tenant for Azure | | Coupon | Hospitality, events, front-desk distribution, temporary anonymous access | Coupon generation process and validity period | OAuth2 is strongest when you need to know who authenticated. Coupon access is strongest when staff need a simple code-based workflow that can be generated, shared, and expired. ## Session Lifetimes A portal session has a time-to-live. The service validates session TTL values from 20 minutes to 7 days. For OAuth2 portals, the authentication window is separate from the session lifetime. Keep the auth window short enough to reduce stale login attempts while still allowing users to complete the identity-provider flow. ## Sites And Subnets You apply a captive portal instance to specific sites and subnets. Be precise: * Apply the portal to guest VLANs or guest-only subnets. * Avoid applying it to infrastructure, management, or staff networks. * Keep walled garden and identity-provider requirements aligned with your chosen strategy. ## Next Step Create an auth integration, build a portal instance, apply it to a site, and generate coupons. # Connectivity and SD-WAN Source: https://altostrat.io/docs/sdx/en/connectivity/introduction Plan and operate Altostrat SDX connectivity services, including WAN failover, managed VPN, and captive portals. Altostrat SDX gives you a managed connectivity plane for MikroTik-based sites. You use it to keep branches online, connect sites and users privately, and control guest access without turning every router into a one-off project. This section focuses on the operator workflow: what you configure in the portal, what SDX pushes to the device, and where you monitor the result. ```mermaid theme={null} flowchart LR Site["Managed site"] --> Failover["WAN failover"] Site --> Portal["Captive portal"] Site --> Mgmt["Management VPN"] Site --> Vpn["Managed VPN peer"] Failover --> Faults["Faults and workflow events"] Portal --> Users["Guest sessions and coupons"] Vpn --> Private["Private site and user access"] Mgmt --> Ops["Monitoring, jobs, and transient access"] ``` ## Connectivity Services Define up to four WAN links for a site, rank them by priority, and monitor link health with latency, packet loss, jitter, and traffic data. Provision a cloud VPN instance and attach site peers or user peers with OpenVPN or WireGuard, depending on the peer type and use case. Create branded guest access experiences that authenticate users with OAuth2 identity providers or coupon codes. ## How The Pieces Fit Connectivity features are built on the same SDX operating model: * The portal stores the desired state for each service. * SDX validates the configuration against the site, workspace, and service rules. * Device changes are delivered through the job plane, so the router fetches work through its outbound management connection. * Faults, telemetry, and workflow events close the loop after the change is live. That model matters operationally. You can review state in the portal, follow job progress, and build workflows around connectivity events instead of relying on someone to notice a local router configuration drift. ## Where To Start Add WAN links, set priority, and understand how SDX reports link faults. Learn the instance and peer model before connecting sites or users. Choose OAuth2 or coupon authentication for guest access. Check the outbound destinations your firewalls must allow for SDX services. # VPN Instances and Peers Source: https://altostrat.io/docs/sdx/en/connectivity/managed-vpn/instances-and-peers Create a managed VPN instance, add site and client peers, and make practical routing decisions. This guide walks you through building a managed VPN fabric in SDX. You create an instance first, then attach site peers or client peers depending on who needs access. ## Prerequisites Before you begin, make sure you have: * Permission to manage VPN instances and peers. * A region selected for the instance. * For site peers, an adopted SDX site and the subnets you want to advertise. * For client peers, the user account that should receive VPN access. * A clear decision on split-tunnel versus route-all behavior for client access. ## Create An Instance In the portal, go to **VPN**, then open **Instances**. Click **Create Instance** and enter: * **Name:** a short operator-friendly label. * **Hostname:** a unique DNS-safe hostname between 3 and 20 characters. * **Region:** the deployment region closest to your expected peers. After you create the instance, wait for it to become available before adding production peers. The portal notes that provisioning can take approximately 10 minutes. Do not use reserved or generic hostnames such as `www`, `api`, `vpn`, `mail`, `cdn`, `assets`, `site`, `ns`, `rsync`, or `shell`. Use a name that clearly belongs to the workspace or environment. ## Add A Site Peer Use a site peer when a managed MikroTik site should advertise one or more local subnets to the VPN instance. Open the VPN instance, then go to **Peers**. Create a peer with type **Site**. Choose the SDX-managed site and select the protocol. The supported peer protocols are OpenVPN and WireGuard. Select only the subnets that should be reachable by other peers. Prefer specific prefixes over broad LAN-wide routing when possible. Save the peer, then monitor its status from the instance. If the peer does not connect, check the site's online state, subnet selection, and management connectivity. ## Add A Client Peer Use a client peer when a user needs remote access from a laptop or mobile device. In the instance **Peers** tab, add a peer with type **Client**. Select the user who should own the peer. Treat the peer profile as user-specific access material. Leave **Route all traffic** disabled for split-tunnel access, or enable it when all user traffic should pass through the VPN instance. Download or display the generated client configuration and give it to the assigned user through your approved access process. ## Operational Checks After peers are created: * Confirm the instance status is healthy. * Confirm each peer shows the expected connection state. * Verify advertised subnets from another peer before telling users the VPN is ready. * Review route-all client peers periodically because they carry more traffic through the instance. * Remove stale client peers when a user no longer needs access. ## Troubleshooting | Symptom | What to check | | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Site peer stays offline | Confirm the site is online in SDX, then check management connectivity and whether the selected interface can reach the VPN service. | | Client can connect but cannot reach a subnet | Confirm the subnet is advertised by a site peer and does not overlap with the client's local network. | | Client traffic is slower than expected | Check whether route-all is enabled and whether the instance region is far from the user. | | Hostname is rejected | Use a 3 to 20 character DNS-safe hostname and avoid reserved names. | ## Related Pages Use transient access when an operator needs short-lived management access to a site. Review the management endpoint model for SDX-connected sites. # Managed VPN Source: https://altostrat.io/docs/sdx/en/connectivity/managed-vpn/introduction Understand VPN instances, peers, protocols, and routing choices in Altostrat SDX. Managed VPN gives you a cloud-hosted private connectivity hub. You create a VPN instance in a region, then connect SDX-managed sites and individual users as peers. Use it when you need branch-to-branch connectivity, controlled access for remote users, or a simpler operational model than manually maintaining per-router VPN meshes. ## Core Concepts A VPN instance is the cloud hub. It has a name, hostname, region, routing settings, DNS settings, and a set of connected peers. A peer is a site or user that connects to the instance. Site peers advertise site subnets. Client peers give a user a downloadable VPN profile. ```mermaid theme={null} flowchart TD Instance["VPN instance"] --> SitePeer["Site peer
Managed MikroTik site"] Instance --> ClientPeer["Client peer
Assigned user"] SitePeer --> Subnets["Advertised subnets"] ClientPeer --> Access["Split tunnel or route all traffic"] ``` ## Peer Types | Peer type | Use it for | Required choices | | ----------- | --------------------------------------------- | ------------------------------------------------ | | Site peer | Connecting an SDX-managed site to the VPN hub | Site, protocol, and subnets to advertise | | Client peer | Giving one user a remote-access profile | User, protocol, and whether to route all traffic | Site peers can use OpenVPN or WireGuard where available. Client peers are designed around per-user access and can be configured for split-tunnel or full-tunnel behavior. ## Region And Hostname When you create an instance, choose a region close to the majority of peers. Region choice affects latency for both site-to-site and user access. The hostname becomes part of the public address for the instance. Hostnames must be unique, short, and DNS-safe. Avoid generic or reserved labels such as `www`, `api`, `vpn`, `mail`, `cdn`, and `ns`. New VPN instances are provisioned asynchronously. The portal indicates that a new instance can take approximately 10 minutes before it is available. ## Routing Choices For site peers, advertise only the subnets that should be reachable over the VPN. Avoid broad routes unless you intentionally want the instance to carry that traffic. For client peers, choose between: * **Split tunnel:** route only private or advertised networks through the VPN. * **Route all traffic:** send the user's general internet traffic through the VPN as well. Split tunnel is usually easier to operate and uses less bandwidth. Route-all is better when you need centralized egress, inspection, or a stricter access posture. ## Next Step Create a VPN instance, connect site peers, and issue client profiles. # WAN Failover Source: https://altostrat.io/docs/sdx/en/connectivity/wan-failover Configure and monitor prioritized WAN links for an Altostrat SDX managed site. WAN failover lets you model each internet connection at a site as a managed WAN tunnel. SDX keeps those links ordered by priority, monitors health, and records WAN events so you can operate failover as part of the wider platform. Use WAN failover when a branch depends on multiple upstream links, such as fibre plus LTE, copper plus 5G, or a primary ISP plus a secondary circuit. ## Prerequisites Before you configure WAN failover, make sure you have: * A site that is adopted into SDX and currently online. * At least two usable WAN connections on the MikroTik router. * The physical interface name for each connection, such as `ether1` or `lte1`. * The gateway IPv4 address for each connection. * Permission to manage WAN failover for the site. ## Core Model A WAN tunnel represents one internet path on one MikroTik interface. It stores the interface, gateway, link type, provider details, and enabled state. The first tunnel in the list is the preferred path. If it becomes unhealthy, SDX can move traffic to the next available link according to the configured order. WAN views show operational health, including latency, packet loss, jitter, receive rates, transmit rates, and related WAN faults. ```mermaid theme={null} flowchart LR Primary["Priority 1
Primary fibre"] --> Router["MikroTik site"] Backup["Priority 2
LTE backup"] --> Router Router --> SDX["Altostrat SDX"] SDX --> Metrics["WAN health metrics"] SDX --> Faults["Fault log and workflow events"] ``` ## Configure WAN Failover In the portal, go to **Sites**, select the site, then open **WAN Failover**. If WAN failover is not active, enable it for the site. SDX prepares the site for managed WAN configuration. For each link, define: * **Name:** a label operators can recognize quickly. * **Interface:** the MikroTik interface used by that connection. * **Gateway:** the upstream gateway IPv4 address. * **Type:** one of the supported link categories, such as fibre, copper, LTE, 5G, ethernet, coaxial, VSAT, microwave, or other. * **Provider and SLA details:** optional context that helps your team interpret faults and reports. SDX supports up to four WAN tunnels for a site. Order the WAN tunnels from most preferred to least preferred, then save the priority order. Use the most stable and cost-effective path first, and place metered or high-latency links lower unless your design requires otherwise. Watch the WAN failover page after the change is applied. Check that each tunnel reports the expected status and that latency, packet loss, jitter, and traffic data look believable for the circuit. ## Operate Failover Use the WAN page for configuration and the wider monitoring surfaces for operations: * Use the per-site **WAN Failover** page when you need to change interfaces, gateways, link types, or priority order. * Use the global **WAN Live** view when you need to compare link health across many sites. * Use the **Fault Log** to investigate when a link went offline, came back online, or experienced packet loss. * Use workflows when WAN events should create tickets, notify a team, or change priority automatically. If you use a cellular or satellite link as a backup, tag it clearly and put cost or usage expectations in the provider/SLA fields. Future operators should know why that link is lower priority before an outage starts. ## Testing Test WAN failover during a planned window, not during the first real outage. 1. Confirm all tunnels are online. 2. Notify anyone who monitors the site. 3. Move a backup link to the top of the priority order, or disconnect the primary link if your change window allows a physical test. 4. Confirm the active path changes as expected. 5. Restore the intended priority order. 6. Review the fault log and WAN metrics to make sure the event was captured. Changing WAN priority or physically disconnecting a link can interrupt traffic while routing converges. Test during a maintenance window for business-critical sites. ## Related Pages Learn how SDX records site and WAN events. See the WAN triggers and actions available in workflows. # Configuration Backups Source: https://altostrat.io/docs/sdx/en/fleet/configuration-backups Request, review, compare, and use MikroTik configuration backups as the safer reference point for change planning and troubleshooting. Configuration backups give you a stored view of router configuration over time. Use them before change windows, after policy or script rollout, and during incident review. ## Prerequisites Before you work with backups, make sure: * You have permission to view or request backups. * The site is online if you need a fresh backup. * You know which site and time window you are investigating. ## What Backups Are For Use backups to: * Review static router configuration. * Compare before and after states. * Validate what changed during a maintenance window. * Prepare rollback or recovery steps. * Investigate configuration drift without running live commands. For static configuration review, backups are usually a better first stop than the synchronous API. Use live commands when you need current runtime state. ## Request a Fresh Backup Go to **Sites**, open the target site, and select **Configuration Backups**. Select the action to request a fresh backup. SDX queues backup work for the router. The site must check in and complete the job before the backup appears. Open the backup and confirm it reflects the expected router and timestamp. ## Compare Backups Use backup comparison when you need to understand drift or validate a change. 1. Open the site's backup list. 2. Choose the earlier backup as the baseline. 3. Choose the later backup as the comparison. 4. Review additions, removals, and changed lines. 5. Record important differences in the change ticket or site notes. ## Restore Carefully Backups are reference material for recovery. Treat any restore-like operation as a production change: * Confirm you are using the correct site. * Confirm the backup predates the unwanted change. * Review site-specific values such as IPs, interfaces, credentials, and customer settings. * Schedule a maintenance window. * Keep out-of-band access available where possible. Do not apply old configuration blindly. A backup can include values that are no longer safe for the current network state. ## Troubleshooting If a requested backup does not appear: * Confirm the site is online. * Check whether other queued jobs are blocking progress. * Check the site job or orchestration history for errors. * Confirm the router has enough time and resources to export configuration. * Retry after the site is stable. If a backup looks incomplete: * Confirm you opened the intended timestamp. * Compare it with adjacent backups. * Use a live command only if you need to confirm current runtime state. # Control Plane Policies Source: https://altostrat.io/docs/sdx/en/fleet/control-plane-policies Use control plane policies to define which router management services are enabled and which source networks can reach them. Control plane policies define the management services SDX should allow on your MikroTik routers. They centralize settings for WinBox, SSH, HTTP, HTTPS, Telnet, FTP, API, and API-SSL access, including service ports and trusted networks. ## Prerequisites Before you change a policy, make sure you have: * Permission to create or update control plane policies. * A trusted-network list in CIDR format. * A recent configuration backup for any production site you will affect. * A maintenance window for broad rollout. ## How Policies Work When you save a control plane policy and attach it to sites, SDX records the policy and updates the affected site assignments. Device-side enforcement is delivered through the platform's management and job model, so a site must be reachable before the router can receive and apply the change. The policy model validates that: * Each management service has an enabled or disabled state. * Each service uses a valid TCP port. * Service ports do not conflict with each other. * Trusted networks and per-service networks use valid CIDR notation. If your account has no policy yet, SDX creates a default policy for the customer. The default policy is protected from deletion and is used as the fallback when a custom policy is removed. ## Create a Policy Go to **Policies > Control Plane**. Select **Add**, enter a clear policy name, and choose whether you need custom input rules. Add the CIDR ranges that should be allowed to reach management services. Enable only the services you need. Confirm ports are unique across services. Select the sites that should use the policy, then save. ## Roll Out Safely For production changes: 1. Apply the policy to a low-risk test site. 2. Confirm WinBox or SSH access behaves as expected. 3. Review the site orchestration or job history for failures. 4. Apply the policy to a small batch. 5. Expand to the remaining sites after validation. Control plane mistakes can lock your team out of management services. Keep at least one known-good access path and a recent backup before changing production management policy. ## Common Policy Decisions If your team does not use Telnet, FTP, HTTP, or non-SSL API access, disable them in the policy. Prefer narrow CIDR ranges for operations networks, bastion hosts, or trusted office networks. Use a documented port standard so support staff know what to expect during incidents. Attach the policy to a small number of sites before applying it fleet-wide. ## Troubleshooting If a policy does not appear to apply: * Confirm the site is online. * Confirm the site is attached to the intended policy. * Check whether the router has picked up the queued work. * Review the orchestration or job history for the site. * Verify the source IP you are connecting from is inside an allowed CIDR. Use the fleet troubleshooting checklist for policy and job-delivery issues. # Fleet Management Source: https://altostrat.io/docs/sdx/en/fleet/introduction Manage MikroTik sites at scale with SDX sites, policies, remote access, backups, tags, notes, and operational metadata. Fleet management is the day-to-day operating surface for SDX. It is where you create sites, check whether routers are online, review device context, apply management policies, request backups, and use secure remote access. ## What Fleet Management Covers Create and manage the site records that represent your MikroTik routers, then use site views to inspect status, metrics, inventory, faults, and settings. Define the management services and trusted networks that SDX should enforce for WinBox, SSH, HTTP, HTTPS, Telnet, FTP, API, and API-SSL access. Generate time-limited access for WinBox or SSH, or create a temporary port forward to reach a specific internal host and port. Browse stored router backups, request fresh backups, inspect backup content, and compare versions before or after change windows. Add structured context to sites so your team can filter, report, automate, and route ownership consistently. Use live and synchronized device data to understand what is connected behind your managed sites. ## The Site Lifecycle A site moves through a predictable lifecycle: 1. You create a logical site in the portal. 2. SDX generates onboarding material for that site. 3. The router runs the bootstrap command and begins sending heartbeats. 4. SDX enriches the site with device identity, tunnel details, metadata, and operational state. 5. Policies, backups, scripts, workflows, reports, and notifications use the site as their target. If a site is deleted, feature services that maintain per-site projections can clean up related state. Treat deletion as permanent operational cleanup, not as a troubleshooting step. ## What to Standardize First Before adding many sites, define: * A naming convention for sites. * Required tags, such as region, customer, environment, service tier, or owner. * A default control plane policy. * A backup and change-window practice. * A notification group for critical site and WAN events. * A support workflow for offline sites and failed jobs. Good fleet hygiene pays off later. Tags, clean names, and backup coverage make reports, dashboards, workflows, and incident response much easier to trust. ## Related Pages Bring a router online as a managed SDX site. Diagnose offline sites, failed jobs, backup issues, and remote access failures. # Managing Sites and Devices Source: https://altostrat.io/docs/sdx/en/fleet/managing-sites-devices Create, review, update, and retire SDX sites while understanding how heartbeats and asynchronous jobs affect site state. A site is the operational record for a managed MikroTik router. SDX stores the site record, enriches it with metadata, and uses it as the target for policies, jobs, backups, scripts, workflows, metrics, and reports. ## Prerequisites Before you manage sites, make sure you have: * Permission to view or manage sites. * A clear naming and tagging standard for your organization. * Router access if you are onboarding a physical device. * A control plane policy ready for new sites. ## Create a Site In the SDX portal, go to **Sites**. Select **Add**, enter a site name, and save the record. Open the new site, generate the bootstrap command, run it on the MikroTik router, and wait for the first heartbeat. Add tags, notes, and any required metadata after the site appears online. ## Understand Site Status The router is checking in and SDX has recent heartbeat data. Live commands and remote access are more likely to succeed. SDX has not received expected heartbeats. Queued jobs can still be accepted by SDX, but the router cannot pick them up until it reconnects. The most recent timestamp SDX has for the site. Use this with fault history when you investigate intermittent links. The management tunnel state. Live commands and transient access depend on the active management path for the site. ## Review a Site Open a site to inspect: * Overview and status * Device identity and RouterOS details * Metrics and live dashboard data * Fault event log * Inventory and discovered devices * Remote access tools * Configuration backups * WAN failover settings * API credentials and management settings * Notes, metadata, and tags Some views use stored data and remain useful while a site is offline. Live views require the management path to be available. ## Edit Site Details Use the site settings or overview actions to update the site name, notes, tags, metadata, or operational settings. Keep names human-readable because they appear in dashboards, reports, notifications, workflow context, and search. Changing metadata is usually immediate in the portal. Applying a device-level change, such as a policy update or job, may be asynchronous. ## Delete a Site Only delete a site when you are sure the router should no longer be managed by SDX. Deleting a site removes the operating record used by downstream features. If you are troubleshooting an offline router, keep the site and use the troubleshooting checklist instead. Before deletion: * Export or review any backups you need to retain. * Check whether workflows, reports, policies, or notification rules depend on the site. * Confirm the site is not part of a managed VPN, captive portal, WAN failover, or security rollout. * Record the reason in your internal change or ticketing system. ## Best Practices Use names that make sense in an alert at 2 a.m. Avoid internal abbreviations that only one person understands. Create consistent tag keys before you onboard many sites. Retrofitting tags after reports and workflows exist is slower. Request a fresh backup before policy, script, WAN, or security changes. Do not rely only on the current status badge. Review recent faults and heartbeat history for intermittent issues. # Metadata, Tags, and Site Files Source: https://altostrat.io/docs/sdx/en/fleet/metadata-and-tags Use tags, metadata, notes, media, and documents to make your SDX fleet searchable, reportable, and automation-ready. Metadata turns a list of routers into an operable fleet. Tags and site files give your team enough context to filter sites, assign ownership, build reports, trigger workflows, and investigate incidents quickly. ## Prerequisites Before you standardize metadata, decide: * Which tag keys are required for every site. * Which values are allowed for each tag key. * Who owns tag definitions. * Which notes or documents should be attached to sites. * Whether tags should be mandatory for sites or other resource types. ## Metadata Types Structured key-value context. Tags support filtering, reporting, workflow conditions, and resource selection. Human-readable operational context, such as access instructions, circuit notes, or support history. Site images or visual context that helps identify the location or installation. Files attached to the site, such as handover notes, diagrams, maintenance records, or customer documentation. ## Design a Tag Model Start with a small number of high-value tags. Common tag keys include: * `region` * `customer` * `environment` * `service-tier` * `owner` * `site-type` * `maintenance-window` Use predictable values. For example, choose either `production` or `prod`, not both. Tags become inputs to reports and workflows. Keep them boring, consistent, and easy to audit. ## Create a Tag Definition Go to **Settings > Tag Management**. Add the tag key, choose a color, and define whether the tag should be mandatory for one or more resource types. Add tag values to sites or other supported resources. Review which sites are missing mandatory tags and fill gaps before using the tag in workflows or reports. ## Add Site Context From a site, use metadata, notes, media, and documents to capture context that is not visible from RouterOS alone: * Physical location or rack notes * ISP and circuit references * Customer contacts * Internal escalation notes * Photos of the installation * Change or handover documents ## Use Tags in Operations Tags are most valuable when they drive action: * Filter sites in fleet views. * Select sites for reports. * Route workflow logic with resource tag conditions. * Apply or remove tags from a workflow. * Group operational ownership by region or customer. ## Best Practices Rename tag keys rarely. Downstream workflows and reports may rely on them. Use a limited set of approved values where possible. If a tag is required, explain who owns it and what each value means. Do not store passwords, private keys, or tokens in metadata, notes, files, or tag values. # Secure Remote Access Source: https://altostrat.io/docs/sdx/en/fleet/secure-remote-access Use time-limited transient access and transient port forwarding to reach managed sites through the SDX management path. Secure remote access lets you reach a managed site without opening permanent inbound firewall rules to the router. SDX creates temporary access through the site's management server and automatically expires it. ## Prerequisites Before you create remote access, make sure: * The site is online. * The site has an active management tunnel and management server. * Your role allows transient access or transient port forwarding. * Your client network is allowed by the CIDR you enter. * You know whether you need router management access or access to an internal host behind the router. ## Access Types Creates temporary WinBox or SSH access to the managed router. You choose the access type, expiry, and allowed source CIDR. Creates a temporary forward to a specific destination IP and port behind the site. Use this for short-lived access to an internal service. Transient access can last from 15 minutes up to 24 hours. Use the shortest useful duration for the task. ## Create WinBox or SSH Access Go to **Sites**, open the target site, and select **Remote Access**. Select WinBox or SSH. Choose an expiry between 15 minutes and 24 hours. Enter the CIDR that should be allowed to use the temporary access. Create the access record, copy the generated connection details, and connect before the expiry time. For emergency work, create access for the specific engineer or jump-host CIDR instead of using a broad network range. ## Create a Temporary Port Forward Use transient port forwarding when you need to reach a device or service behind the managed router. From the site, open **Remote Access** and choose the port-forwarding option. Provide the internal destination IP address and destination port. Add the allowed source CIDR and select the shortest duration that supports the task. Use the generated entry point while the forward is active. ## Revoke Access Revoke active access as soon as the task is complete. Expiry is a safety net, not a substitute for closing unused sessions. ## Troubleshooting If remote access fails: * Confirm the site is online. * Confirm the management server is available for the site. * Confirm your current public IP is inside the allowed CIDR. * Confirm you are connecting before the expiry time. * For port forwarding, confirm the internal destination IP and port are reachable from the router. * Try a shorter, newly generated access record if the first one expired or was copied incorrectly. Do not use transient access as permanent remote access. It is designed for time-bounded operations, support, and incident response. # Core Concepts Source: https://altostrat.io/docs/sdx/en/getting-started/core-concepts Learn the SDX terms you need before managing sites, policies, workflows, and monitoring. Altostrat SDX is easier to use when you separate the things you manage from the systems that carry out the work. A site is the object you see in the portal. The device job plane, management tunnel, metadata store, and workflow engine are the systems that keep that site useful. ## Organization Model The top-level account boundary. Organizations contain workspaces, users, teams, billing settings, and governance configuration. The tenancy and billing container. Workspaces hold the SDX resources your team operates. The collaboration boundary for day-to-day access. Teams collect users and apply roles to the resources they can work with. A permission set. Portal navigation and actions are scope-gated, so users only see what their role allows. ## Network Objects A site represents a managed MikroTik router and its operational context: status, tunnel information, metadata, tags, notes, backups, metrics, faults, and feature assignments. The outbound management path between a site and Altostrat regional infrastructure. It supports remote access, synchronous commands, and management-side operations. A reusable configuration object that can be attached to one or more sites. Examples include control plane, content filtering, BGP threat, security group, and prefix list policies. Structured context you attach to sites and other resources. Tags support filtering, reporting, workflow conditions, and operational ownership. ## Execution Concepts A regular check-in from the router. Heartbeats feed online status, last-seen data, device inventory, and availability reporting. A queued unit of work for a router. Scripts, backup requests, policy pushes, ARP syncs, VPN updates, and selected feature actions all use the same job pattern. A live command sent through the management server when the site is reachable. Use this for current state, not for reading static configuration you can get from backups. One execution of a workflow. Runs have triggers, node results, logs, and context passed between actions and conditions. ## Operational Concepts A normalized operational incident, such as a site outage or WAN state change. Faults feed dashboards, notifications, workflows, and SLA reporting. A reusable time window. Schedules can control when automations, reports, scripts, and notifications should run or deliver. A routing rule for who gets told about operational events, and through which channels or integrations. A generated operational artifact, such as an SLA report or vulnerability report, built from stored platform data. ## Next Step Learn how heartbeats, jobs, live commands, faults, notifications, and reports behave in real operations. # Introduction to Altostrat SDX Source: https://altostrat.io/docs/sdx/en/getting-started/introduction Understand what Altostrat SDX does, how it fits around your MikroTik fleet, and where to start in the documentation.