# Trust and security

Last updated October 27, 2026. Contact: support@masirahq.com

How Masira handles your catalog, your credentials and your account. Written by the engineers who run it, from what the code does today. The full policies live in the repository and are available to customers on request.

## Encryption

Both sites are served over HTTPS by Vercel, which terminates TLS and redirects plain HTTP. Both send a two-year HSTS header covering every masirahq.com subdomain, deny framing, and set nosniff and referrer policies. Calls to your store, your PIM and every vendor are HTTPS; connectors refuse plain-HTTP URLs and private network addresses.

At rest, the database host encrypts storage. On top of that, every credential you give us is encrypted by the application with AES-256-GCM before it is written: store and PIM tokens, SFTP secrets, Google and Microsoft OAuth refresh tokens. A stored value without the encrypted-format marker is refused, never used. Credentials are decrypted only inside the job that needs them and are never returned to the browser.

API keys are stored as SHA-256 hashes and shown once. Sign-in codes are stored hashed.

## Authentication and access

Sign-in is passwordless: a one-time code by email, single use, short expiry, hashed at rest. There is no password to leak. Changing the account email needs a code from the current address first; deleting an account needs a confirmation link opened in the signed-in browser.

A workspace has one owner. Members are invited by email and work on the workspace's catalogs, feeds and measurement. Plan, billing, workspace settings, membership, API keys and bulk approvals are owner-only, checked on the server. Every database query is scoped to the workspace owner, so no request can read another workspace's rows.

API keys carry scopes (catalog:read, readiness:read, feeds:read, jobs:write), read exactly what the owner sees, and can be revoked at any time. Production systems are held by the two founders only, with MFA on every account that offers it.

## Rate limiting

Limits are counted in the database, so they hold across serverless instances rather than per process.

- Sign-in and account endpoints: 100 requests per 10 seconds, and 3 per minute for the email-code endpoints.
- Public API: 120 requests per minute per key. Excess requests get a 429 with a Retry-After header.
- Public readiness scans: throttled per address (hashed) and globally.
- Scheduled jobs require a bearer secret; without it the route refuses to run.

## Data retention and deletion

Your catalog, enrichment, feeds and measurement history stay for as long as your account exists, unless you delete them yourself. Operational rows are pruned by a nightly job:

| Data | Kept |
| --- | --- |
| Feed artifacts (built files) | Newest 5 builds per brand and target |
| Survey answers you upload or we read from your review form | Until you remove the file or delete the account |
| Closed background jobs | 30 days |
| Activity events | 180 days |
| Delivery records for the emails we send you | 180 days |
| Our team's log of events on your account | 180 days |
| Unused workspace setup links from an invoice | 180 days after they expire, or until used once the invoice is paid |
| Market signals from public feeds | 90 days |
| Recommendation cache | 30 days |
| Server logs (Sentry; Vercel keeps its copy 1 day) | 30 days |
| Rate-limit counters | 1 day |
| Signups that never verified and own nothing | 1 day |
| IDs of deleted accounts waiting to be erased from PostHog | Until PostHog accepts the request, normally one night |
| Signups that verified but never set up a workspace | 30 days from the last sign-in |
| Workspaces whose paid pilot or plan ended | 30 days, then deleted |
| Workspaces whose invoice was never paid | Until our team removes them |
| Public scan reports | No expiry yet; a 30-day rule is planned |

Survey answers are stored without who gave them. When you upload a survey export, columns that name a person (name, email, phone, address, order or customer number) are detected and left out, and you see which ones before anything is stored. Email addresses and phone numbers inside written answers are removed. Removing a file deletes its answers at once.

You delete your account yourself from Settings. On confirmation any Stripe subscription is cancelled first, then the account row is deleted and the database cascades through everything it owns: workspace, members, catalogs, products, enrichment, feeds and artifacts, deliveries and their secrets, store connections, API keys, jobs and measurement history. Deleted rows persist in the host's backups until its retention window rolls past. Usage events and marketing-site session replays held by PostHog under the account ID are deleted too: every deleted account is queued in the same step, and a nightly job asks PostHog to remove it, normally within a day. Our team can also remove an account that never paid, such as a signup made by mistake. Requests to delete specific data by email are handled within ten business days.

## Backups

Neon, the Postgres host, keeps automated backups with point-in-time restore for the window its plan provides. We do not take separate backups. We have not yet run a restore drill; the first one is scheduled with the first enterprise agreement, and this page will say when it happened.

## Subprocessors

The services that run the platform and what each one sees. All are in the United States; Azure's global model deployments and Anthropic's API may process a single request in another region.

| Vendor | Purpose | Data it sees |
| --- | --- | --- |
| Vercel | Hosting, logs, scheduled jobs | Request traffic, environment secrets |
| Sentry | Error monitoring, alerting and server logs | Stack traces, the failing request's path and headers, server log lines with query values, email addresses and tokens masked; no request bodies, cookies or credentials |
| Better Stack | Uptime checks and the public status page | Our public URLs; no visitor or customer data |
| Neon | Postgres database | Everything stored; credentials additionally app-encrypted |
| Resend | Transactional email | Email addresses, message content |
| Stripe | Subscription billing | Email, plan; card data stays with Stripe |
| Microsoft Azure | Hosts the OpenAI, Grok and Cohere models for enrichment, embeddings, measurement and shopper search; Bing grounding for web-search measurement | Product text, review excerpts, prompts, shopper search queries from the search API; measurement search queries go to Bing |
| OpenAI | Fallback for the same models when Azure is unavailable | Product text, review excerpts, prompts |
| Anthropic | Claude answers for measurement, with Anthropic's web search | Prompts, product text; the search queries Claude writes run through Anthropic's web search |
| Google Cloud | Gemini answers for measurement, with Google Search | Prompts, product text; the search queries Gemini writes run through Google Search |
| Perplexity | Perplexity answers for measurement and market trends, with Perplexity's web search | Prompts, product text; the search queries Perplexity writes run through its own web search |
| Google APIs | Merchant Center push (per-brand OAuth grant); reads of your own Search Console and your sitemap submitted to it, once you add your workspace's Masira email to it | Feed rows; your product page addresses, for Google's index check |
| Microsoft Advertising | Microsoft Merchant Center push, once you sign in with Microsoft | Feed rows for your Merchant Center store |
| PostHog | Usage analytics on the marketing site and the dashboard; session replays of the marketing site and the live demo | Page addresses, clicks, browser and device data; replays of visits to the marketing site and the dashboard's live demo, with typed text masked except a search typed into the live demo's search box; the rest of the dashboard is never recorded, its page addresses are sent without search terms or filters, a click there carries no text from the page, and a signed-in user is known by account and workspace ID only; no names, emails or catalog content |

Your own store or PIM (Shopify, WooCommerce, Akeneo, Salsify) is read with the credentials you supply and, with your permission on plans that include write-back, written to. Review platforms are read through their public widget endpoints; no customer data is sent to them. Survey answers are read inside Masira and sent to no model provider. Product text goes to model providers under API terms that exclude training.

## Access review

Every quarter, and whenever someone joins or leaves, the CTO lists the human accounts on each production system, confirms each belongs to a current founder or employee, confirms MFA, rotates any secret that was shared outside its system, and records the date and outcome. Offboarding happens the same day. The first inventory was written on September 5, 2026: two founders, nobody else.

## Incident response

An incident is anything that exposes customer data to someone who should not see it, lets someone act as a customer they are not, or takes the service down for more than an hour. The steps, in order:

- Acknowledge: tell the other founder, open a private incident issue with the time noticed.
- Contain: revoke affected keys or sessions, rotate the secret, disable the route or roll back, before the full picture is known.
- Assess: work out which workspaces and which data were affected, and write it down as you go.
- Notify: affected customers are emailed within 72 hours of confirming an incident that touched their data, with what happened, what we did, and what they should do.
- Fix: ship the change that removes the cause, with a test that would have caught it.
- Write it up: a short post-incident note within a week; timeline, cause, what changed.

Alerts come from Sentry, which emails both founders on every new error the apps report, Better Stack's uptime checks, Vercel's cron failures, the backend's job-failure logs, Stripe and Resend, and people writing in.

## Responsible disclosure

If you find a vulnerability, email support@masirahq.com with "security" in the subject. Include the steps to reproduce and, if you can, your own workspace id. We acknowledge within three business days, keep you informed while we fix it, and credit you if you want that. Please do not access data that is not yours, do not run denial-of-service tests, and give us a reasonable time to fix before publishing. There is no bug bounty program. The same contact is published in security.txt on both sites.

## Audits

SOC 2 Type I audit available on request for enterprise agreements.

No auditor is engaged today and no penetration test has been commissioned. The policies above are written so that an audit engagement is short when a deal calls for one. Customers with a security questionnaire can send it to the contact address; the answers come from these documents.

---

This page on the web: https://masirahq.com/trust