Run a sandbox evaluation against saved rulesets and saved APIs.
Synchronously evaluate one or more saved APIs against a selected set of rulesets and return the violations inline. No persistence. Used by the Ruleset Test Sandbox UI (“Test ruleset” on the ruleset detail screen and the API Governance Tab).
Rulesets are selected via either ruleset_ids (explicit) or categories (executes every active ruleset whose categories intersect the input) — exactly one of the two. APIs are selected via api_ids (required). This endpoint takes references only — to evaluate an API definition submitted in the request (CI/CD file, UI draft), use POST /api/evaluations/sandbox/oas. Caps: 10 APIs, 20 resolved rulesets, 20 input categories, 1,000 issues per response.
Authorizations
The Tyk Dashboard API Access Credentials
Body
Sandbox evaluation request — saved resources only. Exactly one of ruleset_ids / categories must be provided (non-empty). To evaluate an API definition submitted in the request body, use POST /api/evaluations/sandbox/oas instead.
APIIDs of saved APIs in the caller's org. Classic (non-OAS) APIs are rejected.
1 - 10 elementsStable RulesetIDs of saved rulesets in the caller's org. Soft-deleted rulesets are rejected. Inactive rulesets are accepted — sandbox semantics are "test this ruleset", regardless of whether it's currently driving the async dispatcher.
1 - 20 elementsCategory names. Server resolves to every active, non-deleted ruleset whose categories intersect this list, scoped to the resource_type of each resolved API. Use this for the "run an entire compliance category against this API" workflow.
1 - 10 elementsResponse
Evaluation completed. The response may include a non-empty error string when the engine returned failures for some (ruleset, api) pairs while others succeeded; successful pairs' issues are still present in issues. An empty rulesets[] indicates no rulesets matched (category resolution returned none, or all matching rulesets had a different resource_type than the APIs).
Rulesets actually executed in this run. Single-ruleset callers see one entry; category-based callers see the resolved set. Each entry carries the ruleset's configured action and its per-ruleset severity counts. Empty array means no rulesets matched the request (category input with no intersection, or the only matches had a different resource_type than the APIs).
Per-rule violations across all evaluated APIs, sorted by severity then location. Capped at MaxSandboxIssues (1000) — see truncated. Shared row schema with /api/governance/issues.
Un-truncated issue count produced by the engine.
True when total > MaxSandboxIssues and issues was capped. FE renders a banner; CI/CD pipelines should treat this as a failure since the build is being gated against partial data.
Run-wide count of severity-0 (error) issues, computed pre-truncation — trustworthy even when issues is capped. Count field names and severity mapping match the persisted ApiGovernanceResult summaries (tyk_governance_api_summaries).
Run-wide severity-1 (warn) issue count, pre-truncation.
Run-wide severity-2 (info) issue count, pre-truncation.
Run-wide severity-3 (hint) issue count, pre-truncation.
Number of APIs the engine actually applied rules against. Always 1 for /sandbox/oas.
Wall-clock duration of engine.Evaluate, in milliseconds.
Joined error string when the engine returned failures for some (ruleset, api) pairs (per errors.Join from the mechanism story). Absent on full success. Per-pair attribution is deferred — see ticket.