Obsedia Email Security Overview
Version 1.1 · Last updated: 22 October 2026 · Effective from first publication
This overview describes the security approach for Obsedia Email, provided by Genius Nutrition SRL, trading as OBSEDIA. It complements the DPA and Privacy Policy; it is not a certification, penetration-test report or service-level agreement.
1. Application access and store separation
The embedded application uses verified Shopify authentication. The authenticated installation determines the store context; a user-supplied store identifier does not itself grant access. Application operations scope customer, campaign, template and other merchant records to the relevant tenant. Credentials, API keys and integration secrets are held on the server rather than returned to the normal merchant interface.
Activity is checked against installation and privacy state. Uninstall, disconnected access, privacy cleanup and applicable service restrictions prevent new authorised work. Public media and recipient action endpoints have different access models from the authenticated merchant API; they are not private merchant dashboards.
2. Transmission, credentials and infrastructure
The public production application uses HTTPS. Requests to integrated providers use their protected API endpoints. The application encrypts stored Shopify authorisation tokens using authenticated encryption and protects signed actions and integration requests with appropriate verification and server-held secrets.
Infrastructure-level storage encryption, network controls, backup protection and key management are also part of the hosting providers' responsibility under their applicable service and data-processing terms. Encryption of an integration credential is not a statement that every database column has separate application-level encryption. Transport security for an external recipient's mail server depends on the email delivery path and that server's capabilities; ordinary marketing email is not end-to-end encrypted confidential messaging.
3. Webhooks, privacy requests and eligibility
Shopify and delivery-feedback requests are verified before trusted processing. Privacy requests use durable state and identity checks to avoid deletion of the wrong store or a newer installation. Customer erasure suppresses affected sending when an in-flight or uncertain outcome needs reconciliation, rather than silently treating an incomplete operation as finished.
Sending also checks the relevant subscription, suppression, sender, billing and application readiness. Hard bounces and complaints feed suppression. Required unsubscribe functions and company information must remain effective even when the merchant changes their visual presentation.
4. Access records and minimisation
The authenticated merchant API records user/store identifiers, route category, action, outcome and timestamps. Its journal avoids full bodies, contact lists, raw authentication headers and arbitrary URL query contents. This application journal is not represented as a complete recording of every administrator terminal session, database query or infrastructure-provider action.
Personnel access is governed by least privilege, confidentiality and documented business need. Administrative accounts must be individually attributable, protected by appropriate strong authentication and promptly reviewed or removed when access is no longer required. Support should use the minimum information needed to resolve the issue. Secrets and customer data must not be copied into public issue trackers, demonstrations or ordinary collaboration materials.
Operational monitoring uses Sentry for allowlisted issue categories and worker availability check-ins. The integration sends aggregate operational counts, timestamps, environment and release identifiers; automatic tracing, session replay, chat content, recipient lists, request bodies, authentication headers and raw exception payloads are not enabled in this integration. Monitoring supports incident detection but does not prove that every event is detected or that every administrative action is audited.
5. AI and media
Creative AI calls use the information needed for the requested operation. Merchants must not paste recipient lists or sensitive records into prompts. We do not authorise general-purpose model training on merchant customer data and do not promise zero provider retention or exclusively European AI processing without a specific verified arrangement.
Email images are designed to be fetched by recipients' email clients and may therefore be accessible through public asset URLs. Do not upload secret information or images of personal documents. Tenant cleanup removes origin assets under its controlled namespace; independently cached, forwarded or downloaded copies remain outside our direct control.
6. Availability, backups and recovery
The service uses persistent records for queued work, delivery evidence and reconciliation. Duplicate prevention and uncertain-outcome protection take priority over speculative retries. Shared limits may pause or delay activity to protect accuracy and other merchants.
Backups and recovery procedures are maintained separately from ordinary application deletion. Restored data must be isolated, access controlled and checked against deletion and suppression instructions before processing resumes. The existence of a backup is not a representation that every disaster scenario has been tested or that a particular recovery time is guaranteed. No numerical recovery-time, recovery-point or availability SLA applies unless expressly agreed in writing.
7. Incident response and disclosure
Suspected incidents are triaged, contained, investigated and documented according to their risk. Where we become aware of a personal-data breach involving data we process for a merchant, we notify that merchant without undue delay and provide available information and reasonable assistance. Initial notice must not wait for a complete forensic report; details may be updated in phases.
The merchant ordinarily determines its notifications to customers and regulators, without limiting OBSEDIA's own legal duties. Ordinary service errors or blocked attempts that do not involve a personal-data breach are handled according to their actual impact; not every failed request is described as a breach.
Report a suspected security issue to support@obsedia.ai and identify it as a security report. For a personal-data issue, also use privacy@obsedia.ai. Share reproduction details privately, minimise personal data and do not access other merchants' information, disrupt the service or publish live credentials. No unauthorised testing permission or automatic bug-bounty payment is granted by this notice.
8. Merchant responsibilities and limits
Merchants must protect their Shopify accounts, review staff permissions, use lawful audiences, maintain sender-domain records, review AI output and avoid disclosing secrets in creative material. They should promptly report suspected compromise and follow requested containment steps.
No control eliminates all risk. OBSEDIA does not claim an independent ISO 27001, SOC 2 or HIPAA certification because a supplier has one. Information about applicable measures is available through the DPA's information and audit process, subject to reasonable confidentiality and security safeguards.