Cryptographic verification is offline-first. The optional trigguard npm helper can call discovery endpoints; execution integration uses @trigguard/execution-sdk from the runtime documentation against your gateway URL.
PROBLEM
Integration inconsistency breaks authorization guarantees
Teams need a consistent way to call TrigGuard from services, CI pipelines, and infrastructure automation without rewriting decision-handling logic for every surface.
WHAT IT DOES
Standard SDK interface for execution authorization
The SDK packages request construction, decision handling, and receipt-aware patterns into a reusable developer workflow.
Capabilities
- Execution authorization
- Policy enforcement
- Receipt generation
- Audit verification
HOW IT WORKS
Two paths: offline verification vs execution (gateway)
Execution path (open-source clients, your gateway URL):
@trigguard/execution-sdk → POST /execute → PERMIT | DENY | SILENCE → signed receipt
Verify receipts offline using /.well-known/trigguard-keys.json + CLI or /verify
Optional npm client "trigguard" (legacy HTTP interop only; not the trust path):
tg.protocol.capabilities() -> GET /protocol/capabilities
# Prefer trigguard verify-receipt or https://www.trigguardai.com/verify for crypto verifyINSTALL
What ships today
Package inventory and install sequence are maintained in canonical onboarding and runtime docs. Use /docs/quickstart for step-by-step setup and /docs/runtime for runtime SDK integration.
SDK references: trigguard · @trigguard/protocol · @trigguard/execution-sdk
EXAMPLE
Canonical implementation examples
This product page defines SDK scope. For runnable examples and step-by-step implementation, use /docs/quickstart, /docs/runtime, and /docs/examples. For receipt validation flow, use /verify and /docs/verification.
INTEGRATION
SDK and API Integration Across CI/CD
RELATED LINKS