Memory for ecommerce

You are building a support assistant that answers each shopper from that shopper's own history. One shopper is one user, so orders, returns, preferences and support threads stay in that shopper's memory and out of anyone else's.

• Facts change. A shopper's address, size, plan or subscription can change, and the assistant must answer from the newest value. Harny marks the newer value as current and keeps the earlier one answerable by date.
• Histories must stay separate. One shopper's data should never reach another shopper's answers. Harny keeps each person's memory separate.
• Deletion must be possible. When a shopper asks for their data to be removed, your app needs a clear route. Harny offers one per user.

• A Memory API where your server sends orders, returns, preferences and support notes for each shopper.
• Recall that can answer as of a date, so an old address or size can still be looked up by when it applied.
• Per-user separation, with each request checked against your app key.
• A per-user erase route, DELETE /v1/users/{user_id}/data, for shopper deletion requests.

• Answer from that shopper's history when they ask about an order you have sent to their memory.
• Remember a shopper's size and preferences, so your app can use what they told you before.
• Hand off a refund decision or a damaged-item judgment to a person as a manual action.

1. Create an app key and keep it on your server, never in a browser.
2. Send each shopper's order, return and preference events with POST /v1/memory/ingest, using that shopper's id in X-Harny-User.
3. Ask for context before each support answer with POST /v1/memory/recall, passing the shopper's identity.
4. Route shopper deletion requests to DELETE /v1/users/{user_id}/data.