Multi Account Usage

The Saner Python SDK supports creating multiple SanerClient instances within the same script. This enables developers to interact with different accounts, environments, or infrastructures simultaneously without reinitializing authentication contexts.

This capability is especially useful in automation platforms, managed service provider workflows, and cross-environment orchestration pipelines.

Note: This page is about running multiple instances of one client class: one per account, region, or environment. It's a different question from which client class (SanerClient, PlatformClient, or CvemClient) to instantiate in the first place. See the "Client Types" guide for that decision. The two are independent and combine freely: nothing stops you from running multiple CvemClient instances, one per account, using the patterns on this page.


Basic Example

You can create multiple independent client objects like this:

from saner import SanerClient

client1 = SanerClient(api_key="KEY1", accountid="AccountA")
client2 = SanerClient(api_key="KEY2", accountid="AccountB")

Each client maintains its own:

  • authentication context
  • base URL
  • retry configuration
  • timeout settings
  • logging destination

This ensures complete isolation between environments.

Note: api_key, accountid, base_url, and verify_ssl can each be read from an environment variable when omitted from the constructor (see the "Client Configuration" guide). That fallback only applies to an omitted argument. Always pass an explicit api_key and accountid to each client when running multiple instances in one script, otherwise every client that omits them resolves to the same environment values and the isolation shown below is lost.


Real-World Example

Below is a practical example demonstrating interaction across multiple Saner environments in a single script:

from saner import SanerClient

client1 = SanerClient(
    api_key="API_KEY_1",
    accountid="ACCOUNT_1",
    base_url="https://eu.saner.secpod.com",
    enable_logging=True
)

client2 = SanerClient(
    api_key="API_KEY_2",
    accountid="ACCOUNT_2",
    base_url="https://in.saner.secpod.com",
    enable_logging=True
)

client3 = SanerClient(
    api_key="API_KEY_3",
    accountid="ACCOUNT_3",
    base_url="https://uk.saner.secpod.com",
    enable_logging=True,
    timeout=10
)

response = client2.platform.Organization.add(
    name="Demo Org",
    email="[email protected]",
    numberofsubscriptions="100"
)

print(response)

response = client1.platform.Organization.get(
    organization="Demo Organization"
)

print(response)

This script interacts with three independent Saner environments simultaneously.


When to Use Multiple Client Instances

Running one client instance per target is recommended when working across multiple tenants, regions, or infrastructure layers.

Multi-Tenant Automation

Useful when managing multiple customer environments from a single automation pipeline.

Example scenarios:

  • security posture monitoring across tenants
  • vulnerability aggregation across organizations
  • centralized reporting dashboards

Example structure:

Tenant A → client1
Tenant B → client2
Tenant C → client3

Cross-Environment Workflows

Helpful when operating across development, staging, and production environments.

Example:

Dev Environment → client_dev
Staging Environment → client_stage
Production Environment → client_prod

Common use cases:

  • migration validation
  • configuration comparison
  • rollout verification
  • staged deployment automation

MSP (Managed Service Provider) Integrations

MSPs often manage multiple customer accounts simultaneously. Running one client instance per customer enables building scalable orchestration tools without repeatedly reinitializing sessions.

Typical workflows include:

  • automated onboarding
  • policy synchronization
  • compliance checks
  • scheduled vulnerability scans
  • cross-customer reporting

Each customer account maps to one client instance.


Logging Across Multiple Client Instances

The SDK logging system is designed to work seamlessly with multiple client instances.

Each client automatically writes logs to a separate file based on:

  • account ID
  • base URL
  • log directory (log_dir)

Example:

logs/secpod-saner-sdk__ACCOUNT_1__a1b2c3d4.jsonl
logs/secpod-saner-sdk__ACCOUNT_2__e5f6g7h8.jsonl
logs/secpod-saner-sdk__ACCOUNT_3__z9x8c7v6.jsonl

This ensures:

  • environment isolation
  • account-level traceability
  • parallel execution safety
  • simplified debugging across tenants

Because logging is scoped to accountid/base_url/log_dir rather than to a specific client object, running multiple clients with distinct values in the same script does not overwrite or mix log data. See the "Logging" guide for the one exception: two client instances (even of different classes) that share identical accountid/base_url/log_dir values write to the same file.

Note: Two clients with the same accountid and base_url but different log_dir values will write to two distinct files, since log_dir is part of what makes the filename unique. If you intend for two client instances to share one log file, use the same accountid, base_url, and log_dir for both.


Benefits of Running Multiple Client Instances

Using multiple client instances provides several operational advantages:

  • simultaneous access to multiple environments
  • independent retry and timeout policies per client
  • isolated authentication sessions
  • structured per-account logging
  • scalable automation design patterns
  • improved debugging visibility across workflows

This architecture enables building enterprise-grade orchestration scripts that interact with multiple Saner deployments efficiently and safely.


Did this page help you?