@juspay/neurolink 13.8.24 → 13.8.25

package/docs-site/static/search-index.json

@@ -7701,8 +7701,9 @@
 {"objectID":"19b651b464a6f5ce48fd3705b461d846781afb42f1bd63f1b862d0af5a7b8ed4","title":"Route Groups","url":"/docs/guides/server-adapters/api-reference#route-groups","content":"Route group factories return RouteGroup objects. Register them with adapter.registerRouteGroup(group).","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"Route Groups","lvl3":""}},
 {"objectID":"69d3af0a2481958a11346eed327bc59d63ae750a56f75683e1d6661de27e4e73","title":"createAllRoutes(basePath?, options?)","url":"/docs/guides/server-adapters/api-reference#createallroutesbasepath-options","content":"Creates all standard route groups in one call.","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"createAllRoutes(basePath?, options?)","lvl3":""}},
 {"objectID":"8af1d4e6d75ca68b8c9248b8411634663fc0eee1d650235a1e5e06122fe6c439","title":"registerAllRoutes(adapter, basePath?, options?)","url":"/docs/guides/server-adapters/api-reference#registerallroutesadapter-basepath-options","content":"Registers all route groups with an adapter. If the adapter has listRoutes(), auto-binds it for OpenAPI spec generation.","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"registerAllRoutes(adapter, basePath?, options?)","lvl3":""}},
-{"objectID":"2a0e62a8cfac86c4b2081bf7c659fb39367ec848852b3700075feaddd6e08979","title":"Individual Route Factories","url":"/docs/guides/server-adapters/api-reference#individual-route-factories","content":"| Factory                                      | Prefix    | Endpoints                                                                                                                                                                                                                                                                                   |\n| -------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| createAgentRoutes(basePath?, options?)     | /agent  | POST /agent/execute -- Execute agentPOST /agent/stream -- Stream agent response (SSE)GET /agent/providers -- List available providersPOST /agent/embed -- Generate single embeddingPOST /agent/embed-many -- Generate batch embeddings                    |\n| createToolRoutes(basePath?)                | /tools  | GET /tools -- List all toolsGET /tools/search -- Search tools by queryGET /tools/:name -- Get tool detailsPOST /tools/:name/execute -- Execute toolPOST /tools/execute -- Execute tool (body-based)                                                       |\n| createMCPRoutes(basePath?)                 | /mcp    | GET /mcp/servers -- List MCP serversGET /mcp/servers/:name -- Get server statusGET /mcp/servers/:name/tools -- List server toolsPOST /mcp/servers/:name/tools/:toolName/execute -- Execute server tool                                                            |\n| createMemoryRoutes(basePath?)              | /memory | GET /memory/sessions -- List sessionsGET /memory/sessions/:id -- Get session detailsGET /memory/sessions/:id/messages -- Get session messagesDELETE /memory/sessions/:id -- Delete sessionPOST /memory/sessions/:sessionId/clear -- Clear session history |\n| createHealthRoutes(basePath?)","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"Individual Route Factories","lvl3":""}},
+{"objectID":"2a0e62a8cfac86c4b2081bf7c659fb39367ec848852b3700075feaddd6e08979","title":"Individual Route Factories","url":"/docs/guides/server-adapters/api-reference#individual-route-factories","content":"| Factory                                      | Prefix    | Endpoints                                                                                                                                                                                                                                                                                                                                                                                 |\n| -------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| createAgentRoutes(basePath?, options?)     | /agent  | POST /agent/execute -- Execute agentPOST /agent/stream -- Stream agent response (SSE)GET /agent/providers -- List available providersPOST /agent/embed -- Generate single embeddingPOST /agent/embed-many -- Generate batch embeddings                                                                                                                  |\n| createToolRoutes(basePath?)                | /tools  | GET /tools -- List all toolsGET /tools/search -- Search tools by queryGET /tools/:name -- Get tool detailsPOST /tools/:name/execute -- Execute toolPOST /tools/execute -- Execute tool (body-based)                                                                                                                                                     |\n| createMCPRoutes(basePath?)","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"Individual Route Factories","lvl3":""}},
 {"objectID":"69bea07b5c4ac414ed9a20d0f483fd96a7b592072d73e2fa263997e5c1aa34eb","title":"Attachments on /agent/execute and /agent/stream","url":"/docs/guides/server-adapters/api-reference#attachments-on-agentexecute-and-agentstream","content":"input.images and input.files are strings that name content. The SDK resolves\nthem itself, which is right for a program naming its own files and wrong for a\nnetwork server, so the agent routes check each one before the SDK sees it. An\nhttps:// URL or an allowed local path is read by the route and handed to the\nSDK as bytes; a data: URI already carries its content and passes through\nunchanged; anything else is refused:\n\n| Entry                          | Result                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |\n| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| data: URI                    | Passed through unchanged. Its length counts against the size limits below, and over a limit it is 413.","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"Attachments on /agent/execute and /agent/stream","lvl3":""}},
+{"objectID":"003df570caeb040e08381d4650241dff3930ff2ea13de5cedbb7e9085c624b5e","title":"Memory routes and per-user authentication","url":"/docs/guides/server-adapters/api-reference#memory-routes-and-per-user-authentication","content":"The memory routes ignore who is calling unless the server opts in with perUserAuth (any truthy value). The opt-in is the same switch the agent routes use (see the security guide); it is off by default because one shared API key (such as neurolink serve with NEUROLINK_SERVER_API_KEY) sets the same ctx.user for every caller and names no person to scope by. A server with per-person authentication must set it: without it the routes do not read ctx.user, so any authenticated caller can name another person with ?userId= on Redis, read any in-memory session by id, and clear every session.\n\nDefault (perUserAuth unset): no authentication, or one shared API key. The routes do not read ctx.user. ?userId= chooses the user on Redis (default \"default\"), the in-memory manager keys sessions by id alone, and GET /memory/stats and DELETE /memory/sessions are open to every caller that passes your authentication, exactly as before scoping existed. A session's owner is not checked.\n\nperUserAuth: true: one credential per person.","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"Memory routes and per-user authentication","lvl3":""}},
 {"objectID":"d89461a69441807c337b069b75bd37d86c2d3e0565e57b529eadb04a07da8784","title":"Proxy Route Factories","url":"/docs/guides/server-adapters/api-reference#proxy-route-factories","content":"These are only included by createAllRoutes when a proxy flag is set, and they\ntake their own dependencies rather than just a basePath.\n\n| Factory                                                                                                   | Included when            | Endpoints                                                                                                                                                                                                                                                   |\n| --------------------------------------------------------------------------------------------------------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| createClaudeProxyRoutes(modelRouter?, basePath?, strategy?, passthrough?, primaryAccountKey?, options?) | proxy or claudeProxy | POST /v1/messages — Anthropic Messages passthrough with account poolingGET /limits — per-account quota (?snapshot=true for stored state)GET /accounts — one row per account joining status, quota and per-account token totals and cost |\n| createOpenAIProxyRoutes(modelRouter?, basePath?, loopbackPort?, runtimeConfigProvider?)                 | proxy or openaiProxy | POST /v1/chat/completions — OpenAI-compatible surface; Anthropic-targeted models loop back through /v1/messages                                                                                                                                         |\n| createCodexProxyRoutes(basePath?)","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"Proxy Route Factories","lvl3":""}},
 {"objectID":"7e72ba983f827d21de4123a24256ed23c608281e7c46bfc918a5196071715853","title":"OpenAPIGenerator","url":"/docs/guides/server-adapters/api-reference#openapigenerator","content":"Class that generates OpenAPI 3.1 specifications from route definitions.","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"OpenAPIGenerator","lvl3":""}},
 {"objectID":"b404b041f78f01f9182bc1a5f9e980c7019c0c085cd3d80f40d024fdb6cd0c0a","title":"OpenAPIGeneratorConfig","url":"/docs/guides/server-adapters/api-reference#openapigeneratorconfig","content":"OpenAPIGeneratorConfig","hierarchy":{"lvl0":"Guides","lvl1":"Server Adapters API Reference","lvl2":"OpenAPIGeneratorConfig","lvl3":""}},
@@ -8029,7 +8030,7 @@
 {"objectID":"75f9986be54ffb5b39930d9b1514e6a696e982fe41bbc2a600033e3254bad57b","title":"When to Use","url":"/docs/guides/server-adapters/middleware#when-to-use-12","content":"Expensive operations (database queries, AI generation)\nFrequently requested static data\nRate limit budget optimization\nReducing latency for repeated requests","hierarchy":{"lvl0":"Guides","lvl1":"Middleware Reference","lvl2":"When to Use","lvl3":""}},
 {"objectID":"3e522465420d38d5c0e20166dfc374452a7c8366d592ff2cf3a9cb9afadc3b7d","title":"Composing Middleware","url":"/docs/guides/server-adapters/middleware#composing-middleware","content":"Middleware are executed in order based on their order property. Here's a recommended production setup:","hierarchy":{"lvl0":"Guides","lvl1":"Middleware Reference","lvl2":"Composing Middleware","lvl3":""}},
 {"objectID":"293ec2d6d2933e2f370ee73b87ee9684f64143acd21d8bbb5e7e48640ec0d2bb","title":"Next Steps","url":"/docs/guides/server-adapters/middleware#next-steps","content":"Configuration Reference - Full server configuration options\nSecurity Best Practices - Authentication and authorization patterns\nDeployment Guide - Production deployment strategies\nExpress Adapter - Express-specific middleware integration\nFastify Adapter - Fastify-specific hooks and plugins","hierarchy":{"lvl0":"Guides","lvl1":"Middleware Reference","lvl2":"Next Steps","lvl3":""}},
-{"objectID":"3f8ed2c1cc0b9c59fe231fb08fe10302270284784b912664350299fe0a5de458","title":"Security Best Practices","url":"/docs/guides/server-adapters/security","content":"Security Best Practices\n\nProtect your AI APIs with comprehensive security measures\n\nThis guide covers authentication, authorization, rate limiting, and other security best practices for deploying NeuroLink server adapters in production.\n\nAuthentication\n\nNeuroLink server adapters support multiple authentication strategies out of the box.\n\nBearer Token Authentication\n\nBearer tokens (JWT, OAuth tokens) are the most common authentication method for APIs:\n\nAPI Key Authentication\n\nFor service-to-service communication or simple API access:\n\nBasic Authentication\n\nFor simple username/password authentication:\n\nCustom Authentication\n\nFor OAuth 2.0, OIDC, or custom schemes:\n\nCarrying middleware state to guards and handlers (carryMiddlewareState)\n\nAuthentication middleware sets ctx.user. On the built-in adapters, whether the\nmiddleware that runs after it, and the route handler, see it depends on the\nadapter and on carryMiddlewareState, which is off by default: each adapter\nthen propagates context as it always did. Express, Fastify and Koa build a fresh\ncontext for every middleware step and for the handler and carry only the\nresponse headers; Hono shares one context between the steps and the handler only\nwhen the client sent its own X-Request-ID.\n\nThe option does not apply to a context you build yourself: a custom adapter, or a\nroute handler you call directly, can supply a context that already has ctx.user\nset.\n\nSo by default a role guard (createRoleMiddleware) registered after\ncreateAuthMiddleware sees the user on one request shape only. Measured: it\nanswers 401 to every request on Express, Fastify and Koa, and on Hono without a\nclient X-Request-ID, even for a user holding the required role, and a\nrate-limit keyGenerator reads ctx.user as undefined there. Set the option on\nthe server to carry ctx.user, ctx.session, ctx.metadata and the abort\nsignal to later middleware and the handler on every built-in adapter:\n\nWith it on, the role guard admits a user holding the role (200) and refuses one\nwithout it (403), and a keyGenerator sees ctx.user, on every built-in adapter. A key\ngenerator that keys on the user id then does what it says, so make it ignore a\nshared identity (ctx.user.shared), or every holder of one API key falls into a\nsingle bucket; the rate-limit examples below do. Turning the option on does not\nchange whose identity the agent routes trust, and registerAllRoutes turns it\non by itself when given perUserAuth, as the next section says.\n\nWho the agent routes treat as the user (perUserAuth)\n\nWhether the agent routes (/agent/execute, /agent/stream, and the skill\nmutation routes' requestedBy) trust ctx.user as a person is a separate\nchoice from whether the server carries it: a single shared API key sets the same\nctx.user for every caller, and taking it as the user would give every client\none userId and no conversation memory.\n\nSo without an opt-in the agent routes resolve identity as they always have:\nOn Express, Fastify and Koa, and on Hono when the client sent no\n  X-Request-ID, userId and sessionId come from the request body.\n  ctx.user and ctx.session are ignored (they are not in the handler's\n  context at all unless the server carries middleware state), and the skill\n  routes use the body's requestedBy.\nOn Hono, when the client sent its own X-Request-ID header, an authenticated\n  ctx.user wins over the body (and ctx.session over the body's\n  sessionId), as it did before. Hono kept the middleware's context under that\n  header, so the handler found it. That is the only built-in combination where\n  the default ever guarded userId.\nA context the built-in adapters did not hand the carry to keeps the same\n  rule, an authenticated ctx.user wins: an adapter you wrote that sets\n  ctx.user itself, or a route handler you call directly with a context you\n  built (a test harness, for one).\n\nSet perUserAuth: true when your middleware identifies individual people (one\ncredential per person). Only this option, with carryMiddlewareState on, makes the agent routes take\nthe user from ctx.user, and ignore the body's userId, on every built-in\nadapter and for every request:\n\nregisterAllRoutes also turns on carryMiddlewareState for the server, because\nthe routes can only take identity from ctx.user if the adapter hands it to the\nhandler. With carryMiddlewareState on, a perUserAuth request that your middleware\nauthenticated reaches the handler with that user on every built-in adapter. A\nrequest that no middleware authenticated (optional authentication) runs as\nanonymous, with no userId and no session.\n\nIf you register the agent routes yourself with\ncreateAgentRoutes(\"/api\", { perUserAuth: true }), create the server with\ncarryMiddlewareState: true. Without it, whether a perUserAuth request has a\nuser depends on the adapter and the request:\nHono, when the client sent its own X-Request-ID header: an authenticated\n  request has its user and session. Hono hands the handler the middleware's context for such\n  a request whether or not carryM","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"","lvl3":""}},
+{"objectID":"3f8ed2c1cc0b9c59fe231fb08fe10302270284784b912664350299fe0a5de458","title":"Security Best Practices","url":"/docs/guides/server-adapters/security","content":"Security Best Practices\n\nProtect your AI APIs with comprehensive security measures\n\nThis guide covers authentication, authorization, rate limiting, and other security best practices for deploying NeuroLink server adapters in production.\n\nAuthentication\n\nNeuroLink server adapters support multiple authentication strategies out of the box.\n\nBearer Token Authentication\n\nBearer tokens (JWT, OAuth tokens) are the most common authentication method for APIs:\n\nAPI Key Authentication\n\nFor service-to-service communication or simple API access:\n\nBasic Authentication\n\nFor simple username/password authentication:\n\nCustom Authentication\n\nFor OAuth 2.0, OIDC, or custom schemes:\n\nCarrying middleware state to guards and handlers (carryMiddlewareState)\n\nAuthentication middleware sets ctx.user. On the built-in adapters, whether the\nmiddleware that runs after it, and the route handler, see it depends on the\nadapter and on carryMiddlewareState, which is off by default: each adapter\nthen propagates context as it always did. Express, Fastify and Koa build a fresh\ncontext for every middleware step and for the handler and carry only the\nresponse headers; Hono shares one context between the steps and the handler only\nwhen the client sent its own X-Request-ID.\n\nThe option does not apply to a context you build yourself: a custom adapter, or a\nroute handler you call directly, can supply a context that already has ctx.user\nset.\n\nSo by default a role guard (createRoleMiddleware) registered after\ncreateAuthMiddleware sees the user on one request shape only. Measured: it\nanswers 401 to every request on Express, Fastify and Koa, and on Hono without a\nclient X-Request-ID, even for a user holding the required role, and a\nrate-limit keyGenerator reads ctx.user as undefined there. Set the option on\nthe server to carry ctx.user, ctx.session, ctx.metadata and the abort\nsignal to later middleware and the handler on every built-in adapter:\n\nWith it on, the role guard admits a user holding the role (200) and refuses one\nwithout it (403), and a keyGenerator sees ctx.user, on every built-in adapter. A key\ngenerator that keys on the user id then does what it says, so make it ignore a\nshared identity (ctx.user.shared), or every holder of one API key falls into a\nsingle bucket; the rate-limit examples below do. Turning the option on does not\nchange whose identity the agent routes trust, and registerAllRoutes turns it\non by itself when given perUserAuth, as the next section says.\n\nWho the agent routes treat as the user (perUserAuth)\n\nWhether the agent routes (/agent/execute, /agent/stream, and the skill\nmutation routes' requestedBy) and the memory routes (/memory/*) trust\nctx.user as a person is a separate choice from whether the server carries it:\na single shared API key sets the same ctx.user for every caller, and taking it\nas the user would give every client one userId and no conversation memory\n(agent routes), or make every client a non-admin of its own deployment (memory\nroutes).\n\nSo without an opt-in the agent routes resolve identity as they always have:\nOn Express, Fastify and Koa, and on Hono when the client sent no\n  X-Request-ID, userId and sessionId come from the request body.\n  ctx.user and ctx.session are ignored (they are not in the handler's\n  context at all unless the server carries middleware state), and the skill\n  routes use the body's requestedBy.\nOn Hono, when the client sent its own X-Request-ID header, an authenticated\n  ctx.user wins over the body (and ctx.session over the body's\n  sessionId), as it did before. Hono kept the middleware's context under that\n  header, so the handler found it. That is the only built-in combination where\n  the default ever guarded userId.\nA context the built-in adapters did not hand the carry to keeps the same\n  rule, an authenticated ctx.user wins: an adapter you wrote that sets\n  ctx.user itself, or a route handler you call directly with a context you\n  built (a test harness, for one).\n\nThe memory routes have none of these exceptions: without the opt-in they ignore\nctx.user on every adapter and for every request.\n\nSet perUserAuth: true when your middleware identifies individual people (one\ncredential per person). Only this option, with carryMiddlewareState on, makes the agent routes take\nthe user from ctx.user, and ignore the body's userId, on every built-in\nadapter and for every request:\n\nregisterAllRoutes also turns on carryMiddlewareState for the server, because\nthe routes can only take identity from ctx.user if the adapter hands it to the\nhandler. With carryMiddlewareState on, a perUserAuth request that your middleware\nauthenticated reaches the handler with that user on every built-in adapter. A\nrequest that no middleware authenticated (optional authentication) runs as\nanonymous, with no userId and no session.\n\nIf you register the agent routes yourself with\ncreateAgentRoutes(\"/api\", { perUserAuth: true }), create the server with\ncarryMiddlewareState: true. Without it, whether a perUserAuth request","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"","lvl3":""}},
 {"objectID":"7cdb3cd74c088f4b197de4db297c2eb3b47c353b41ce1a84ed2e12548147b408","title":"Security Best Practices","url":"/docs/guides/server-adapters/security#security-best-practices","content":"Protect your AI APIs with comprehensive security measures\n\nThis guide covers authentication, authorization, rate limiting, and other security best practices for deploying NeuroLink server adapters in production.","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Security Best Practices","lvl3":""}},
 {"objectID":"7165b0d19a27c31d8ca81ea15e5a79ad56fd20234c80f3c955a1c579a669e84f","title":"Authentication","url":"/docs/guides/server-adapters/security#authentication","content":"NeuroLink server adapters support multiple authentication strategies out of the box.","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Authentication","lvl3":""}},
 {"objectID":"9b83e309c15f0ef505257e6ef1750da7d26183f6b598bcd24996ad199df910cc","title":"Bearer Token Authentication","url":"/docs/guides/server-adapters/security#bearer-token-authentication","content":"Bearer tokens (JWT, OAuth tokens) are the most common authentication method for APIs:","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Bearer Token Authentication","lvl3":""}},
@@ -8037,7 +8038,7 @@
 {"objectID":"55486c9aed152083800f7142accdefaf2750be560161e53b51e4e7f076e78783","title":"Basic Authentication","url":"/docs/guides/server-adapters/security#basic-authentication","content":"For simple username/password authentication:","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Basic Authentication","lvl3":""}},
 {"objectID":"3975b5affef7749530f0c88db91dccfe9ae500ea616d9ae756de09c501e74e09","title":"Custom Authentication","url":"/docs/guides/server-adapters/security#custom-authentication","content":"For OAuth 2.0, OIDC, or custom schemes:","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Custom Authentication","lvl3":""}},
 {"objectID":"6c5ba88d8c7484db5bcd476fabfca5763fad609f689edee826a37f9360219610","title":"Carrying middleware state to guards and handlers (carryMiddlewareState)","url":"/docs/guides/server-adapters/security#carrying-middleware-state-to-guards-and-handlers-carrymiddlewarestate","content":"Authentication middleware sets ctx.user. On the built-in adapters, whether the\nmiddleware that runs after it, and the route handler, see it depends on the\nadapter and on carryMiddlewareState, which is off by default: each adapter\nthen propagates context as it always did. Express, Fastify and Koa build a fresh\ncontext for every middleware step and for the handler and carry only the\nresponse headers; Hono shares one context between the steps and the handler only\nwhen the client sent its own X-Request-ID.\n\nThe option does not apply to a context you build yourself: a custom adapter, or a\nroute handler you call directly, can supply a context that already has ctx.user\nset.\n\nSo by default a role guard (createRoleMiddleware) registered after\ncreateAuthMiddleware sees the user on one request shape only. Measured: it\nanswers 401 to every request on Express, Fastify and Koa, and on Hono without a\nclient X-Request-ID, even for a user holding the required role, and a\nrate-limit keyGenerator reads ctx.user as undefined there. Set the option on\nthe server to carry ctx.user, ctx.session, ctx.metadata and the abort\nsignal to later middleware and the handler on every built-in adapter:\n\nWith it on, the role guard admits a user holding the role (200) and refuses one\nwithout it (403), and a keyGenerator sees ctx.user, on every built-in adapter. A key\ngenerator that keys on the user id then does what it says, so make it ignore a\nshared identity (ctx.user.shared), or every holder of one API key falls into a\nsingle bucket; the rate-limit examples below do. Turning the option on does not\nchange whose identity the agent routes trust, and registerAllRoutes turns it\non by itself when given perUserAuth, as the next section says.","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Carrying middleware state to guards and handlers (carryMiddlewareState)","lvl3":""}},
-{"objectID":"f4407e53fe643ff19343687ebdafae3eaf56adc6a7cafc61834a490cc90bffd1","title":"Who the agent routes treat as the user (perUserAuth)","url":"/docs/guides/server-adapters/security#who-the-agent-routes-treat-as-the-user-peruserauth","content":"Whether the agent routes (/agent/execute, /agent/stream, and the skill\nmutation routes' requestedBy) trust ctx.user as a person is a separate\nchoice from whether the server carries it: a single shared API key sets the same\nctx.user for every caller, and taking it as the user would give every client\none userId and no conversation memory.\n\nSo without an opt-in the agent routes resolve identity as they always have:\nOn Express, Fastify and Koa, and on Hono when the client sent no\n  X-Request-ID, userId and sessionId come from the request body.\n  ctx.user and ctx.session are ignored (they are not in the handler's\n  context at all unless the server carries middleware state), and the skill\n  routes use the body's requestedBy.\nOn Hono, when the client sent its own X-Request-ID header, an authenticated\n  ctx.user wins over the body (and ctx.session over the body's\n  sessionId), as it did before. Hono kept the middleware's context under that\n  header, so the handler found it. That is the only built-in combination where\n  the default ever guarded userId.\nA context the built-in adapters did not hand the carry to keeps the same\n  rule, an authenticated ctx.user wins: an adapter you wrote that sets\n  ctx.user itself, or a route handler you call directly with a context you\n  built (a test harness, for one).\n\nSet perUserAuth: true when your middleware identifies individual people (one\ncredential per person). Only this option, with carryMiddlewareState on, makes the agent routes take\nthe user from ctx.user, and ignore the body's userId, on every built-in\nadapter and for every request:\n\nregisterAllRoutes also turns on carryMiddlewareState for the server, because\nthe routes can only take identity from ctx.user if the adapter hands it to the\nhandler. With carryMiddlewareState on, a perUserAuth request that your middleware\nauthenticated reaches the handler with that user on every built-in adapter.","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Who the agent routes treat as the user (perUserAuth)","lvl3":""}},
+{"objectID":"f4407e53fe643ff19343687ebdafae3eaf56adc6a7cafc61834a490cc90bffd1","title":"Who the agent routes treat as the user (perUserAuth)","url":"/docs/guides/server-adapters/security#who-the-agent-routes-treat-as-the-user-peruserauth","content":"Whether the agent routes (/agent/execute, /agent/stream, and the skill\nmutation routes' requestedBy) and the memory routes (/memory/*) trust\nctx.user as a person is a separate choice from whether the server carries it:\na single shared API key sets the same ctx.user for every caller, and taking it\nas the user would give every client one userId and no conversation memory\n(agent routes), or make every client a non-admin of its own deployment (memory\nroutes).\n\nSo without an opt-in the agent routes resolve identity as they always have:\nOn Express, Fastify and Koa, and on Hono when the client sent no\n  X-Request-ID, userId and sessionId come from the request body.\n  ctx.user and ctx.session are ignored (they are not in the handler's\n  context at all unless the server carries middleware state), and the skill\n  routes use the body's requestedBy.\nOn Hono, when the client sent its own X-Request-ID header, an authenticated\n  ctx.user wins over the body (and ctx.session over the body's\n  sessionId), as it did before. Hono kept the middleware's context under that\n  header, so the handler found it. That is the only built-in combination where\n  the default ever guarded userId.\nA context the built-in adapters did not hand the carry to keeps the same\n  rule, an authenticated ctx.user wins: an adapter you wrote that sets\n  ctx.user itself, or a route handler you call directly with a context you\n  built (a test harness, for one).\n\nThe memory routes have none of these exceptions: without the opt-in they ignore\nctx.user on every adapter and for every request.\n\nSet perUserAuth: true when your middleware identifies individual people (one\ncredential per person).","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Who the agent routes treat as the user (perUserAuth)","lvl3":""}},
 {"objectID":"0eb6912fafa8a4ab0aa683215da36521df010f267a7e6fa07e5b36117285fbd7","title":"Skip Paths Configuration","url":"/docs/guides/server-adapters/security#skip-paths-configuration","content":"Certain endpoints should bypass authentication:","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Skip Paths Configuration","lvl3":""}},
 {"objectID":"9e51a77be4d03e43ee3f36b8d0011c07bc65e43fe63401529fc309117cc8f14d","title":"Rate Limiting","url":"/docs/guides/server-adapters/security#rate-limiting","content":"Protect your API from abuse with configurable rate limiting.","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Rate Limiting","lvl3":""}},
 {"objectID":"c6e767ba1ce5b5628ab9d303d199a6fb4947a70e2e43358a5d7f89a96534c74e","title":"Basic Configuration","url":"/docs/guides/server-adapters/security#basic-configuration","content":"Basic Configuration","hierarchy":{"lvl0":"Guides","lvl1":"Security Best Practices","lvl2":"Basic Configuration","lvl3":""}},

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@juspay/neurolink",
-  "version": "13.8.24",
+  "version": "13.8.25",
   "packageManager": "pnpm@10.34.7+sha512.upirxYVTmTM3W1lx9LxtbHOhtLftxKh559EC/lQj0eAjCdZ8YKEfBJVQk6luUhrZw7E4zdZUylvlY/N4s65IvQ==",
   "description": "The pipe layer of an AI nervous system: one interface connecting provider neurons to your application, across three inference types — generate, stream and decide. `decide` returns typed, calibrated judgements from a non-generative model (~400ms, ~$0.00002/call) for routing, tool selection and context budgeting. MCP-native (4 transports), voice TTS/STT/realtime, RAG, agents, memory, compaction, 9 observability exporters. OpenAI · Anthropic · Gemini · Bedrock · Azure · Ollama · TypeSafe Jev and more.",
   "author": {
@@ -216,6 +216,7 @@
     "test:agent-input-guard": "pnpm exec tsx test/continuous-test-suite-agent-input-guard.ts",
     "test:body-limits": "pnpm exec tsx test/continuous-test-suite-body-limits.ts",
     "test:adapter-request-context": "pnpm exec tsx test/continuous-test-suite-adapter-request-context.ts",
+    "test:memory-route-scope": "pnpm exec tsx test/continuous-test-suite-memory-route-scope.ts",
     "test:websocket-agent-handler": "pnpm exec tsx test/continuous-test-suite-websocket-agent-handler.ts",
     "test:tool-reliability": "pnpm exec tsx test/continuous-test-suite-tool-reliability.ts",
     "test:video-abort": "pnpm exec tsx test/continuous-test-suite-video-abort.ts",