1. Who is responsible
Nivora Relay is the product name. The legal person or organisation operating the Service has not been identified in the repository. That operator must be named here, with a working privacy contact, before this policy is published as the final notice.
2. Information the Service handles
- Account and workspace data: name, email address, password hash, verification status, pending email address, workspace name, account status, and creation/update details.
- Sign-in and security records: hashed session and CSRF secrets, session expiry/revocation and creation times, email-action token hashes and their purpose/expiry/use status, and OAuth state records. Session cookies are used for authentication; the CSRF cookie is readable by frontend JavaScript so it can be returned in a request header.
- Google and Facebook sign-in data: provider subject/identifier and email recorded for a connected identity. Google sign-in reads identity claims including name and verified email; Facebook Login requests basic profile and email. A Facebook email is separately verified by Nivora Relay.
- Instagram and workspace content: connected account ID, username, account type, granted scopes, connection status and timestamps, and an encrypted access token. The Service also handles resource names, URLs and descriptions; automation names, keyword, reply text and status; and delivery IDs, status, attempt counts, error details, comment identifiers and timestamps.
- Comment information: Instagram webhook handling receives comment text and IDs and may receive account/user identifiers and usernames. These fields are used to match configured keywords and attempt delivery. The current webhook code also writes received event details to application logs; production log contents and retention are not configured here.
- Technical/rate-limit data: the rate limiter uses the request IP address and a hashed account/action identifier to enforce request limits. The deployment may create additional server, database, or provider logs; their contents and retention depend on infrastructure that has not been identified.
3. Purposes
The code uses this information to create and secure accounts; verify email; authenticate users; manage workspaces, resources, and automations; connect social accounts; match comment keywords; attempt private replies; show delivery activity; enforce request limits; and investigate operational errors. The operator must document the applicable legal basis and provide any required standalone notice before launch. We will not sell personal data for unauthorised purposes or use it for unrelated advertising. We will limit processing to disclosed service, security, and legal purposes.
4. Sharing and service providers
When you choose to use connected features, information is exchanged with the relevant platforms:
- Meta / Instagram: OAuth login and Instagram connection send authorisation requests to Meta. Connected Instagram account data and access tokens are used to identify accounts, receive configured webhook events, and request private replies. Commenters’ data may be handled when Meta sends event payloads.
- Google: Google receives the OAuth request when you choose Google sign-in and returns identity claims to the backend.
- Email delivery: an SMTP provider selected by the operator receives the recipient address and verification, reset, or email-change message. Local development uses Mailpit and does not deliver externally.
- Infrastructure: PostgreSQL stores application records and Redis stores expiring rate-limit counters. The production hosting, database, Redis, and SMTP vendors and their processing locations are not identified in the repository and must be disclosed by the operator.
The codebase contains no analytics or advertising SDK integration. We do not claim that hosting-provider logs or third-party platform processing are absent.
5. Cookies and similar technology
The application uses an HttpOnly session cookie, a separate CSRF cookie, and short-lived OAuth state cookies. They support login, request protection, and OAuth state validation. The frontend does not store session tokens in local storage. No analytics cookie is configured in the frontend code inspected for this draft.
6. Storage and security
Passwords are hashed with bcrypt. Server session secrets, email action tokens, and OAuth state are stored as digests. Instagram access tokens are encrypted in the database using a Fernet key. These controls do not establish that every database, backup, log, network connection, or third-party system is encrypted or secure. The operator must document hosting safeguards, access control, backups, incident response, and the encryption-key management process.
7. Retention and deletion
There is no complete retention schedule in the repository. Session lifetime defaults to 14 days; email verification links expire after 24 hours and password-reset links after 30 minutes, but expired/revoked database rows are not automatically purged by the code shown. Delivery, workspace, automation, and connected-account retention periods are not defined.
Account deletion currently anonymises the user’s name and email and revokes sessions and sign-in identities, while retaining workspace and delivery history. The deletion route does not remove the workspace’s Instagram account record or its encrypted access token. A separate Instagram disconnect clears that account token. This behavior needs a deletion policy and implementation review before users are promised complete erasure.
8. Your choices and requests
In the current app, you can edit your name, request an email change, change your password, disconnect a listed Instagram account, revoke sessions, and request account deletion. There is no working contact API, published privacy email, or process for other access, correction, objection, grievance, or deletion requests. Configure and test those channels before launch.
9. India legal framework
The Digital Personal Data Protection Act, 2023 and Digital Personal Data Protection Rules, 2025 are relevant to review for an India-facing service. The Government’s commencement notification phases provisions: some commenced on publication, with further groups scheduled one year and eighteen months after 13 November 2025. The applicable duties therefore depend on the specific provision and date; this notice does not claim that Nivora Relay complies with the Act or Rules. Obtain advice on the operator’s role, applicable provisions, notices/consent, user rights, grievance handling, children’s data, processors, and commencement dates.
See the official DPDP Act, 2023, DPDP Rules, 2025, and commencement notification.
CERT-In’s directions issued under section 70B of the Information Technology Act, 2000 include specified cyber-incident reporting and ICT log-retention requirements for covered entities. The directions state a six-hour reporting window for specified incidents and a rolling 180-day log requirement. The operator must confirm applicability, scope, provider responsibilities, and the India-location requirement with counsel and its infrastructure providers; the current app configuration does not establish that these controls are met. Refer to the official CERT-In directions and FAQs.
10. Changes and privacy contact
When a verified operator and privacy contact are available, the operator should publish updates here with an effective date and explain material changes. No grievance officer or privacy contact details can be listed yet because none were supplied or verified. The contact page currently identifies this gap and does not send messages.