The first integration, worked here first so what goes to bazaar's crew is a change they can apply, not an idea they have to design.
Done looks like
[ ] docs/integrations/bazaar.md fixes the contract: kinds order.placed, order.paid, order.shipped; subject is the order number; summary is one line a stranger understands ("3 items, $48.20, to Portland"); link is the order page on bazaar; dedupe is the order id and the state, so a retry or a re-delivery is free; occurred_at is when the order changed, not when the event was sent.
[ ] A test in relay proves the whole path: post those three events through the signed door with client/relay.ts, then assert the timeline page shows them in order, ?source=bazaar filters to them, the digest sentence for that day reads as the doc promises, and the MCP resource lists them.
[ ] The bottom of the doc is the issue bazaar's crew receives, ready to copy: the file they add (client/relay.ts), the three call sites in their order flow, the two environment variables, what they must not post (no addresses, no card data, no customer names), and how they check it worked — their events on relay's timeline within a second.
[ ] Nothing is seeded into production data: the examples live in the test and the doc.
[ ] README.md gains a line on who posts here and what the timeline is expected to carry.
Files:docs/integrations/bazaar.md, src/server.test.ts or test/bazaar.test.ts, README.md
Risks: an order event is the closest relay gets to personal data — the summary rule has to be written as a refusal, not a suggestion. Deduping on order id plus state is what keeps a webhook retry from doubling the timeline.
The first integration, worked here first so what goes to bazaar's crew is a change they can apply, not an idea they have to design.
Done looks like
docs/integrations/bazaar.mdfixes the contract: kindsorder.placed,order.paid,order.shipped;subjectis the order number;summaryis one line a stranger understands ("3 items, $48.20, to Portland");linkis the order page on bazaar;dedupeis the order id and the state, so a retry or a re-delivery is free;occurred_atis when the order changed, not when the event was sent.client/relay.ts, then assert the timeline page shows them in order,?source=bazaarfilters to them, the digest sentence for that day reads as the doc promises, and the MCP resource lists them.client/relay.ts), the three call sites in their order flow, the two environment variables, what they must not post (no addresses, no card data, no customer names), and how they check it worked — their events on relay's timeline within a second.README.mdgains a line on who posts here and what the timeline is expected to carry.Files:
docs/integrations/bazaar.md,src/server.test.tsortest/bazaar.test.ts,README.mdRisks: an order event is the closest relay gets to personal data — the summary rule has to be written as a refusal, not a suggestion. Deduping on order id plus state is what keeps a webhook retry from doubling the timeline.
Suggested: Scout.