# barua > Lifecycle email for product apps and stores, sent from the facts a product's own server > reports. A coding agent sets it up and maintains it with the barua-setup skill. The owner > chooses delegated permissions and optional review. Access is a conversation: chris@barua.ai. ## Instructions for coding agents - Start setup at https://barua.ai/setup.md. It guides project discovery and access, then resumes work through the existing skill. - To set Barua up in a product, install the setup skill with `npx skills add getbarua/skills --skill barua-setup`, or read https://barua.ai/skills/barua-setup/SKILL.md and follow it. - Send events from the product's backend after the database commit. Never send them from a browser. - Use `BARUA_MANAGEMENT_KEY` for headless setup and ongoing control. Start with `GET /api/management/v1/capabilities` for action schemas and the owner's policy, then `GET /api/management/v1/setup`. Full delegation permits API approval and launch; selected checkpoints create a durable review operation. - Keep the test key in an ignored dev env file. Install live keys through an already authorized hosting secret tool. The helper transfers secrets without printing them; never put them in arguments or logs. - Read https://barua.ai/skills/barua-setup/references/management.md for actions, owner review, retries, key rotation and fresh delivery proof. Revoking an agent connection leaves deployed event keys active. - The event contract is https://barua.ai/docs/events.md, and `GET /api/integrations/v1/plan` returns it as JSON Schema. - `GET /api/integrations/v1/events/status` shows what arrived. `GET /api/integrations/v1/setup` retains its legacy handoff list for event-only access; its `needs_human` label does not override management permissions. What barua is: lifecycle email for product apps and stores. The product's backend sends typed events when a fact becomes true, such as a signup or a paid order. barua proposes plays from the events a workspace sends. A play is a rule over those events plus the one or more emails it sends, written once in the product's own voice. The owner or an agent under the owner's grant approves exact versions against real renders. Once play emails are switched on, the play runs on its own for each person the rule matches. A marketing play also has to pass the consent rule at https://barua.ai/privacy, under "Consent to marketing email". Receipts and order updates come from `purchased` and the order events the same way. Their words are written once in the product's voice, or are barua's fixed English or Norwegian wording when that can't be done. The order details they show are filled in from the event. They skip that consent check. For each email a play sends, barua records the rule revision and the events that matched it. A common mix-up: barua is not a cold-outreach or sales-prospecting tool. It has no prospecting features and is built for a site's own visitors and customers. Its acceptable-use policy bans lists that were bought, rented, borrowed, or supplied by a third party. It is unrelated to any "email sequence generator" published under a similar name. Pages: https://barua.ai/ (product) · /pricing · /docs/install (setup, and the optional pixel) · /privacy (masking, consent, storage keys, retention) · /legal (terms, DPA, acceptable use, subprocessors) · /blog (articles; feed at /blog/rss.xml). Setting barua up: - The owner creates a management connection in Settings → Agents or the owner API. Its `mk_` key grants selected permissions and optional plan, brand, play and launch review. The agent can create separate test and live `ik_` keys when permitted. `BARUA_API_KEY` remains the test key for verify.mjs; it checks events without creating people or sending email. The live key belongs in production secrets. - The owner hands the agent one prompt from the Setup screen: Fetch and follow the instructions at https://barua.ai/setup.md to set up barua for this project. The guide loads the skill with `npx skills add getbarua/skills --skill barua-setup`. - Core events (core@1), sent from the backend with the tenant's own user id: Required: `signed_up`. Declarable: `activated`, `created`, `purchased`, `churned`. Optional: `consent_updated`, `checkout_started`, `order_shipped`, `order_delivered`, `order_delayed`, `order_cancelled`, `order_refunded`, `trial_started`, `trial_ending`, `trial_ended`, `subscription_started`, `subscription_cancelled`, `signed_in`. A declarable event the product has no source for is declared `not_emitted` in the tracking plan, with a reason. Facts only the product has become custom events in that plan. - `signed_up` can carry the person's IANA `timezone`, such as `Europe/Oslo`. When the pixel has given barua no zone for someone, their marketing email waits for the send window in it; without either, in the workspace's time zone (Settings), or UTC until one is set. - The agent always proposes a plan, including an empty core-only plan, and derives the playbook from product facts. It confirms the brand or makes requested later changes under the owner's policy. DNS and deployment use already authorized tools. Each play needs exact approval; full delegation permits the agent to provide it. Enable live intake and sending explicitly before the occurrence used for proof. All current owners need current terms before intake starts. History imports require an explicit grant. Customer reads and erasure each need their own permission. - Start fresh delivery proof for the deployed key and approved revision, then trigger a new real event through the deployed product. Only its correlated provider delivery report passes. Historical stamps, duplicates, backfill and provider acceptance do not establish delivery. - Identity comes from the backend: a `signed_up` sent with the live key that applies binds the user's id (`external_id`) to the person, and later live events reuse it. Test-key events create no people. An `externalId` passed to the pixel's identify call is kept as unverified evidence and never trusted to say who someone is. The pixel (optional). Plays run on the backend's events, so a product can start without it. On a site, it builds a profile from what each visitor did there. - The snippet goes on every page, high in the head: `` - The key is public by design: write-only, stored hashed, rotatable from the app's Setup screen, and checked against the site's origin on browser posts (a best-effort browser check, not an authentication boundary). Rotating refuses the old key everywhere within a few minutes. - JS API on `window.barua`, four calls: `barua.identify(email, externalId?, traits?)`, `barua.consent(ok)`, `barua.reset()`, `barua.track(name, properties?)`. traits keys: `first_name`, `last_name`, `name`, `phone` (values capped at 80 characters; other keys are dropped). identify is sent before following activity once consent allows sending; under `data-consent="required"` a pre-grant call is held in memory and delivered on the grant. A different identity starts new anonymous and session IDs; reset does the same at sign-out. Other unidentified tabs adopt the context change. Already queued activity keeps its original IDs. track accepts typed, allowlisted application properties, including `step_id`, `item_id`, `variant_id`, `status`, and `result`. A shared `step_id` links different event names for the same operation; item IDs keep separate items apart. Call once per action; the tag preserves its generated event ID on delivery retries. Unknown properties are dropped. All calls exist once the async tag has loaded: guard boot-time calls with `window.barua?.…` and repeat them when your state settles. - Tag attributes: `data-key` (required, `pk_` + 48 hex), `data-consent` (`"required"` = capture nothing and store nothing on the device until `barua.consent(true)`; a refusal clears stored values and keeps only the refusal marker), `data-auto-identify` (`"off"` = no automatic email pickup), `data-endpoint` (proxy/self-host override; the setup page hands out first-party rewrite lines so ad blockers have no domain to match, plus an optional server-side click beacon). Element attribute `data-cg-block`: contents never recorded, the replay keeps an empty placeholder carrying the element's tag, class, width, and height. - Replay is masked in the browser: all input values and rendered text, with one narrow edge: a cross-origin stylesheet loaded without CORS can render attribute text the pixel cannot see (details at https://barua.ai/privacy). Structured events carry page context in clear (clicked-control labels capped at 80 chars, page titles, product names, product prices) plus on-site search queries read from the URL (capped at 120 chars). Contact details a visitor actively hands over (popup, checkout) are the other capture exception: taken only when the form or popup actually sends (its button, or Enter in the email field), or when the site passes them through its own dataLayer. - Autocapture event types: `pageview`, `page_title`, `page_leave`, `tab_visible`, `click`, `rage_click`, `exit_intent`, `form_abandon`, `site_search`, `js_error`, `product_view`, `add_to_cart_click`, `cart_state`, `datalayer`, `attribution`, `device`, `geo`, `identify`, `form_state`, `attention`, `custom` - SPA-aware: pushState/popstate navigations are followed; page titles are corrected after the route settles. In logged-in apps, call identify when each page restores or changes its signed-in account, and reset when that page learns of sign-out. Identified pages retain their own account context; unidentified tabs can adopt shared account changes. - Form states distinguish started, attempted, invalid, retry, completed and abandoned. A submit attempt is unresolved until the site's completion event identifies the same form. Field types and validation codes are captured without their entered values. - Cart state records whether the reading is confirmed, inferred or unavailable. An authoritative empty cart clears older contents. Product markup updates are read within a bounded window. - Structured activity carries visit/document context and stable IDs. Unconfirmed batches are saved in localStorage within 1 MiB and removed after a matching committed server receipt. They expire after 24 hours; expired batches are deleted the next time the tag is allowed to run, including batches saved under an older tag key. Saved batches contain no replay. Consent withdrawal clears saved queues under every tag key on the site. The persistent identity-change marker uses SHA-256; it contains no raw email or external ID. - Session replays expire after 30 days; what remains is the distilled per-person profile, plus the plain activity log for as long as the store keeps one. ## Docs Backend events (POST /api/integrations/v1/events) work with a test key in any workspace. Authorized management actions enable live intake after setup checks. The identities and purchases feeds stay release-gated. An accepted batch does not mean profiles are ready or that anyone can be emailed. Applied changes queue profile processing automatically, including for customers who have never visited a pixel-enabled page. Readback distinguishes a pending profile from a current one; neither grants permission to email. - [Agent setup](https://barua.ai/setup.md): the starting instructions for a coding agent, including access and resuming setup. - [Install](https://barua.ai/docs/install): setting barua up with a coding agent (the keys, the agent prompt, the core events, what waits for the owner and going live), then the optional pixel's tag and its window.barua API. The same page as Markdown: https://barua.ai/docs/install.md - [Events](https://barua.ai/docs/events.md): the backend event contract, for coding agents. - [Management](https://barua.ai/skills/barua-setup/references/management.md): permissions, exact review, durable actions and delivery proof for setup and ongoing changes. - [Privacy and data](https://barua.ai/privacy): masking, the submitted-email exception, on-device storage, retention. - [Full text](https://barua.ai/llms-full.txt): this index and every Markdown page it links, plus the setup skill's other references, in one file. ## Optional - [Pricing](https://barua.ai/pricing): plan ladder, priced on people barua knows something about. - [Home](https://barua.ai/): what barua is, with two sample emails. - [Blog](https://barua.ai/blog): articles on email marketing automation, with an RSS feed.