Last Updated: 2026-10-01
Journalit is designed with privacy as a core principle. Your trading data stays in your Obsidian vault. Update notifications use public release metadata by default, while account, import, synchronization, and exchange-rate features remain optional as described below.
The core functionality of Journalit operates entirely locally within your Obsidian vault:
- Trade Notes: All manually created trade entries are stored only in your vault
- Daily/Weekly/Monthly Reviews: Review notes remain local
- Account Data: Account configurations stored in plugin settings
- Prop Challenges: Challenge phases, rules, payouts, and personal firm profiles stay in your vault and plugin settings
- Custom Fields & Settings: Customization data stays local except custom field definitions/options sent when you explicitly use Trade Import analysis or preview generation
- Analytics & Charts: Calculated locally from your vault data
Local journal content is not included in Trade Import requests unless it is in the file you select. Custom field definitions and options are sent as described below; the current Trade Import flow does not send local open-trade context.
Location: .obsidian/plugins/journalit/data.json
Contains your preferences: currency, display name, date formats, custom fields, dashboard layout, and sync mappings. Most settings remain local. Network-backed features transmit only the settings and identifiers explicitly described in their sections below.
Authentication credentials are stored locally using Obsidian's SecretStorage API. Legacy plaintext settings from older plugin versions are migrated into SecretStorage when possible and then cleared from plugin settings.
When you authenticate, the following is stored locally:
- JWT access token
- User ID and email
- Subscription tier
Security: SecretStorage is managed by Obsidian and the host platform. Journalit does not store authentication tokens in notes, trade files, or synced vault content.
Locations:
${app.vault.configDir}/plugins/journalit/cache/${app.vault.configDir}/plugins/journalit/indexes/
Query results and indexes for performance optimization. Stays local, never transmitted.
Journalit includes optional features that require network connectivity. Backend synchronization is disabled by default and requires explicit authentication.
When update notifications are enabled, Journalit checks its public GitHub manifest.json and matching release metadata at most once every 24 hours. The request is used only to compare the installed version with the newest compatible published version.
What is transmitted:
- A standard HTTPS request to public Journalit release files hosted by GitHub
- As with any direct HTTPS connection, GitHub receives standard connection information such as the requesting IP address
What is NOT transmitted:
- Vault content or file names
- Trading or account data
- Journalit authentication tokens, email addresses, or user IDs
- Device or vault identifiers
Control:
- Disable Show Update Notifications in Journalit notification settings to stop the check
When you choose to authenticate:
What is Transmitted:
- Your email address (to receive a 6-digit verification code)
- The verification code you enter (to complete authentication)
What is Returned:
- JWT token (42-day expiry)
- User ID and subscription status
What is NOT Transmitted:
- Device fingerprints or hardware identifiers
- Passwords (we use passwordless email verification)
When you enable MetaTrader 4 Trade Sync in Settings → Journalit → Trade Sync, the plugin:
What is Transmitted:
- Only automatically synced trades from your MetaTrader account
- Trade data: symbol, entry/exit times, prices, position size, P&L, commission, swap, fees
- Account information: MT4 account ID and display name
- Vault identifier: A SHA-256 hashed, non-reversible identifier for sync coordination
What is NOT Transmitted:
- Manual trades you create in Obsidian
- Trade notes or analysis you write
- Screenshots or attachments
- File contents or vault structure
Infrastructure:
- Backend Server (HTTPS encrypted)
- FTP Server (for MetaTrader report uploads)
Control:
- Requires explicit authentication via email verification
- Enable or disable the account in Settings → Journalit → Trade Sync
Trade Import uploads only the file you select to Journalit servers for the requested analysis or preview. Supported inputs include CSV, XLSX, XLS, HTML, and broker statements. The file may contain account identifiers, trade history, symbols, timestamps, prices, quantities, fees, balances, notes, and P&L. Requests include the plugin version, selected source/file type, sheet/header selection, timezone and custom field definitions/options; preview also includes the target account name, asset type, date/row-mode choices and column mappings. The current flow does not include local open trades or unrelated journal content.
The backend retains encrypted diagnostic bundles containing the uploaded file, original and effective requests, response and parser decision trace. Captures expire after one day for free accounts or 14 days for Pro accounts; stored previews expire after seven days. Expired captures and previews are swept every 15 minutes. Support access is authorized and audited. Canonical trades created by a confirmed import are retained separately and are not removed by preview expiry. Server-side operational metadata includes request outcomes, parser versions and diagnostic codes; raw file contents do not belong in ordinary logs or metrics.
Compatibility errors and recovery guidance are returned through the same user-requested analyse/preview response and displayed locally. Trade Import does not send separate analytics events, background failure reports or additional journal content when displaying those errors. Changing source requires your selection; the file is then reanalysed with source-dependent options reset. An incompatible result is not automatically retried.
When optional AI mapping suggestions are enabled for a supported source, the backend also sends column headers and a limited sample of rows to its AI model provider to suggest column matches. Disable AI mapping to avoid this additional processing. Rithmic's native adapter does not support or request AI mapping.
When you confirm an import, the backend commits the selected preview items and returns the canonical post-commit trade projection used to create or update local Obsidian trade notes. The plugin then sends a projection acknowledgement containing backend trade IDs, versions, local file paths for successfully written notes, and success/failure status so the backend can track whether the local projection completed.
Control:
- Requires sign-in before upload. Free accounts can analyse and preview within rate/storage limits; committing and projecting imports requires Pro.
- Upload processing is disclosed in the import view. There is no per-session acknowledgement requirement.
- Final note creation remains local in your Obsidian vault.
Tradovate authorization and connection lifecycle are handled on Journalit.co. Tradovate credentials and provider tokens are stored by the Journalit backend and are never returned to the plugin.
When you configure or run Tradovate Sync, the plugin transmits:
- The selected backend account records and initial-history boundaries
- A random vault identifier used for projection coordination
- The plugin version and random client-installation/operation identifiers
- Privacy-safe synchronization event codes, timestamps, and aggregate counts
- Projection acknowledgements containing canonical trade IDs, versions, local file paths for written notes, and success/failure codes
The anonymous client-installation identifier is stored in Obsidian's device-local browser storage rather than the vault settings file. Client diagnostic events do not contain note contents, frontmatter, account names, symbols, prices, quantities, P&L, raw exception messages, stack traces, response bodies, or Tradovate credentials/provider tokens. Diagnostic storage is used for synchronization support and is subject to limited backend retention and access controls.
The backend stores the connected Tradovate account configuration, normalized provider source data, canonical synchronized trades, synchronization jobs, reconciliation state, projection state, and privacy-safe diagnostics required to operate and support the feature.
cTrader authorization and connection lifecycle are handled on Journalit.co. Journalit requests read-only account access and cannot place, modify, or close cTrader orders. Access and refresh tokens are encrypted on the Journalit backend and are never returned to the website UI or plugin.
When you configure or run cTrader Sync, the plugin transmits:
- Selected backend account records and initial-history boundaries
- A random vault identifier used for projection coordination
- The plugin version and random client-installation/operation identifiers
- Projection acknowledgements containing canonical trade IDs, versions, local file paths for written notes, and success/failure codes
The backend stores connection-scoped account configuration and source provenance, normalized provider records, canonical synchronized trades, synchronization jobs, reconciliation state, projection state, and privacy-safe diagnostics required to operate and support the feature. Disconnecting removes the cTrader authorization but preserves existing cloud trades. Deleting cloud data removes provenance owned by that connection. Neither action deletes Obsidian notes.
Rithmic credentials are entered and managed on Journalit.co, not in the plugin. The selected Rithmic system, username, and password are sent over TLS to the Journalit backend, verified against Rithmic, and stored encrypted at rest. They are never returned to the browser or plugin and are deleted when you disconnect.
The plugin receives provider-neutral connection, account, trade-projection, and synchronization status records. It sends the local Journalit account assignment, a random vault identifier, a persistent random client-installation identifier stored in Obsidian's device-local browser storage, the plugin version, a random per-operation identifier, and projection acknowledgements needed to write and track trade notes in the current vault. Your note text, screenshots, reviews, and other local journal content are not sent as part of Rithmic synchronization.
When you are signed in, the plugin can download prop-firm profiles to prefill challenge rules. These are read-only requests: the plugin sends only standard request headers, your authentication token, and a cache validator (If-None-Match), never your challenge settings, accounts, trades, or vault data.
- Firm index (any signed-in user): a names-only list of supported firms, used to tell you when a firm you type has a profile available.
- Firm profiles (Pro): the rules, phases, and payout conditions for each supported firm challenge.
Both responses are cached in plugin settings so challenge setup works offline. You can always enter challenge rules by hand without downloading any profile, and nothing about your challenges is sent to Journalit servers.
When multi-currency conversion is needed, Journalit may request exchange rates from a third-party exchange-rate service:
What is Transmitted:
- Base currency code needed for the exchange-rate lookup
- Standard exchange-rate request parameters required to retrieve current rates
What is NOT Transmitted:
- Trade notes or journal text
- Vault contents or file structure
- Full trade history
- Authentication tokens for Journalit services
Purpose:
- Convert multi-currency P&L and analytics into your selected base currency
Control:
- This happens only when exchange-rate-backed conversion is needed for multi-currency calculations
- Cached rates are stored locally for performance and offline fallback
Upgrade prompts do not send client-side telemetry. Viewing a paywalled feature
sends no analytics or usage event; if you are signed in, the plugin still checks
your own subscription status so it knows what to show you, which is a functional
request listed under Network Endpoints below. Upgrade buttons open
journalit.co in your normal browser only when you click them, and the link
carries fixed campaign parameters:
What is Transmitted:
- Constant campaign parameters identifying that the link came from the plugin, which feature's paywall you clicked, and, when that feature was opened from a contextual entry point inside the plugin, which kind of entry point it was (for example the onboarding import path, or the one-time Trade Import suggestion in the new-trade form). The entry point is a fixed value, currently
pro_upgrade(a paywall you reached yourself),pro_upgrade_onboarding, orpro_upgrade_manual_trade_nudge; it is never a count, a date, or anything derived from your trades - Nothing else; the plugin sends no request of its own for attribution, and the parameters travel only because your browser opened the link
What is NOT Transmitted:
- Any generated, random, or per-installation identifier
- Your email, account ID, or authentication tokens
- Vault contents, trades, or usage of any other part of the plugin
- Whether, when, or how often an in-plugin suggestion was shown, or anything the plugin used locally to decide to show it (such as how many trades you entered by hand and on which days)
Purpose:
- Let us see, server-side, which paywalled features and which entry points lead people to upgrade, so we can improve them
Control:
- The only control is the click itself. Once an upgrade button is opened, the parameters have already been sent with that first request, so editing the address bar afterwards cannot withdraw them. Not clicking an upgrade button leaves nothing to record at all
- An entry-point marker is held in memory only and is a fixed word rather than an identifier. Setting it sends nothing. It is discarded by the first upgrade click on the feature it was set for, by closing that feature's screen, and by restarting Obsidian or the plugin. An upgrade click on a different feature leaves it untouched, because that click is not the flow the entry point started
- Seeing, dismissing, or following an in-plugin suggestion sends no suggestion or attribution data; attribution only travels with an upgrade link you click. Following a suggestion opens the feature normally, so that feature's usual functional requests (for example the subscription check described above) still happen. Whether a suggestion applies is decided entirely on your device, and the only record kept is an "already shown" flag in this vault's local plugin settings, which is never sent to Journalit
Once the link opens, the journalit.co website records the upgrade attempt and
signup origin on our servers, including the campaign parameters above, the page
you landed on, and the referring site. This is server-side, is described in
Server-Side Data Storage below, and is used for aggregate conversion
reporting only.
When backend integration is enabled, the plugin communicates with the following endpoints:
Authentication:
/auth/login- Request email verification code/auth/verify- Verify code and receive token/auth/validate- Validate existing token/api/v1/me/entitlements- Read your own subscription tier and feature entitlements
Sync Operations:
/api/v1/obsidian/register-vault- Initial vault registration/api/v1/sync/ftp- Trigger FTP synchronization/api/v1/trades- Fetch trade data from backend/api/v1/mt-accounts- MetaTrader account management/api/v1/obsidian/status- Check synchronization status/api/v1/ftp-users- FTP credential management/api/v1/trade-import/capabilities- Trade Import capabilities/api/v1/trade-import/analyse- Trade Import file analysis/api/v1/trade-import/preview- Trade Import canonical preview/api/v1/trade-import/{importId}/commit- Confirm selected Trade Import preview items/api/v1/trade-projections/accounts- List canonical account projection inventory/api/v1/trade-projections/missing- Retrieve missing or stale canonical projections/api/v1/trade-projections/ack- Acknowledge local canonical note projection status/api/v1/broker-connections/tradovate- Read Tradovate connection and account status/api/v1/broker-connections/tradovate/accounts- Configure synchronized accounts and history/api/v1/broker-connections/tradovate/sync- Start Tradovate discovery or synchronization/api/v1/broker-connections/tradovate/jobs/{jobId}- Read synchronization job status/api/v1/broker-connections/tradovate/client-diagnostics- Submit privacy-safe client synchronization diagnostics/api/v1/health- Backend health check
Prop Challenges:
/api/v1/prop-firm-profiles/firms- Read the names-only prop-firm index/api/v1/prop-firm-profiles- Read prop-firm challenge profiles (Pro)
All authenticated API requests use JWT tokens in the Authorization header.
When you use sync features, the backend stores:
- Email address
- Username (derived from email)
- Subscription tier and status
- Account creation timestamp
- Synced trades from MetaTrader (symbol, times, prices, P&L, fees)
- Canonical Trade Import records for confirmed imports, including imported trade identity, version, source broker/account metadata, execution details, status, and processing/projection state
- Canonical Tradovate synchronization records, normalized provider source entities, account selections, durable job history, reconciliation issues, and projection state
- MT account IDs and display names
- Processing history (which reports have been synced)
- Upgrade attempts started from an upgrade link: the campaign parameters listed above, the feature paywall involved, which in-plugin entry point (if any) opened it, the requested billing period, and timestamps for each step of the upgrade page
- Signup origin for accounts created from such a visit: landing page, referring site, and the same campaign parameters
- Used for aggregate conversion reporting; never used for advertising and never sold
- FTP login attempts (IP address, timestamp, success/failure)
- Used for security monitoring and abuse prevention
All user data is protected by PostgreSQL Row-Level Security (RLS). Each user can only access their own data.
- All network communications use HTTPS (TLS 1.2+)
- Authentication tokens stored locally using Obsidian SecretStorage
- FTP credentials stored locally using Obsidian SecretStorage
- Vault identifiers are randomly generated opaque values and do not contain the vault path or name
- FTP credentials: bcrypt hashed on server
- No plaintext passwords stored
- Stored indefinitely until you delete files or uninstall the plugin
- You have full control over local data
- Synced trades: Stored for sync functionality until account deletion
- Account data: Stored until account deletion
- FTP access logs: Retained for security purposes, older entries periodically cleaned
- Authentication codes: Expired codes deleted within 24 hours
Verification codes are sent via email service provider:
- Only your email address and verification code
- Used solely for authentication
- No Google Analytics
- No advertising networks or cross-site clickstream tracking
- Network-backed synchronization features may submit the narrow operational diagnostics disclosed above
- No advertising networks
- No data sold to third parties
- All your data is accessible in your Obsidian vault
- Backend synced data available via sync status in settings
- Local Data: Delete by removing the plugin or deleting files
- Backend Data: Contact contact@journalit.co to request complete account deletion
- Local data: Already in your vault as markdown files
- Backend data: Contact contact@journalit.co for data export
- MT5 Sync: Disable in Settings → Backend Integration
- Authentication: Log out to revoke token access
- You can use the plugin 100% offline with no network features
- Browsing history, or clickstream data beyond the upgrade-link attribution described above
- Hardware fingerprints or operating-system advertising identifiers
- Location data
- Trading account passwords or API keys
- Contents of your Obsidian vault
- Your manual trades or personal notes
- General usage analytics or behavioral telemetry from inside Obsidian, beyond the explicitly disclosed synchronization diagnostics and upgrade-link attribution
We will notify users of material changes to this privacy policy through:
- Plugin update notes
- Discord community announcements
- GitHub release notes
Privacy questions or concerns:
- Email: contact@journalit.co
- Discord: Join our server
This plugin adheres to:
- Obsidian Developer Policies
- Obsidian Plugin Guidelines
- GDPR principles (data minimization, purpose limitation, transparency)