Reply-to-edit
When a receipt lands in needs_review (or needs_confirmation for a duplicate), Splitjar emails you. That email is reply-able. Your reply is the edit.
The shape
Reply with whatever feels natural:
- “split 3 ways between me, Rod and Steve”
- “vendor is actually Soko Coffee”
- “amount was 42.50 GEL”
- “category is groceries”
- “this is fine, approve it”
A small model reads the receipt’s current state plus your reply and produces a tight JSON patch. Allowed fields:
vendor,category,country_codeamount,currency,purchased_at,notessplit_policyand member assignments
Anything else is ignored.
How the link back works
Cloudflare Email Routing doesn’t support RFC 5233 sub-addressing, so we can’t put the receipt id in the local part of the reply address. Instead, the body of every review email carries a marker:
Ref: SJ-<receiptId>-<HMAC token>Most clients quote the body on reply, so the marker comes back to us. The HMAC token is verified server-side before any edit is applied — a forwarded copy of the email can’t be replayed by an attacker who doesn’t hold the secret.
Who can reply
The reply must come from a verified alias of a member of the jar. Two checks:
- The
From:address is mapped to ausers.idvia theuser_emailstable, AND that mapping hasverified_at IS NOT NULL. - That user is a member of the receipt’s jar.
A placeholder invitee whose email was added during invite does have a user_emails row, but that row’s verified_at is NULL until they sign in. They can’t edit by reply alone.
What you get back
If the patch parses cleanly and applies, you get a confirmation email with a one-line summary of what changed. If the model couldn’t make sense of the reply, you get a “couldn’t parse” email asking for a sharper version. The receipt stays in needs_review either way until the change actually lands.
Why this exists
The product is built for the on-holiday-half-drunk use case. Opening an app to fix a vendor name on a single receipt is friction. Replying to an email isn’t.