1. About this notice
This Privacy Notice explains how HoneyNotify handles personal information when people visit our public website, create or use a HoneyNotify account, use the dashboard, API or SDK services, receive support, manage a subscription, or interact with operational communications. It also explains the important distinction between information HoneyNotify controls for its own business and information it processes on behalf of a customer.
In this notice, “personal information” and “personal data” mean information relating to an identified or identifiable person. A device token, browser push subscription, external user identifier, IP address, or combination of technical attributes may be personal data even when it does not contain a person's name. “Customer” means the person or organisation that has a HoneyNotify workspace. “Recipient” means a person whose device, browser, activity, or identifier is processed because a customer uses HoneyNotify to communicate with them.
This notice covers the HoneyNotify public website, account and organisation administration, hosted dashboard, REST API, client SDK interactions, push-delivery infrastructure, support, billing, service communications, and related security and operational processes. A third-party website, application, push provider, or customer property has its own privacy practices. Following a link away from HoneyNotify or receiving a notification from a customer does not make HoneyNotify responsible for that third party's privacy notice.
HoneyNotify is designed as a business-facing push-notification platform. The identity of the HoneyNotify contracting operator is provided in the applicable account, order, invoice, or other contractual record. Questions about that identity or this notice can be raised using the support contact available in the dashboard.
2. When HoneyNotify is controller and processor
HoneyNotify as controller
HoneyNotify acts as a controller when we decide why and how to process information for our own purposes. This normally includes website and dashboard visitors, prospective and current customer contacts, account users, billing contacts, people asking for support, and information needed to protect, administer, and improve the service. It includes decisions about account authentication, fraud and abuse prevention, billing records, security logs, product operations, and legal compliance.
HoneyNotify as processor
When a customer uses HoneyNotify to register devices, associate external user identifiers, build audiences, create messages, run journeys, or collect engagement events, the customer ordinarily determines the purpose and essential means of that processing. The customer is the controller and HoneyNotify acts as its processor or service provider. We process that customer data to provide the service, follow documented instructions, protect the platform, and meet applicable legal duties. The Data Processing Addendum, where applicable, provides additional processor terms.
The customer's responsibilities
Customers must provide recipients with their own clear privacy information and establish a lawful basis for collecting device information, assigning identities or attributes, tracking events, and sending notifications. They decide what message content, tags, aliases, custom properties, event metadata, and journey logic to submit. They are responsible for data accuracy, consent and permission management, opt-outs, age-related rules, and responding to recipient requests. HoneyNotify does not decide why a particular customer contacts a particular recipient.
If a notification or data request concerns a customer's app or website, the recipient should contact that customer first. HoneyNotify cannot ordinarily identify the relevant business purpose, change a customer's underlying records outside the service, or authenticate a recipient on the customer's behalf. We will support verified customer instructions as required by contract and data-protection law.
3. Information we process
Account and organisation information
We process email addresses, organisation names, team membership, assigned roles, account status, and timestamps such as account creation and last login. We process password hashes rather than plain-text passwords. If multi-factor authentication is enabled, we process the configuration and recovery information needed to provide it. We also record acceptance of applicable terms and privacy information.
Team owners and administrators may invite other users and assign access roles. The inviting customer is responsible for having authority to provide a team member's business email address. Organisation owners and administrators can see information about their own team and activity within the workspace.
Billing and commercial information
We process the selected plan, subscription state, billing period, usage measurements, customer and subscription references, invoice or transaction references, and related business correspondence. Stripe provides hosted checkout and customer-portal services for paid subscriptions. Payment-card entry and storage are handled by Stripe; HoneyNotify does not need to receive or store the full card number or card security code. Stripe may separately act as a controller for parts of its fraud prevention, compliance, and payment-network activity under its own privacy information.
Application configuration and credentials
Customers provide application names and settings, platform configuration, frequency caps, retention choices, webhook endpoints, and credentials required to connect with Apple Push Notification service (APNs), Firebase Cloud Messaging (FCM), or Web Push. Provider credentials are encrypted at rest. API keys are scoped to permissions and stored in hashed form after issue, although key prefixes and operational metadata may remain visible so customers can identify and revoke keys.
Recipient, device, and identity information
Depending on the customer's integration, we process push tokens, browser push-subscription endpoints and cryptographic keys, HoneyNotify device identifiers, imported provider identifiers, platform, app version, operating-system version, device model, locale, timezone, enabled or invalidated status, registration and activity timestamps, and delivery capability. A customer may also submit an external user identifier, aliases, tags, and other properties used to connect devices to its own user records and create audiences.
When a customer imports supported OneSignal data, HoneyNotify may process the exported Subscription ID or legacy Player ID, APNs or FCM token, external user ID, tags, app and operating-system details, model, locale, and timezone. Imported tokens are used for delivery and later device matching but are not exposed through normal dashboard or API responses.
Messages, audiences, and automation
We process notification titles and bodies, images and links, custom data payloads, localisation variants, sounds, badges, action definitions, templates, segment rules, schedules, target types, priority, collapse identifiers, and journey definitions. We also maintain message and audience snapshots needed to explain what was sent, to whom the customer intended it to be sent, and which rules applied at that time.
Delivery, event, and analytics information
We process delivery attempts, queue and provider responses, success or failure states, invalid-token signals, timestamps, error categories, notification receipts, opens, clicks, dismissals, actions, custom events, outcome events, attribution, and aggregated analytics. Custom-event names and metadata are chosen by the customer and may contain personal information if the customer places it there.
Technical, website, and security information
When a person or system connects to HoneyNotify, servers and security controls may process IP address, request time, requested route, HTTP method and status, browser or client type, operating system, referrer, request ID, app or organisation context, API-key identifier, rate-limit activity, error details, and diagnostic information. Audit records may identify the account user, action, affected resource, time, and relevant metadata. This information helps authenticate requests, troubleshoot faults, enforce tenant boundaries, and detect abuse.
Support and communications
We process the content and metadata of support requests, service enquiries, security reports, and other communications, including attachments a person chooses to provide. We may connect a support conversation to account, request, audit, or error information when necessary to investigate. Customers should redact secrets and unnecessary recipient data before sending diagnostic material.
4. Where information comes from
We obtain information directly from account users when they register, configure a workspace, contact support, or manage billing. We receive customer data through customer-controlled API requests, dashboard actions, SDK integrations, CSV imports, webhook configuration, and files or instructions submitted for support.
Client SDKs and customer applications send device registration, identity, token-lifecycle, and event information according to the customer's implementation. APNs, FCM, browser push services, and related infrastructure return routing, acceptance, rejection, and invalidation information. Stripe returns subscription and transaction status required to administer a paid plan. Security, hosting, database, and network systems generate operational records as the service runs.
We may receive information from an organisation owner or administrator about another authorised user, from a customer about its recipients, or from professional advisers and public authorities where relevant to a legal or security matter. We do not obtain recipients' names or contact details merely because HoneyNotify can deliver a push notification; any direct identity fields arise from the customer's chosen integration.
5. Purposes and legal bases
Providing and administering the service
We use account, configuration, device, message, event, and operational information to create workspaces, authenticate users and API clients, register destinations, resolve audiences, schedule and deliver notifications, run journeys, provide analytics and exports, and respond to support. For customers and their authorised users, this is generally necessary to perform the service contract or take requested steps before entering it. Customer recipient data is ordinarily processed on the customer's documented instructions under the DPA.
Security, reliability, and abuse prevention
We use access, request, audit, provider, and diagnostic information to protect accounts and tenants, apply rate and plan limits, identify malicious or unlawful activity, investigate incidents, restore service, and preserve evidence. Our legal basis is normally our legitimate interest, and the shared interests of customers and recipients, in running a safe and dependable platform. Some processing may also be necessary to comply with law or establish, exercise, or defend legal claims.
Billing and customer management
We measure plan usage, initiate checkout and customer-portal sessions, reconcile subscription events, manage account entitlements, issue or retain commercial records, and handle payment questions. This is necessary to perform the subscription agreement and to meet tax, accounting, and fraud-prevention obligations. Where business contact information is used to manage the relationship, we may rely on legitimate interests.
Service communications and support
We use contact details to send invitations, password resets, authentication or security alerts, receipts, changes affecting the service, support responses, and other communications needed to operate the account. These are not optional marketing messages. We may also send relevant product information to business contacts where permitted, relying on consent when required or legitimate interests where appropriate. Any marketing message will provide a way to opt out, while essential account and security notices may continue.
Product maintenance and improvement
We analyse service usage, errors, performance, feature adoption, and aggregated or de-identified trends to troubleshoot, plan capacity, understand whether features work, and improve documentation and product design. We aim to use the minimum information reasonably needed and, where practical, use aggregated or de-identified results. We do not use a customer's recipient data to market directly to those recipients.
Legal and corporate purposes
We may process information to comply with valid legal process, tax and accounting duties, regulatory enquiries, sanctions or fraud checks, and contractual enforcement; to protect rights, safety, and property; and to manage a financing, reorganisation, acquisition, or sale. The basis may be a legal obligation, legitimate interests, or the establishment and defence of legal claims, depending on the circumstances.
Where we rely on legitimate interests, we consider the purpose, necessity, and likely impact on individuals. A person may object to relevant processing as described below. Where processing is based on consent, consent may be withdrawn without affecting processing already carried out lawfully. If required information is not provided, we may be unable to open an account, provide a requested feature, complete billing, or respond effectively.
6. How push-notification processing works
A customer's app or website first obtains permission from the recipient where the platform requires it and receives an APNs token, FCM token, or Web Push subscription. The customer's SDK integration registers that destination with HoneyNotify using a restricted public client key. The customer may associate the device with its own external user identifier and selected attributes. Secret notification-send keys remain on the customer's trusted server.
When the customer creates a notification, HoneyNotify validates the request, resolves the instructed target, records an immutable content and audience snapshot, and queues delivery. Delivery workers send the necessary token, message payload, and provider configuration to APNs, FCM, or the relevant browser push service. Those providers and the recipient's operating system or browser determine final routing and display. A response accepted by HoneyNotify or a push provider does not prove that a device was online, displayed the message, or that a person read it.
The customer's app or website may report received, delivered, opened, clicked, dismissed, action, custom, and outcome events. HoneyNotify records those events and makes them available to the customer in recipient history, analytics, webhooks, journeys, or exports. The customer decides which optional custom events and metadata to send and must tell recipients about that collection when required.
Recipients can normally control notifications through the customer's app and their operating-system or browser settings. Removing permission can prevent future display but may not immediately delete historical delivery or account records. Customers can disable or delete recipients through supported service controls. Invalid provider tokens are disabled and later removed according to retention settings.
Customers should not place passwords, authentication secrets, payment data, government identifiers, medical details, precise location, or other sensitive material in notification bodies, links, tags, or event metadata unless they have established that doing so is lawful, necessary, appropriately protected, and supported by their HoneyNotify agreement. Lock-screen notifications may be visible to people other than the intended recipient.
7. Cookies, local storage, and external resources
The authenticated dashboard uses a session cookie to keep a user signed in and protect account interactions. It is configured with security protections including HttpOnly, Secure in production, and SameSite controls. Authentication, security, load-balancing, or preference mechanisms may also use cookies or similar browser storage where needed to provide the requested service.
The public website currently does not deliberately use advertising cookies or behavioural advertising trackers. Public pages request font files from Google Fonts, which means the visitor's browser connects to Google and supplies ordinary network information such as IP address and user-agent details. Links to documentation, status, customer applications, and other third-party sites are governed by those sites' practices.
A customer that embeds a HoneyNotify SDK in its own app or website controls the surrounding property and its consent interface. Browser push subscriptions, service-worker state, and locally stored HoneyNotify device identifiers support notification functionality; they are not used by HoneyNotify to follow recipients across unrelated customers. The customer must provide any cookie or similar-technology notice required for its implementation.
Browser settings can delete or block cookies and site data, but blocking strictly necessary storage may prevent login, Web Push, preferences, or other requested features from working. HoneyNotify does not currently treat a browser “Do Not Track” signal as an authenticated deletion or objection request because there is no consistent technical standard for applying it to account and processor data.
8. Who receives information
We disclose personal information only where it is reasonably needed for the purposes in this notice, where the customer instructs us, or where law permits or requires it. Recipient data is not sold, and HoneyNotify does not use it to build advertising profiles for unrelated businesses.
Customer and authorised users
Information in a workspace is available to the customer and its authorised team members according to their roles. A customer may retrieve information through the dashboard, API, webhooks, or exports and may direct it to its own systems and providers. HoneyNotify is not responsible for the customer's subsequent independent processing.
Push and browser providers
APNs, FCM, and browser push services receive the routing token or subscription and message payload needed to attempt delivery. Apple, Google, browser vendors, operating-system providers, and network operators may process this information under their own terms and privacy documentation. Customers must configure the correct provider project, application, and credentials.
Payment, infrastructure, and operational providers
Stripe processes hosted checkout, billing-portal, payment, subscription, and fraud-related information. Hosting, database, network, backup, monitoring, email, security, and support providers may process limited information to run and protect HoneyNotify. Subprocessors handling customer personal data are subject to contractual data-protection and confidentiality obligations appropriate to their role.
Professional advisers, authorities, and transactions
Lawyers, accountants, insurers, auditors, and other professional advisers may receive information where necessary and subject to professional or contractual duties. We may disclose information to a court, regulator, law-enforcement body, emergency service, or other party when we reasonably believe disclosure is legally required or necessary to protect rights, safety, property, the service, customers, or the public. We assess requests and seek to limit disclosure to what is properly required.
If HoneyNotify or the relevant business is involved in due diligence, financing, reorganisation, merger, acquisition, or sale of assets, information may be disclosed under confidentiality safeguards and transferred as part of that transaction. Any successor remains subject to applicable privacy law and the commitments that continue to bind the information.
9. International transfers
HoneyNotify and its providers may process information in countries different from the country where the customer, account user, or recipient lives. Push delivery is inherently international: a customer may target a recipient abroad, and Apple, Google, browser, network, or infrastructure systems may route data through multiple locations.
Where UK or EEA data-protection law restricts a transfer, HoneyNotify uses an available lawful mechanism appropriate to the transfer. This may include a UK adequacy regulation or EU adequacy decision, the EU Standard Contractual Clauses, the UK International Data Transfer Addendum or Agreement, or another mechanism recognised by applicable law. We may supplement contractual safeguards with encryption, access restrictions, transfer assessments, and data minimisation where appropriate.
Customers are responsible for assessing transfers they initiate through their choice of recipients, push-provider accounts, webhook destinations, integrations, and submitted content. The applicable DPA provides further terms for restricted transfers of customer personal data. A customer can ask support for information reasonably available about applicable safeguards.
10. Retention, exports, and deletion
We keep personal information only for as long as reasonably necessary for the purpose for which it was collected, the customer's configured retention settings and instructions, account security and continuity, contractual commitments, and legal requirements. Relevant considerations include the amount and sensitivity of the information, the risk of harm, operational dependencies, limitation periods, and tax, accounting, dispute, and regulatory duties.
Service data and customer controls
Customers can configure retention periods for event detail, delivery attempts, and disabled-device information within supported settings. Scheduled retention jobs remove information after the applicable period. Deleting a user through the API disables associated devices and removes the subscriber record; invalid or unsubscribed devices may remain temporarily so the service can prevent delivery, preserve operational integrity, and complete configured cleanup.
Owners and administrators can download a company data export from privacy controls. That direct privacy export excludes credentials and token secrets. API-created CSV export files for audience, messages, recipients, events, or audit data expire after 24 hours and are removed by retention processing.
Account deletion
An organisation owner can schedule deletion of the company and its service data. HoneyNotify applies a seven-day safety period during which the request can be cancelled. Once processed, the organisation and records deleted through its database relationships cannot be restored through the normal service. Customers should export required information before the safety period ends.
Operational and legal records
Account, security, audit, billing, tax, support, fraud-prevention, dispute, and legal records may remain longer where necessary for legitimate operations or required by law. We may retain a minimal record of a request and its outcome to demonstrate compliance. Aggregated or irreversibly de-identified information may be retained because it no longer identifies a person.
Backups
Encrypted backups are isolated from ordinary use and expire on a separate backup cycle. Information deleted from the live service may therefore remain temporarily in protected backups. We do not restore deleted information to ordinary use except where necessary for disaster recovery, and restored data remains subject to the applicable deletion and retention process.
11. Security and incident response
HoneyNotify uses technical and organisational measures intended to preserve confidentiality, integrity, and availability. These include tenant-aware access checks; role-based dashboard access; scoped API keys; hashing of passwords, API keys, and reset tokens; encrypted provider credentials; transport encryption; multi-factor authentication support; request and rate controls; audit logging; private service networking; encrypted backups; restore testing; monitoring; and incident-response and vulnerability-management processes.
Access is limited according to operational need, and personnel and providers with access are expected to protect confidentiality. HoneyNotify reviews relevant activity and can revoke credentials, disable destinations, throttle traffic, or suspend access to contain risk. If a personal-data breach affects customer data, we will notify affected controllers as required by the DPA and applicable law and provide information reasonably available to support their assessment.
No network, storage method, or software service can guarantee absolute security. Customers must use unique passwords and MFA where available, restrict team roles, rotate and scope keys, keep secret keys out of apps and public repositories, validate identity tokens, secure webhook destinations, maintain their own backups where needed, and promptly report suspected compromise. Recipients and customers should never send passwords, private keys, API secrets, raw provider credentials, or unnecessary device tokens in an initial support message.
12. Your choices and data-protection rights
Depending on where you live and the circumstances, you may have rights to be informed; request access to personal data; correct inaccurate or incomplete data; request deletion; restrict processing; receive certain data in a portable format; object to processing based on legitimate interests or direct marketing; and withdraw consent. You may also have the right to complain to a supervisory authority and not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects.
HoneyNotify does not use account or recipient data to make solely automated decisions about individuals that have legal or similarly significant effects. Automated platform actions such as rate limiting, fraud signals, token invalidation, audience matching, journey branching, or temporary protective suspension are operational service functions. Customers remain responsible for any significant decisions they make using notification engagement or other exported data.
Requests about HoneyNotify-controlled information
For account, billing, website, or support information that HoneyNotify controls, submit a request through the support contact in the dashboard. Describe the account and right involved without including secrets. We may ask for information reasonably necessary to verify identity and authority, especially where a request concerns an organisation account. Authorised agents may need to provide evidence of authority.
Requests about a customer's recipient data
If the request concerns a notification, device, external user identifier, tag, event, or other data submitted by a HoneyNotify customer, contact that customer. The customer is best placed to identify the recipient, understand the purpose and lawful basis, and determine whether an exemption applies. HoneyNotify will provide the customer with reasonable assistance and act on authenticated instructions consistent with the DPA.
Rights are not absolute. We may decline or limit a request where the law permits, including where identity cannot be verified, the request would adversely affect another person's rights, information must be retained by law, or an applicable exemption protects security, confidential information, or legal claims. We will explain the relevant reason where required. We do not charge for ordinary requests, but the law may permit a reasonable fee or refusal for manifestly unfounded or excessive requests.
In the United Kingdom, concerns may be raised with the Information Commissioner's Office. Individuals elsewhere may contact their local data-protection authority. We encourage people to contact us or the relevant customer first so the issue can be understood and addressed.
13. Children and sensitive information
HoneyNotify accounts are intended for adults acting for themselves or an organisation and are not offered directly to children. We do not knowingly invite children to create HoneyNotify administrative accounts. If we learn that a child has provided account information without appropriate authority, we will take reasonable steps to close the account and delete or restrict the information as required.
A customer may operate an app or website used by children, but the customer must comply with all age-appropriate design, transparency, parental-consent, platform, and child-privacy rules that apply to it. The customer must not submit children's data unless its agreement permits the processing and it has completed any required assessment and obtained valid authorisation. HoneyNotify does not independently know a recipient's age unless a customer improperly or deliberately places age information in customer data.
Customers should not submit special-category or highly sensitive personal data—including health information, biometric identifiers, racial or ethnic origin, political opinions, religious beliefs, trade-union membership, sexual life or orientation, criminal-offence data, government identifiers, financial credentials, or precise location—unless processing is expressly permitted, necessary, and protected by appropriate legal and technical safeguards. Notification content may appear on a locked or shared device, so even lawful processing may be unsuitable for a visible push message.
14. Contact, complaints, and changes
Contact HoneyNotify through the support details available in the dashboard for privacy questions, rights requests, complaints, or information about the contracting operator. If you cannot access the dashboard, use the public support route made available on the HoneyNotify website or application. Include enough information to locate the relevant account but do not include API keys, passwords, device tokens, identity-signing keys, provider credentials, or other secrets.
We may update this notice when the service, legal requirements, providers, or processing practices change. The effective date at the top identifies the current version. For a material change, we will provide reasonable notice through the website, dashboard, account email, or another appropriate service channel before it takes effect where required. Earlier versions may be requested where they remain available.
If any translated version of this notice is provided, it is for convenience unless applicable law requires otherwise. The English version governs to the extent legally permitted if there is a conflict.