# Docs Mara is hired, not installed, so there is not much to integrate. What she needs from your side is data: who your users are and what they do. Two surfaces carry it, and both are documented here in enough detail that an AI coding agent can do the work for you. ## Connect your data **[Events API](/docs/events-api).** One endpoint, two operations. `identify` upserts a contact, `track` records what happened and fires matching journeys. Bearer-key auth, batching, idempotency, rate limits, naming guidance, runnable examples. **[Webhooks](/docs/webhooks).** Stripe, Polar, and Clerk. Paste Mara's per-tenant URL into the provider and the provider's signing secret into Mara. Events arrive signature-verified and normalized into the eight lifecycle moments journeys trigger on. Contacts can also arrive by CSV or JSON import from the settings page; no docs needed, the upload form explains itself. ## For AI coding agents Every docs page has a raw markdown twin: append `.md` to the URL. There is also [llms.txt](https://hiremara.com/llms.txt) at the site root, and [llms-full.txt](https://hiremara.com/llms-full.txt) with the full docs inlined. Your founder's dashboard (Settings, Integrations, Events API) has a ready-made prompt that includes the tenant's real endpoint URL. ## Where things are decided Integration gets data in. Everything else, drafting journeys, approving emails, pausing sends, teaching Mara what to say, happens in your dashboard and chat. If you are evaluating Mara rather than wiring her up, start at [how it works](/how-it-works). --- # Events API Send your product's events to Mara. One endpoint, two operations: `identify` tells Mara who a contact is, `track` tells her what happened. Any active journey whose trigger matches an incoming event fires automatically, per contact. This page is the complete spec, written for humans and for AI coding agents. The raw markdown lives at [hiremara.com/docs/events-api.md](https://hiremara.com/docs/events-api.md). The fastest path: open Settings, then Integrations, then Events API in your dashboard and copy the ready-made prompt into Claude Code, Cursor, or whatever agent writes your code. It links back here. If your "events" are billing events from Stripe or Polar, do not send them through this API. Point your provider's webhooks at Mara instead, so payloads arrive signature-verified and normalized. See [Webhooks](/docs/webhooks). ## Endpoint ``` POST https://hiremara.com/api/tenants/{tenantId}/events Content-Type: application/json Authorization: Bearer {your ingestion key} ``` Your exact endpoint URL, with your tenant id filled in, is shown in Settings under Integrations, Events API. ## Authentication Auth is a per-tenant bearer key with the prefix `mara_ing_`. Generate it on the same settings row. The raw key is shown exactly once at generation; Mara stores only a hash. Generating a new key immediately revokes the old one. This is a server-to-server key. Keep it in an environment variable on your backend. Never ship it to a browser or a mobile client. ## Request body The body is a single operation, or a batch of up to 100: ```json { "batch": [ { "type": "identify", "userId": "u_42", "email": "ada@example.com", "name": "Ada", "traits": { "plan": "starter" } }, { "type": "track", "event": "user.signed_up", "userId": "u_42", "messageId": "evt_001" } ] } ``` ### identify Upserts the contact. Pure projection: it never writes an event and never fires a journey. | Field | Type | Required | Notes | | ------------ | ------------ | ----------------------------------------------- | -------------------------------------------------------------- | | `type` | `"identify"` | yes | | | `userId` | string | at least one of `userId`, `externalId`, `email` | Your stable user id. | | `externalId` | string | | Same meaning as `userId`. If both are sent, `externalId` wins. | | `email` | string | | Must be a valid email address. | | `name` | string | no | Display name. | | `traits` | object | no | Custom attributes, flat scalars only. See sanitization below. | ### track Records an event against a contact and fires any matching journeys. | Field | Type | Required | Notes | | --------------------------------- | --------- | ----------------- | ----------------------------------------------------------------------------------- | | `type` | `"track"` | yes | | | `event` | string | yes | The event type, 1 to 120 characters. See naming below. | | `userId` / `externalId` / `email` | string | send at least one | Same identity rules as identify. A track with no identity is skipped, not an error. | | `properties` | object | no | Event details, flat scalars only. Same sanitization as traits. | | `timestamp` | string | no | ISO 8601. Defaults to arrival time. Invalid values fall back to arrival time. | | `messageId` | string | no | Your idempotency key for this event. Strongly recommended. | ### Identity resolution `externalId` (or `userId`) is the contact's primary identity; `email` matches or creates the contact when no external id is sent. Send the same `userId` from signup onward and Mara keeps one contact per user, even if the email changes later. Contacts that arrive with an email get lifecycle consent recorded automatically, so journey sends are not blocked downstream. ### Traits and properties sanitization `traits` and `properties` become contact attributes and event details that Mara's agents can reference in copy, so they are filtered at the door: - Flat objects only. Nested objects and arrays are dropped. - Values must be strings, finite numbers, or booleans. Strings are trimmed and truncated at 1024 characters. - Keys: up to 64 characters from letters, digits, `_`, `.`, `:`, `-`. At most 50 keys survive per object. - Keys that look like secrets or sensitive PII (password, token, api_key, ssn, card numbers, and similar) are dropped outright. Do not send secrets. ## Idempotency and retries Set `messageId` on every track op: a UUID, or the id of the row in your own event log. Retrying a request with the same `messageId` is safe; the duplicate op returns `"status": "duplicate"` and writes nothing. Identify ops are upserts and naturally safe to retry. ## Rate limits 600 requests per hour per tenant, token bucket, burst up to 600. A batch of 100 operations counts as one request, so batching gives you up to 60,000 events per hour. Over the limit you get a 429 with a `Retry-After` header in seconds. Back off and retry after that. ## Responses Success is a 200 with one result per operation, in order: ```json { "ok": true, "results": [ { "index": 0, "type": "identify", "status": "ok", "contactId": "9a1f..." }, { "index": 1, "type": "track", "status": "ok", "contactId": "9a1f..." } ] } ``` Per-op `status` values: `ok`, `skipped_no_identity` (the op carried no usable identity), `duplicate` (the `messageId` was already processed). Errors return `{ "ok": false, "code": "...", "message": "..." }`: | HTTP | `code` | Meaning | | ---- | ------------------ | ------------------------------------------------------------------------- | | 400 | `bad_request` | Body is not valid JSON or fails the schema. | | 401 | `unauthorized` | Missing or wrong bearer key. | | 412 | `no_ingestion_key` | No key has been generated for this tenant yet. | | 429 | `rate_limited` | Over the hourly cap. Honor `Retry-After`. | | 500 | `infra` | Something broke on Mara's side. Safe to retry with the same `messageId`s. | ## How events fire journeys Event types are free-form. Two ways they connect to journeys: 1. **The signup event.** On the same settings row, tell Mara which event means "a new user signed up" (for example `user.signed_up`). Saving it seeds a draft welcome journey that fires on that event; you approve the draft from your dashboard to make it live. 2. **Any other event.** Ask Mara in chat. "When a user fires `project.created`, start the activation journey" is enough; she drafts the journey with an on-event trigger and you approve it. Naming guidance: lowercase, dot-namespaced, object.action. `user.signed_up`, `project.created`, `report.exported`. Allowed characters are letters, digits, spaces, `.`, `_`, `:`, `-`, `/`, up to 120 characters. Keep types low-cardinality: no user ids or timestamps inside the type string. Details belong in `properties`. ## Quickstart Test with curl (the endpoint URL and key come from your settings page): ```bash curl -X POST "https://hiremara.com/api/tenants/{tenantId}/events" \ -H "Authorization: Bearer $MARA_INGESTION_KEY" \ -H "Content-Type: application/json" \ -d '{ "batch": [ { "type": "identify", "userId": "u_42", "email": "ada@example.com", "name": "Ada" }, { "type": "track", "event": "user.signed_up", "userId": "u_42", "messageId": "test-001" } ] }' ``` A minimal Node helper: ```js const MARA_EVENTS_URL = process.env.MARA_EVENTS_URL; // from your settings page const MARA_INGESTION_KEY = process.env.MARA_INGESTION_KEY; export async function maraSend(ops) { const res = await fetch(MARA_EVENTS_URL, { method: 'POST', headers: { Authorization: `Bearer ${MARA_INGESTION_KEY}`, 'Content-Type': 'application/json', }, body: JSON.stringify({ batch: ops }), }); if (!res.ok) throw new Error(`Mara events API ${res.status}: ${await res.text()}`); return res.json(); } // At signup: await maraSend([ { type: 'identify', userId: user.id, email: user.email, name: user.name }, { type: 'track', event: 'user.signed_up', userId: user.id, messageId: `signup-${user.id}` }, ]); ``` Call Mara off the request path (a queue, a background job, or at minimum fire-and-forget with a catch). An email platform should never be able to slow your product down. ## Verify it landed Three checks, in order: 1. The HTTP response: 200 with `"status": "ok"` per op. 2. Settings, Integrations: the ingestion health strip shows per-connector contact counts and last activity. 3. Ask Mara in chat: "did you get my test event?" ## For AI coding agents If you are an agent implementing this integration, the checklist: 1. Put the endpoint URL and ingestion key in env vars (`MARA_EVENTS_URL`, `MARA_INGESTION_KEY`). Never hardcode the key; never expose it client-side. 2. Add a small server-side helper that POSTs `{ batch: [...] }` with the bearer header. Batch when you can, up to 100 ops. 3. On signup: send one `identify` (userId, email, name, useful traits) plus one `track` with the agreed signup event type. 4. Instrument the 3 to 5 lifecycle moments that matter (activation milestone, key feature used, plan limit reached). Stable dot-namespaced event types, details in `properties`. 5. Set a deterministic `messageId` per event so retries are safe. Retry on 429 (honor `Retry-After`) and on 5xx; do not retry 4xx. 6. Keep Mara off the hot path: queue or fire-and-forget. A Mara outage must not break signup. 7. Verify with the curl above, then confirm in the response that every op returned `"status": "ok"`. --- # Webhooks: Stripe, Polar, Clerk Billing and auth events reach Mara through the webhooks you already have. Each connector gets a per-tenant URL, verifies the provider's signature, and dedupes on the provider's event id, so redeliveries are safe. Setup is two pasted values: Mara's URL into the provider, the provider's signing secret into Mara. Your per-tenant URLs and the secret fields live in Settings under Integrations. The raw markdown version of this page is at [hiremara.com/docs/webhooks.md](https://hiremara.com/docs/webhooks.md). For product events from your own code, see the [Events API](/docs/events-api). ## What journeys can trigger on Provider events are normalized into eight lifecycle moments. Journeys trigger on these, not on raw provider payloads: | Mara event type | Meaning | | ----------------------- | ------------------------------------------------ | | `subscription-started` | A new subscription begins. | | `trial-converted` | A trial becomes a paying subscription. | | `subscription-upgraded` | Plan or quantity changed upward. | | `subscription-canceled` | Subscription canceled or revoked. | | `payment-failed` | A renewal payment failed (dunning territory). | | `payment-recovered` | A previously failing payment went through. | | `refund-issued` | A charge was refunded. | | `purchase` | A one-time purchase, not tied to a subscription. | Anything else the provider sends returns `200` with `"status": "ignored"`. It is fine, and simplest, to send everything. Custom fields you attach as provider metadata (Stripe subscription or checkout metadata, Polar order or customer metadata, Clerk public metadata) are projected onto the contact as attributes, with the same sanitization as the Events API: flat scalars only, secret-looking keys dropped, capped at 50 keys. ## Stripe Endpoint: ``` POST https://hiremara.com/api/webhooks/stripe/{tenantId} ``` Setup: 1. In the Stripe dashboard, open Developers, then Webhooks, and add a destination with your per-tenant URL from Mara's settings page. 2. Select these events (or send all): `customer.subscription.created`, `customer.subscription.updated`, `customer.subscription.deleted`, `invoice.payment_failed`, `invoice.payment_succeeded`, `charge.refunded`, `checkout.session.completed`. 3. Copy the signing secret (`whsec_...`) and paste it into Settings, Integrations, Billing, Stripe. How Stripe events map: | Stripe event | Becomes | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | `customer.subscription.created` | `subscription-started` | | `customer.subscription.updated` | `trial-converted` when status goes trialing to active; `subscription-upgraded` when the plan or items changed; otherwise ignored. | | `customer.subscription.deleted` | `subscription-canceled` | | `invoice.payment_failed` | `payment-failed` | | `invoice.payment_succeeded` | `payment-recovered`, only when it recovers a failing invoice. First-attempt successes are ignored. | | `charge.refunded` | `refund-issued` | | `checkout.session.completed` | `purchase`, only for `mode=payment` (one-time). Subscription checkouts are already covered above. | Requests are verified with the `stripe-signature` header against your pasted secret. Wrong or missing signature returns 401; a tenant with no secret configured returns 412. ## Polar Endpoint: ``` POST https://hiremara.com/api/webhooks/polar/{tenantId} ``` Setup: 1. In Polar, open your organization settings, then Webhooks, and add an endpoint with your per-tenant URL. 2. Select the subscription and order events (or send all). 3. Copy the signing secret and paste it into Settings, Integrations, Billing, Polar. How Polar events map: | Polar event | Becomes | | ----------------------------------------------- | ----------------------------------------------------------------------------------- | | `subscription.created` | `subscription-started` | | `subscription.active` | `trial-converted` | | `subscription.upgraded` | `subscription-upgraded` | | `subscription.canceled`, `subscription.revoked` | `subscription-canceled` | | `subscription.past_due` | `payment-failed` | | `subscription.recovered` | `payment-recovered` | | `order.refunded` | `refund-issued` | | `order.paid` | `purchase`, only for orders not tied to a subscription. Renewal cycles are ignored. | Signatures follow the Standard Webhooks spec (`webhook-id`, `webhook-timestamp`, `webhook-signature` headers). ## Clerk Endpoint: ``` POST https://hiremara.com/api/webhooks/clerk/{tenantId} ``` Setup: 1. In the Clerk dashboard, open Webhooks and add an endpoint with your per-tenant URL. 2. Subscribe to `user.created`, `user.updated`, and `user.deleted`. 3. Copy the Svix signing secret and paste it into Settings, Integrations, Clerk. What each event does: `user.created` creates the contact and records a `user.created` event, which can fire your welcome journey (map it as the signup event on the settings row). `user.updated` refreshes the contact's email and name. `user.deleted` records a deactivation signal. Mara projects the email, username, avatar URL, and public metadata; private and unsafe metadata are never read. Optional backfill: paste a Clerk Backend API key on the same settings row and Mara imports your existing users as contacts, so journeys do not start from an empty list. ## Verify it is flowing After setup, trigger a test event (most providers have a "send test event" button) and check the ingestion health strip in Settings, Integrations: it shows per-connector contact counts and last activity. Or ask Mara in chat. --- # Help center Short, practical guides to running your lifecycle email program with Mara. Each page opens with a quick walkthrough, then explains what you can do, how to do it, and where the limits are. Mara is hired, not installed. You approve the work; she drafts, sends, and improves the emails. These pages cover the surfaces where that happens. ## Topics - [Dashboard](/help/dashboard): the four panes and what each one is for, from the Needs you queue to Chat. - [Journeys](/help/journeys): what a journey is, how to see what each one sends and to whom, and how to pause, resume, or archive one. - [Chat](/help/chat): how to ask Mara to build, edit, and approve journeys and audiences, and what she can and cannot do from the conversation. - [Playbook](/help/playbook): what Mara has learned about writing to your customers, confidence tiers, sources, and how it shapes her drafts. - [Settings](/help/settings): a reference to every settings section, from brand profile and value metric to send window, reply autonomy, and suppression. If something here is missing or unclear, tell us from the Feedback button in your dashboard. ## For AI assistants Every help page has a raw markdown twin: append `.md` to the URL. The site root also serves [llms.txt](https://hiremara.com/llms.txt) and [llms-full.txt](https://hiremara.com/llms-full.txt). --- # Dashboard Your dashboard is where you work with Mara day to day. It opens with one question in mind: does Mara need anything from you? Four panes answer the questions you have most visits. Needs you is the queue of things waiting on your call. Activity is the history of what Mara has done. Results shows whether the program is working. Chat is where you direct her. ## What you can do - See in one glance whether Mara is waiting on you. The Needs you pane collects everything that needs your decision: blockers that stop her working, customer replies where a person is waiting, emails and journeys she has drafted for your approval, and optional ideas she suggests. - Read the running history of what Mara has done in the Activity pane: emails sent, journeys activated, replies handled, learnings added. It is a log, so nothing there asks you to act. - Check whether the program is working in the Results pane: your value metric over time, per-journey funnels, top emails, and deliverability. - Direct Mara in the Chat pane: ask her to design a journey, edit copy, build an audience, or explain anything. See the [Chat guide](/help/chat) for how that works. - Reach your reference pages from the header: Journeys (what each one sends), Playbook (what Mara has learned), and Settings (everything you configure). ## How The dashboard has a header and four panes you can expand or collapse. Needs you and Chat are open by default; Activity and Results start collapsed. - Work top to bottom in Needs you. Items are tiered by urgency, with blockers first and optional ideas last. Acting on an item clears it from the pane. When the queue is empty you see "Nothing needs you. Mara is working." - Approving and rejecting happen on the cards in Needs you, using the same plain verbs everywhere: Approve and send for an email, Approve and activate for a journey, Reject to drop a draft, Dismiss to hide an idea. - Activity and Results are read-only. Expand a row in Activity to read the full detail; on a failed send you can hand the context to chat with "Ask Mara about this". - Use the header links to open the Journeys, Playbook, and Settings pages when you want to look something up, and the workspace switcher to move between companies. ## Limitations - Needs you is for decisions, not browsing. Once you act on an item it leaves the pane, by design. To revisit something later, look in Activity or on the relevant page. - Activity never carries action buttons. It is a record of what happened. Anything you can act on lives in Needs you, with the Activity row as its echo. - Results reports aggregates over a time window, not row-level actions. Where a number is a stand-in for what you really care about, the label says so. - Building and editing happen in chat, not on the panes. The panes surface and summarize; the work itself is a conversation with Mara. - The dashboard shows your own workspace only. It never exposes another company's data. --- # Journeys A journey is one lifecycle email program. A welcome series, a win-back, a dunning sequence for failed payments. Each journey has a trigger that starts it (a new signup, a canceled subscription, entry into an audience), one or more email steps, and timing between them. Mara runs every journey for you. You decide which ones go live. ## What you can do - See every journey Mara runs for you, with its status, what starts it, how many steps it has, and how much it has sent in the last 30 days. - Open any journey to read exactly what it sends, to whom, and when: the audience, each step with its trigger and timing, the latest email copy, and the last 30 days of results for that journey. - Where a step is testing variants, see the live versions and the share of sends each one is getting as Mara learns which lands best. - Pause a live journey so it stops sending, resume a paused one, or archive a journey you no longer want. - Ask Mara in chat to design a new journey, change copy or timing, or set up a whole program. ## How The Journeys pages live behind the Journeys link in your dashboard header. - The list page shows all of your journeys. Click any one to open its detail page. - The detail page lays out the audience, the funnel for the last 30 days, and each step in order with its trigger, timing, and the latest email. - Pause, Resume, and Archive are buttons on the journey, so a quick state change does not need a conversation. A live journey can be paused; a paused journey can be resumed; any journey can be archived. Archiving asks you to confirm first. - Anything that changes what a journey says or when it sends happens in chat, the place where Mara does the work. Open the Chat pane and tell her what you want. See the [Chat guide](/help/chat) for how that works. ## Limitations - The Journeys pages are for reading and for mechanical state changes (pause, resume, archive). They do not let you edit copy or timing in place. Those edits go through chat so Mara can redraft and you can re-approve. - Resuming a journey re-runs the same checks as going live. If another live journey already starts on the same trigger, Mara will not resume into that collision. Pause or archive the other one first. - One trigger should drive one live journey. Mara refuses to put two live journeys on the same trigger so a contact never gets two emails for the same moment. - A journey only sends once it is live and your sending domain is set up. A drafted or paused journey sends nothing. - These pages show your own journeys only. They never expose another company's data. --- # Chat Chat is how you direct Mara. It is a conversation in your dashboard where you ask her to design journeys, write and edit emails, build audiences, approve or reject her drafts, and teach her what works. She streams a reply, and when she takes an action she shows it inline so you can see what changed. ## What you can do - Ask Mara to design a journey for any moment in your customer lifecycle, or to set up a whole program. She drafts it and you approve before anything goes live. - Edit an existing journey: change the copy, the timing, the audience, or the trigger. Every edit comes back to you to re-approve. - Build an audience from your contacts and their behavior, then attach a journey to it. - Approve or reject what Mara has drafted, including journeys and the variant sets she proposes for testing. - Pause, resume, or archive a journey from the conversation. - Manage your Playbook, the set of learnings that shape how Mara writes. Ask her what she has learned, add a learning, or retire one. - Fix a send problem without leaving chat: rewrite or retire an email variant, add a suppression, or clear failed sends. - Ask what is happening: which journeys are active, what has been sent, and why a send failed. ## How Open the Chat pane in your dashboard and type what you want, in plain language. You do not need to name a tool or learn any syntax. Mara figures out what to do. - When she takes an action, it appears inline in the conversation as a collapsible step, so you can expand it to see exactly what she did. - Actions that change what gets sent are gated. Mara drafts, and the draft waits for your approval before it sends. You stay in control. - Some cards elsewhere in the dashboard hand you off to chat with the context already filled in, for example an idea from Mara or a failed send you want to ask about. Approving from there runs the same conversation. - Long conversations stay coherent: Mara works from a running summary of the earlier messages plus your most recent ones. Start a new chat anytime for a clean slate, and use the history dropdown to jump back into a past conversation. ## Limitations - Chat does not send data into Mara. Connecting your product (who your users are and what they do) happens through the Events API and webhooks, covered in the [developer docs](/docs). - Mara will not skip your approval on anything that sends. She drafts; you decide. Approving is always a deliberate step. - She acts only on your own workspace. She cannot see or touch another company's contacts, journeys, or data. - Mara reaches for a tool before she tells you she cannot do something. If she says a request is out of scope, it is because no tool covers it yet, not because she did not look. - Chat is for directing the program. To read what a journey sends step by step, the [Journeys pages](/help/journeys) lay it out without a conversation. --- # Playbook Your Playbook is what Mara has learned about writing to your customers. As she sends emails, reads replies, and watches outcomes, she distills the signal into short, evidence-cited learnings: what subject lines land, what tone fits your audience, when to send, what to say. The Playbook is that running set of insights, and Mara uses it when she writes for you. ## What you can do - Read what Mara has learned, grouped by category: voice, subject lines, timing, customers, structure, and offers. - See how sure she is about each learning. Every learning carries a confidence tier, from a hypothesis she is still testing to a validated insight backed by your own results. - See where a learning came from. A learning is either one you taught Mara or one she distilled from your data, and each row is labeled so you can tell. - Open the evidence behind a learning. Distilled learnings cite the real sends, replies, and outcomes they came from, so nothing is a black box. - Add a learning, retire one, or ask what she knows, all from chat. See the [Chat guide](/help/chat). - Turn off applying learnings in Settings if you want Mara to keep watching and noting without changing her drafts yet. ## How The Playbook lives behind the Playbook link in your dashboard header. - Active learnings are grouped by category at the top, each with its confidence tier, its source, and how many times it has been applied. Retired or contradicted learnings sit in a collapsed history section below. - Mara builds the Playbook on her own as your results come in. You do not have to do anything to start it. A learning you add yourself in chat sits alongside the ones she distills. - When applying learnings is on, the default, Mara folds the relevant learnings into every email she writes. The validated ones shape her drafting directly. - Toggle "Apply Playbook learnings" in Settings to switch between using the Playbook in drafts and observe-only mode, where it keeps building but does not change her copy. ## Limitations - The Playbook fills in over time, not on day one. Mara needs your sends, replies, and outcomes to have something to learn from, so a new workspace starts with little or nothing. - It is read on its page and managed in chat. The page is for reading; adding or retiring a learning is a chat action. - Mara holds the evidence bar high. She will not promote a learning to validated without your real data behind it, and she will not quietly overwrite a learning you taught her. - A learning can be contradicted later. When new results disagree with an old insight, Mara moves it to history rather than pretending it still holds. - Your Playbook is yours alone. It is built only from your data and never mixes in another company's results. --- # Settings Settings is where you configure how Mara works for your company. This page is a quick reference to every core section. Reach Settings from the gear icon or the Settings link in your dashboard header; jump to a section using the side navigation. Most changes take effect on the next email Mara writes or the next worker scan. ## Brand Profile The voice and product context Mara uses for every email she writes: your tone, a sample line that sounds like you, your value prop, your ideal customer, and the features she is allowed to reference. It also holds who emails are signed by and the mailing address that marketing email is required to carry. Mara fills this in from your website, and you correct it here. Changes apply to the next email she writes. ## Value Metric The single number Mara optimizes for and reports on in Results: revenue, signups, activations, or replies. Pick the one that matters most for your stage. It applies to the next Results render. ## Integrations The external systems Mara reads from or writes to: your sending domain, GitHub, billing webhooks from Stripe or Polar, the Events API, Clerk, Supabase, and Molted. This is also where you connect a product so Mara learns who your users are and what they do, and where an ingestion-health strip shows per-connector contact counts. Connecting your product is covered in the [developer docs](/docs). ## Send From The address Mara sends from, and where replies come back. You choose the local part on your verified sending domain. Register a sending domain first, since the address sits on it. If a mailbox is already live, a new address takes effect the next time Mara provisions, not as a live rename. ## Send Window When Mara is allowed to send, plus the most emails one contact gets in a week. Set your timezone and a per-contact weekly cap; the cap defaults to 3 per week, and 0 disables it. On top of the cap, Mara sends at most one journey email per contact per day and still respects the deliverability fatigue gate. It applies on the next worker scan. ## Reply Autonomy How much Mara can send a reply on her own, set per kind of inbound. She drafts every reply regardless; this decides which ones she sends without waiting for you. Each kind can graduate from "always ask me" to auto-send only after enough approvals, so she learns your voice first. Some kinds, like complaints, legal, and unsubscribes, always wait for you and cannot be changed. ## Audiences The saved audiences Mara can target with journeys, shown as a read-only list with live sizes and a proposed or active badge. Mara proposes audiences from your product activity; to build one, ask her in chat. ## Suppression Addresses Mara must never email again. Paste an email and pick a reason, and Mara skips it from then on. This is add-only; it is your escape hatch for an address you know should not hear from you. ## Subscription Your Mara plan, Starter or Growth. You start a 14-day trial to activate journeys and begin sending, then pay per active journey with sends metered and overage shown. Sending is never blocked; you see usage and an overage estimate here, and "Manage billing" opens the customer portal. Your monthly send allotment is read-only here, by design. ## Danger Zone Delete this company. Deleting stops in-flight sends, pauses active journeys, cancels pending emails and journey drafts, cancels any active subscription, and removes your access. You confirm by typing the company name, and it is reversible only with support intervention.