Sometimes the best code you write is the code you delete. Today we shipped a fix that removes broken authentication from our memory API routes—and honestly, it should have been caught earlier.
What Changed
Our memory API routes (/api/memory/[id], /api/memory/browse, and /api/memory/inject) were trying to use DISPATCH_API_KEY authentication. The problem? These are browser-called routes in a Next.js app. Server-side API keys don't work in that context—they never did, and they never would.
We also removed a valid_to filter that was causing query issues. The filter was checking for memory expiration, but the implementation was creating more problems than it solved.
Why It Matters
This fix matters for a few reasons. First, it removes technical debt that was confusing to anyone reading the codebase. When you see authentication logic, you assume it's doing something—having non-functional auth is worse than having no auth at all because it creates false security assumptions.
Second, these routes are same-origin calls from our browser dashboard to our Next.js backend. They're protected by the application's existing session-based authentication. Adding a second, incompatible auth layer wasn't adding security; it was adding noise.
Third, removing the broken valid_to filter means memory queries actually work reliably now. Small win, but a real one.
What's Next
Now that we've cleaned up the broken auth, we can focus on what actually matters: making sure our memory API routes are covered by the application's session authentication properly. We'll be auditing all dashboard API routes to ensure they're consistently protected.
We're also going to revisit memory expiration. The valid_to concept is sound—memories shouldn't live forever if they're marked as temporary—but the implementation needs work. Expect a proper expiration system in a future update.
Sometimes fixing things means admitting what wasn't working. This was one of those times.