[Connettori mock deterministici, nessun traffico in uscita live]

Ambiente sandbox

Testa le integrazioni contro connettori mock deterministici senza alcun traffico in uscita verso il partner live. Emetti un token sandbox (`aud=sandbox`) su `auth.knogin.com`, chiama la stessa superficie v2026.4 contro `https://sandbox-api.knogin.com` e ricevi risposte identiche byte per byte ad ogni replay dello stesso payload.

Ambiente sandbox

Iniziare

L’accesso al sandbox passa dal flusso standard di admin di piattaforma. Con lo scope `argus:platform:admin` su un bearer token, chiama `POST /v1/platform/apps/{client_id}/sandbox-token` per emettere un JWT sandbox per l’app che stai cablando. La risposta porta l’host sandbox (`https://sandbox-api.knogin.com`) e l’elenco degli scenarios pinnati al token. Punta il tuo SDK partner esistente all’host sandbox, sostituisci il token live con quello sandbox e l’intera superficie v2026.4 viene istradata verso mock deterministici in modo trasparente.

Emissione del token

`POST /v1/platform/apps/{client_id}/sandbox-token` accetta un array `scenarios` opzionale (pinna il sandbox su dati predefiniti, ad es. `["wallet.high-risk", "entity.sanctioned"]`) e un `ttl_seconds` opzionale (limitato all’intervallo inclusivo [60, 86400]; i valori fuori range vengono normalizzati prima della firma). La risposta include il token sandbox firmato, il suo `expires_at`, `audience: "sandbox"`, l’insieme di scope incorporato nel token, l’host sandbox e gli scenarios pinnati. Il token sandbox riusa il keyset RS256 esistente di auth_service; l’header `kid` punta allo stesso JWKS usato da `/oauth/token`, così gli SDK partner validano i token sandbox out of the box.

Catalogo scenarios

Cinque scenarios vengono spediti nel primo rilascio. Pinnane uno o più nel campo `scenarios` al momento dell’emissione del token affinché il sandbox restituisca gli stessi dati predefiniti ad ogni replay; ometti il campo per la rotazione mista di default.

Doppio cancello

Argus impone il no-leak in entrambe le direzioni. L’host sandbox (`sandbox-api.knogin.com`) rifiuta i token live: il middleware di routing controlla la claim `aud` del JWT e respinge con 403 quando `aud != "sandbox"`. I connettori live rifiutano i token sandbox: ogni factory `<provider>_client.py` live controlla `request.state.sandbox` e solleva un 403 se la richiesta è in scope sandbox. I test coprono entrambe le direzioni, così un token live non può leggere per errore dati mock e un token sandbox non può raggiungere i sistemi live del partner.

Determinismo

Le risposte sandbox sono deterministiche. Lo stesso payload, sparato due volte con gli stessi scenarios pinnati, restituisce una risposta identica byte per byte. È voluto: le pipeline di CI partner possono fare snapshot delle risposte sandbox e asserirvi contro ad ogni build senza retry-flake. Le risposte sandbox portano inoltre `X-Argus-Sandbox: true` così gli strumenti di debug partner vedono a colpo d’occhio che la risposta è sintetica, conservando il `X-Argus-Trace-ID` standard di G2 per la correlazione end-to-end con i tuoi log.

Fatturazione e quota

Le chiamate sandbox non consumano la tua quota live di connettori partner e non sono fatturabili. Non toccano mai provider OSINT o finance reali, non raggiungono mai dataset sensibili e non entrano mai nei budget di rate-limit che hai negoziato per la produzione. Le voci di audit dal traffico sandbox sono taggate `secrecy_level=sandbox` così gli operatori possono filtrare il traffico sandbox dai report di conformità. Usa il sandbox liberamente per test di integrazione, prove di onboarding partner, registrazioni demo e CI esplorativa; i budget di produzione restano intatti.

Migrazione verso produzione

Quando la tua integrazione è pronta, scambia la base URL da `https://sandbox-api.knogin.com` a `https://api.knogin.com` e riemetti un token live tramite il flusso standard `POST /v1/oauth/token` con i tuoi scope di produzione. Forma sul wire, header, status code e propagazione del trace sono identici tra sandbox e live, quindi un client validato in sandbox non richiede modifiche di comportamento. L’unica differenza a runtime è la claim `aud` del JWT e l’host a cui punti.

Catalogo scenarios

ID scenarioEtichettaDescrizione
wallet.high-riskWallet ad alto rischioRestituisce arricchimenti che indicano hit su sanzioni, interazione con mixer e trasferimenti rapidi ad alto volume.
wallet.cleanWallet pulitoRestituisce arricchimenti che indicano attività a basso rischio e nessun hit su sanzioni.
entity.sanctionedEntità sanzionataRestituisce arricchimenti OSINT con corrispondenze su liste OFAC, UN ed UE.
incident.escalatingIncidente in escalationRestituisce segnali dispatch ed ePCR coerenti con una situazione in peggioramento.
device.offlineDispositivo medico offlineRestituisce telemetria che indica last-seen N ore fa con stato batteria stantio.

Emettere un token sandbox

# Mint a sandbox token (requires argus:platform:admin)
curl -X POST https://auth.knogin.com/v1/platform/apps/app_123/sandbox-token \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "scenarios": ["wallet.high-risk", "entity.sanctioned"],
    "ttl_seconds": 3600
  }'

# 200 OK
# {
#   "token": "<sandbox-jwt>",
#   "expires_at": "2026-05-08T13:00:00Z",
#   "audience": "sandbox",
#   "scopes": [
#     "argus:profiles:read",
#     "argus:profiles:write",
#     "argus:jobs:read",
#     "argus:jobs:write"
#   ],
#   "sandbox_host": "https://sandbox-api.knogin.com",
#   "scenarios": ["wallet.high-risk", "entity.sanctioned"]
# }

Elencare gli scenarios sandbox

# Discover the scenario catalogue (sandbox host only)
curl https://sandbox-api.knogin.com/v1/sandbox/scenarios \
  -H "Authorization: Bearer $SANDBOX_TOKEN"

# 200 OK
# {
#   "scenarios": [
#     { "id": "wallet.high-risk", "label": "High-risk wallet", "description": "..." },
#     { "id": "wallet.clean", "label": "Clean wallet", "description": "..." },
#     { "id": "entity.sanctioned", "label": "Sanctioned entity", "description": "..." },
#     { "id": "incident.escalating", "label": "Escalating incident", "description": "..." },
#     { "id": "device.offline", "label": "Offline medical device", "description": "..." }
#   ]
# }

# A live token against the sandbox host fails closed:
# HTTP/1.1 403 Forbidden
# X-Argus-Sandbox-Reason: live-token-on-sandbox-host

Chiamare la superficie sandbox

# Same v2026.4 surface, sandbox host, sandbox token.
# Two replays of the same payload return a byte-equal response.
curl -X POST https://sandbox-api.knogin.com/v1/jobs \
  -H "Authorization: Bearer $SANDBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "intelligence.enrich.bulk",
    "payload": { "profile_ids": ["p1", "p2"] }
  }'

# Response carries:
#   X-Argus-Sandbox: true
#   X-Argus-Trace-ID: <32-hex>   (G2 trace propagation, unchanged)

# When ready for production, swap the base URL and re-mint a live token:
curl -X POST https://auth.knogin.com/v1/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id=app_123&client_secret=<secret>&scope=argus:jobs:write"

curl -X POST https://api.knogin.com/v1/jobs \
  -H "Authorization: Bearer $LIVE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "kind": "intelligence.enrich.bulk", "payload": { "profile_ids": ["p1"] } }'

Pronto a cablare la tua integrazione tramite il sandbox?

Apri la reference API per il contratto pubblico o contatta Knogin se hai bisogno di una fixture di scenario su misura per il tuo workflow partner.