Privacy and security

Last updated: 20 August 2026

This page explains what reaches SmallCRM when you use the hosted service at smallcrm.org, what stays on your machine, and where the main security boundaries are.

SmallCRM is different from SmallDocs: it is a hosted CRM and persistence layer. If you use the hosted service, your account, workspace configuration, CRM records, forms, webhooks, email activity, saved views, and event history are stored on SmallCRM servers.

Hosted account data

When you sign up or log in, SmallCRM stores:

• Your email address.
• Linked sign-in identities, such as a Google account identifier or verified email-code identity.
• A salted scrypt password hash only if you use the transitional password sign-in path; SmallCRM never stores the raw password.
• Session records containing a hash of the session token, creation time, expiry time, last-seen time, and revocation time if you log out.
• Authorized CLI installation records, including their name, token hash, creation and last-used timestamps, and revocation status.
• Workspace names, ids, slugs, and membership records.

Browser sessions use the scrm_session cookie. The cookie is HttpOnly, SameSite=Lax, expires after 30 days, and is marked Secure on the production HTTPS deployment.

The CLI stores its credential on your own machine in ~/.smallcrm/sessions.json by default. The file is written with owner-only permissions where the operating system supports that. scrm status --json reports account emails and origins, but it does not print credentials.

Workspace data

Each hosted workspace has its own SQLite workspace database. That database stores:

• Collections and schema definitions.
• CRM records and record relation indexes.
• Saved query views.
• Public form configs.
• Inbound webhook configs.
• Email-provider connections, normalized threads, messages, drafts, delivery state, and explicit links between email activity and CRM records.
• Mailbox-access requests and grants, including their requested and approved scope, purpose, requesting CLI installation, expiry, status, use count, and last-used time.
• Event logs for important reads and writes.

A workspace binding file in your project directory, .smallcrm/workspace.json, is only a pointer to the hosted workspace. It contains the hosted origin and workspace identity/path. It is not a local CRM database.

CLI and browser views

Ordinary scrm commands operate on the hosted workspace when a project directory is bound to one. Commands send the relevant request body to the hosted SmallCRM API. For example, an upsert sends records, a schema command sends the schema, and a query sends the query DSL.

The hosted browser app fetches workspace data through authenticated workspace API routes. It stores a small amount of interface state in your browser:

• localStorage keys beginning with scrm:view: remember the selected row/object view for a workspace.
• sessionStorage keys beginning with scrm:return: remember a same-workspace return path while navigating records.

This browser storage is not used for analytics or advertising.

Email integrations

Email connections are separate from signing in to SmallCRM. Connecting a provider authorizes SmallCRM to use the provider capabilities shown in Email settings.

• Resend: SmallCRM can configure a workspace domain, send email, receive replies, and receive delivery events. Workspace members share the resulting CRM conversations.
• Gmail: SmallCRM can send through the connected Google account, store the outgoing message and its provider identifiers, and periodically read messages in Gmail threads SmallCRM already tracks so replies appear on the related CRM record.
• Outlook: SmallCRM can currently identify the connected Microsoft account and send email into its Sent Items. It does not currently read Outlook inbox messages or replies.

Provider OAuth tokens and Resend credentials are stored encrypted. SmallCRM stores normalized message data needed for CRM history, which can include sender and recipient addresses, subject lines, message bodies, dates, provider message/thread identifiers, delivery status, and relation data. Disconnecting an email provider prevents new provider access; it does not silently delete CRM messages already recorded in the workspace.

Optional Gmail inbox research

Routine Gmail synchronization does not copy the whole inbox. An authorized CLI agent can separately request permission to search wider Gmail history. Before any search, the mailbox owner sees a browser approval page and can change or reject:

• the content level: relationship metadata only, subjects plus relationship data, or full message bodies;
• the history window: 30 days, six months, one year, or all available email; and
• the duration: one search, one hour, one day, or until revoked.

Attachments are excluded. The approved search is read-only and cannot send, delete, archive, label, or move Gmail messages. Search results are returned to the requesting CLI installation and are not automatically written into CRM records. SmallCRM records the grant and its usage, not a second persistent copy of every search result. An agent may deliberately create or update CRM records from selected findings using normal SmallCRM commands, in which case those records become ordinary workspace data.

User-chosen coding agents and model providers

SmallCRM provides a CLI and permission system that a user may operate through a coding agent. SmallCRM does not select, operate, train, or supervise the external agent or the AI/model service behind it.

When SmallCRM returns CRM or approved mailbox data to an authorized CLI installation, that data reaches the process running the CLI. If the process uses Codex, Claude, another hosted model, an agent platform, plugins, tools, logs, or telemetry, those external services may also receive or retain the data under the user's arrangement with them. Their terms, privacy settings, retention controls, and training policies apply independently. SmallCRM cannot control what those services do after data has been provided at the user's direction.

The user controls which agent installation is authorized and, for Gmail research, the content, history, and duration of each grant. Users should approve full-content or long-lived access only when they trust the agent and model provider and have the right to disclose the relevant email data. SmallCRM remains responsible for operating its own service, enforcing the approved boundary, protecting credentials, and meeting obligations that apply to SmallCRM.

Public forms

SmallCRM public forms let a static HTML page submit fields to a write-only endpoint under:

https://smallcrm.org/w/<workspace>/f/<form-public-id>

Anyone who has the form endpoint URL can submit to it. The endpoint does not require a SmallCRM login and does not expose existing workspace records.

Form submissions are limited in size, must use configured collection prefixes such as prospects.email, and cannot set reserved SmallCRM metadata fields such as id, timestamps, or scrm_* fields. Accepted submissions create records in the configured workspace collections and write event-log entries.

The person or organisation embedding the form is responsible for telling submitters what data is being collected and why.

Inbound webhooks

SmallCRM inbound webhooks let external services send JSON or form-encoded events to a write-only endpoint under:

https://smallcrm.org/w/<workspace>/wh/<webhook-public-id>

Anyone who has the webhook endpoint URL can send a delivery. The endpoint does not expose existing workspace records.

Webhook configs decide which payload fields are mapped into records, which fields are used for matching, and which trusted server-owned metadata is applied. Unmapped payload fields are not intentionally stored, but mapped values, match values that become record fields, before/after record data, request context, and event metadata may be stored in the workspace event log.

SmallCRM webhooks currently do not provide provider-specific signature verification. Do not use them for high-risk financial, legal, medical, security, or regulated workflows unless you have separately agreed production terms and controls with us.

Event logs

SmallCRM keeps a workspace event log so humans and agents can understand how state changed.

Event entries may include:

• Method, source, action, collection, record id, actor, reason, and user/agent-supplied metadata.
• Request context such as URL, user agent, and remote address.
• Changed fields.
• Before and after record data for mutations.
• Query/read details for logged reads.

Because mutation events can include before/after record data, the event log may contain the same personal or confidential information as the records themselves.

What we do not use

SmallCRM does not currently use:

• Third-party analytics scripts.
• Advertising trackers.
• Device fingerprinting.
• Payment processing.
• User-content training for AI models.

We do not read arbitrary files from your machine. The CLI sends only the files and data you pass to commands, plus ordinary request metadata needed to operate the service.

Third parties

SmallCRM uses a small number of third parties as part of normal operation:

• Hosting, domain, network, and infrastructure providers that deliver smallcrm.org.
• npm, when the installer resolves and downloads the published smallcrm CLI package.
• Resend, when SmallCRM sends passwordless login or invitation email, or when a workspace connects Resend for CRM email.
• Google, when you use Google sign-in or connect Gmail. Google sign-in and Gmail access are separate authorizations.
• Microsoft, when you connect Outlook.
• Google Fonts on the public marketing, auth, and legal pages.
• External websites you click from records or pages, including links and mailto: links rendered from CRM data.
• External services that you configure to send webhook deliveries.
• The coding-agent, model, plugin, tool, or telemetry providers you choose to run around the SmallCRM CLI. SmallCRM does not contract with those providers on your behalf merely because their software invokes scrm.

Those providers may receive ordinary network metadata such as IP address, user agent, requested URL, and time of request. Email providers receive the message and mailbox data needed for the capability you authorize. User-chosen agent/model providers may receive data returned to the CLI as described above.

SmallCRM's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including its Limited Use requirements. Google user data is used only to provide the visible SmallCRM email features the user authorizes; it is not sold, used for advertising, or used to train general AI models by SmallCRM.

Retention and deletion

Workspace data is retained while the workspace exists. Session records expire after 30 days unless renewed by logging in again, and logout revokes the current session. Gmail research grants expire according to the period approved by the mailbox owner or remain active until revoked. Disconnecting an email provider stops future access, while normalized CRM messages and threads remain workspace records until they are deleted with the workspace or through an available record-deletion path.

SmallCRM is an early hosted prototype and does not yet provide self-service account or workspace deletion in the app. Contact us if you need account or workspace data deleted. We may retain limited records where required for security, abuse prevention, legal obligations, or dispute handling.

Do not treat SmallCRM as your only backup for important data. Unless we separately agree otherwise in writing, SmallCRM does not provide a backup, disaster recovery, uptime, or data-retention guarantee.

Reporting issues

If this page does not match what SmallCRM does, that is a bug. Please report it.

• Contact: hi@sdocs.dev