Webhooks

Webhooks let FishMem push notifications about memory API activity to your systems, so you don't have to poll the API to find out when something happened. You configure them per project in the dashboard.

What they're for

A webhook is an HTTP endpoint you own that FishMem calls when relevant memory activity occurs in your project. Instead of asking "did anything change?" on a schedule, your system gets told. That makes them a good fit for keeping other systems in step with what FishMem is storing.

Typical uses:

• Sync memory activity into your own database, search index, or analytics.
• Trigger downstream work when memory changes — refresh a cache, kick off a job, notify another service.
• Audit and observe what your integration is doing to memory over time.

Configuring

Webhooks are set up per project in the dashboard. You point FishMem at an endpoint URL you control, and it sends notifications there as activity happens. Because configuration is per project, different projects can deliver to different endpoints.

Building a good receiver

Whatever the exact payloads look like, a few practices keep a webhook receiver healthy regardless of provider:

• Respond fast. Acknowledge the request quickly and do heavy work asynchronously, so a slow handler doesn't cause retries.
• Be idempotent. Network delivery can repeat, so make sure handling the same notification twice is safe.
• Use a stable, reachable URL. The endpoint has to be publicly reachable for FishMem to deliver to it.

Use webhooks as a complement to the API, not a replacement: they tell you something happened, and you read back through the API or the dashboard when you need the full picture.