Verify mode is the sweet spot between observability and enforcement.
You still call the LLM yourself (no proxying, no key sharing), but
before returning the answer you ask PromptWall: “is this safe to
show?”. PromptWall returns
allow, block, or rewrite and you act
on it.⚡ 30-second integration
Three steps. Each step says exactly where the code goes — terminal or a specific file.- 🐍 Python
- 🟨 Node.js
- 🔧 cURL
Step 1 — In your terminal, install the SDK:Step 2 — Create a new file Step 3 — Back in your terminal, run the file:You should see
Terminal
test_promptwall.py in any folder.
Paste this and replace pk_live_xxxxxxxx with your real key from
prompt-wall.com/settings → Apps → + New App → Verify:test_promptwall.py
Terminal
governance: allow and the original answer echoed
back. That confirms the call works.Step 4 — Wire it into your real LLM call. In whichever existing
file holds your openai.ChatCompletion.create(...) (commonly
app.py, services/chat.py, routes/chat.py), wrap the answer:services/chat.py (your existing file — edit it)
Don’t have an API key yet? Sign up at
prompt-wall.com/signup (free —
$50 of credits), then click + New App in Settings and pick mode
Verify. Copy the
pk_live_… key shown on the final step (it’s
only displayed once — save it).When this mode is right for you
✅ Pick Verify when…
- You want real enforcement — block PII leaks, jailbreak echoes, off-topic answers — but you can’t replace your LLM call
- Your LLM stack is locked-in (Bedrock, Azure OpenAI, internal gateway) and a proxy is impossible
- You want a clear separation of concerns: PromptWall verifies, your code stays in control of what the user sees
- You’re OK adding ~80–200 ms to the critical path
❌ Don't pick Verify if…
- You only need observability — Events is cheaper (90/M) and zero-latency
- You want a single API to call instead of two — see Full Control
- You need to enforce on the prompt before hitting the LLM — Full Control runs both pre-flight and post-flight checks
prompt_tokens + completion_tokens you send. Failed verifications
(network errors, timeouts) are not billed.
What you’ll build
The verify call adds latency to your user-visible response — typical 80–200 ms p95. Always set a timeout and have a fallback path for when PromptWall is unreachable (see Failure modes below).Choose your integration
- 🐍 Python SDK
- 🟨 Node.js SDK
- 🔧 cURL / raw HTTP
- 📦 Other languages
Step 1 — Install the SDK
Step 2 — Add API key to your environment
Create new file:
.env (in your project root). If .env already
exists, add the line below. Make sure .env is in .gitignore..env
pk_live_… key
shown on the final step (it’s only displayed once).An app provisioned for Verify can also call
/v1/events — Verify
is a strict superset. The reverse is not true: an Events-only key
cannot call /v1/verify.Step 3 — Create a thin wrapper
Create new file:
lib/promptwall_client.py (or wherever you keep
shared infrastructure code).lib/promptwall_client.py
Step 4 — Wire into your existing LLM call
Edit existing file: wherever you call OpenAI / Anthropic / etc.
Common locations:
app.py, main.py, services/chat.py,
routes/chat.py. Find the place you receive the LLM response and
return it to the caller.services/chat.py (before)
services/chat.py (after)
Step 5 — Verify it worked
Run a request through your app, then open prompt-wall.com/observability.Within ~3 seconds you should see:- Requests counter ticked up
- A new row in Recent Traces with mode badge Verify
- The decision (
allow/block/rewrite) shown on the row
block, reason
security.prompt_injection, severity high. Your caller received
SAFE_FALLBACK.Step 6 — Deploy to production
SetPROMPTWALL_API_KEY as a secret in your hosting platform:Restart / redeploy after setting it.
Common patterns
Multi-turn conversations
Pass a stablesession_id on every verify call in a single conversation
so PromptWall can replay the entire thread on
/sessions:
Verifying tool / RAG output
If you ran a function-call or pulled RAG context before the LLM answer, pass it astool_result. PromptWall will scan the tool output
for prompt-injection separately from the final answer:
Fail-open vs fail-closed
When/v1/verify is unreachable (network, 5xx, timeout), you have two
options. Pick per app based on the cost of a wrong answer:
The wrappers in Steps 3-4 default to fail-open. To switch to
fail-closed, return
SAFE_FALLBACK (or raise) inside the except
block.
Per-environment splitting
Create one App per environment in Settings → Apps. Each gets its own API key. Use the right key per environment:Custom metadata for filtering
metadata.feature = "customer-support-bot".
Complete worked example — copy this into a new project
If you want to see what a real, runnable app looks like end-to-end (not just snippets), here are two complete starter projects.Python (Flask)
A minimal Flask server that exposesPOST /chat, calls OpenAI, and
verifies the answer through PromptWall before responding.
Project layout — five files in a single directory:
requirements.txt (create new)
requirements.txt
.env (create new — add to .gitignore)
.env
lib/promptwall_client.py (create new — same as Step 3)
lib/promptwall_client.py
app.py (create new — the runnable server)
app.py
{"answer": "Paris is the capital of France.", "governance": "allow", "request_id": "req_..."}. Try a jailbreak prompt to see governance: "block" instead.
Node.js (Express)
The same app in TypeScript + Express.Project layout — four files in a single directory:
package.json (create new)
package.json
tsconfig.json (create new)
tsconfig.json
.env (create new — add to .gitignore)
.env
src/promptwall.ts (create new — same as Step 3)
src/promptwall.ts
src/server.ts (create new — the runnable server)
src/server.ts
Failure modes
Your code path must handle PromptWall being unreachable. Possible failures:
The SDK retries idempotent failures (5xx + network) once with 100 ms
backoff before raising. cURL/raw HTTP integrations should implement the
same.
What you’ll see in the dashboard
Within seconds of your first verify call:- /observability — KPIs (requests, blocks, rewrites, tokens, cost), decisions chart, breakdown table by policy
- /traces — drill-down on each verify call, including the policy
reasons array and the
rewrittentext if applicable - /sessions — multi-turn replay (if
session_idis set) - /billing — credit consumed at $90/M tokens for verify
/v1/events and /v1/chat traffic.
Next steps
Tune your policies
Decide what counts as PII / brand-safety / off-topic for your tenant.
Set actions per severity (allow / warn / block / rewrite).
Upgrade to Full Control
Collapse the two-call flow (LLM + Verify) into a single
POST /v1/chat. Adds pre-flight prompt scanning. $180/M tokens.