Resources

Testing & sandbox.

You can exercise the entire API before writing a line of integration code: paste a connection token into the dev-portal Sandbox and call any endpoint. Then wire the same calls into automated tests with the SDK pointed at your local stack.

The dev-portal Sandbox

In the dev portal, the Sandbox lets you paste a connection token and fire requests against a live store. Useful endpoints to try:

Try	What it shows
GET `/v1/catalog`	Standard scopes / kinds / intents (public)
GET `/v1/scopes`	What this user actually granted, with counts
GET `/v1/identity/brief`	The synthesized memory portrait
GET `/v1/context`	A scored, filtered context bundle for an intent
GET `/v1/memories?query=...`	Recall: hybrid search over readable memories
POST `/v1/memories`	Remember a memory and inspect what persisted
POST `/v1/signals`	Emit a signal; it fans out to subscribers (not stored)
POST `/v1/gateway/chat`	A hosted chat turn end-to-end

Getting a test connection token

Two ways to obtain a token to paste or use in tests:

Run the real OAuth flow once. Connect a test user through the hub, then copy the resulting token from your app's storage. This mirrors production exactly.
Exchange directly. POST /v1/oauth/token with a code, your client id, and secret — the same call exchangeCodeForToken() makes.

bash

curl -X POST http://localhost:4000/v1/oauth/token \
  -H "Content-Type: application/json" \
  -d '{ "code": "<auth_code>", "client_id": "<id>", "client_secret": "<secret>" }'
# → { "connection_token": "...", "ai_id": "...", "scopes": [...] }

Auth codes are short-lived

An authorization code expires in 10 minutes and is single-use. Generate it fresh right before exchanging. See Connect an app.

Local base URLs & env vars

Service	Local URL	Env var
API	`http://localhost:4000`	`PAMBASE_API_URL` / `NEXT_PUBLIC_API_BASE_URL`
Hub	`http://localhost:3000`	`PAMBASE_HUB_URL`
Docs	`http://localhost:3004`	—

App credentials and the webhook secret:

Var	Use
`PAMBASE_CLIENT_ID`	Your app's OAuth client id
`PAMBASE_CLIENT_SECRET`	Used server-side for the token exchange
`PAMBASE_WEBHOOK_SECRET`	Signing secret for inbound webhook verification

Production base URLs (aspirational) are https://api.pambase.io and https://pambase.io.

Mock connectors

To populate a test store with realistic data without real integrations, the dev stack ships mock connectors — mock-strava and mock-apple-health. Push synthetic provider data through them via POST /v1/webhooks/:provider, then read it back with recall().

bash

# Seed a test store with a mock workout, then read it back
curl -X POST http://localhost:4000/v1/webhooks/mock-strava \
  -H "Content-Type: application/json" \
  -d '{ "activity": "run", "distanceKm": 8, "durationMin": 44 }'

Integration test tips

Point the SDK at http://localhost:4000 and use a dedicated test user's token from a fixture/secret, not a real account.
Make remember() writes idempotent in assertions — assert on the returned memoryIds.
A write to an unknown top-level scope is rejected (400) — assert that path, and that general always works.
For webhook tests, sign a sample raw body with your secret and post it to your handler to verify your verification path.
Don't assert exact LLM text — assert structure (a reply exists, a memory landed, usage is returned).
Embeddings/LLM may be offline in dev: remember()/recall()/signals still work; semantic ranking degrades. Test both states.

LLM-free paths are testable offline

Writing memory (remember) and emitting signals need no model — ideal for deterministic CI. Reading usefully is where you bring an LLM.