Configuring targets at scale

Once the first target is running, scaling up is mostly a question of reusing configuration. This guide covers three patterns every team adopts as they add more targets: shared auth profiles, per-environment scope templates, and workspace-level rate limits.

Shared auth profiles#

Most targets in a workspace authenticate the same way. Rather than repeating the auth block inside every target, define a named auth profile at the workspace level and reference it from each target.

# workspace-level
auth_profiles:
  internal-api:
    type: "bearer"
    token_source: "env:INTERNAL_API_TOKEN"
    refresh:
      interval_minutes: 30

# target-level
target:
  name: "staging-api"
  base_url: "https://staging.api.example.com"
  auth_profile: "internal-api"

Every target that references internal-api picks up the same token, refresh behaviour, and credential rotation. When a secret rotates you update the profile once and every target follows.

For OAuth-protected targets, the same pattern applies but the profile carries the access token (and optional refresh token + token URL) supplied by your identity provider — Pentrova does not drive the upstream OAuth dance itself, see the Configuring authentication guide for the full schema.

Per-environment scope templates#

Staging, QA, and production usually share a URL shape but differ on what is safe to scan. Express the differences as a scope template and reference it by environment name.

scope_templates:
  default:
    include: ["/v1/**"]
    exclude: ["/v1/admin/danger/**", "/v1/health"]
  production_safe:
    include: ["/v1/**"]
    exclude: ["/v1/admin/**", "/v1/write/**", "/v1/health"]

target:
  scope_template: "production_safe"

Production targets automatically pick up the conservative exclusion list without anyone having to remember to add it on day one.

Workspace-level rate limits#

Per-target rate limits are useful when one target needs a tighter cap, but the common case is a workspace-wide ceiling that every target inherits. Configure default_rate_limit at the workspace level and override per target only when you need to.

default_rate_limit:
  rps: 20
  concurrent: 4

This keeps the configuration small, makes rollouts safer, and means new targets inherit a sensible default without requiring every team to rediscover it. The full list of rate-limit fields is in the API reference overview under TargetConfig.

Next steps#

Once the workspace hosts more than about fifteen targets, adopt tags on every target so release gates, reporting, and the Authorization Matrix can operate on groupings rather than individual names.