Data, Storage & Security

Advocate Diary is a software-as-a-service application used by advocates, chambers and law firms in India to manage their practice — cases, clients, hearings, tasks, notifications and related records, and to upload documents that go with a matter.

This page is a plain description of how the application handles that information: how access is controlled, where documents and application data are held, how payments are processed, and what stays your responsibility. It is written to be accurate rather than impressive, and it does not use claims we cannot back up.

Every request against the application, other than the handful of clearly public pages, is authenticated. There are no public read endpoints for firm data. A signed-in user is placed in a specific role — firm administrator, advocate, staff, client (portal) or platform administrator — and the role determines what they can see and do.

• Sign-in tokens are scoped to the individual account and are invalidated when you sign out.
• Repeated failed sign-in attempts are rate-limited both by identifier and by IP address, to make guessing attacks harder.
• Password reset links are single-use, expire after one hour, and are stored only as hashes.
• Platform administration is fully separate from firm accounts and cannot reach a firm's records; equally, firm users cannot reach platform administration.

Advocate Diary is built so that each organisation’s records are scoped to that organisation. Every case, client, hearing, task, document, note and report belongs to an organisation, and application APIs answer only from within it.

• One firm's users cannot list, open, edit or export another firm's data through the application's APIs.
• Within a firm, what a member can do depends on the role assigned to them — for example only a firm administrator can manage the team, and only staff-level users can create new matters.
• The client (portal) role can see only their own matter, and only the updates the firm chooses to publish.

Passwords are never stored in a readable form. When you set a password, it is converted into a one-way hash using bcrypt, and only that hash is stored. Nobody operating the service can read your password back, which is also why a forgotten password must be reset rather than retrieved.

• Passwords must be at least eight characters.
• Password reset tokens are randomly generated, stored only as hashes, are single-use, and expire.
• Reset links only work over HTTPS.

Documents you upload — pleadings, orders, briefs, correspondence and other files attached to your matters — are stored in Cloudflare R2, a private object storage service. The R2 bucket used by Advocate Diary is not public.

• Documents are not served through public links. There are no permanent public URLs for your files.
• Every download goes through an authenticated endpoint on the application, which checks that the signed-in user belongs to the organisation the document belongs to and has the role required to see it.
• Only the file itself is stored in the bucket; the record of what the file is (name, matter, uploader, size) is stored in the application database and is also scoped by organisation.
• When you delete a document in the application, it is marked as deleted and is no longer available through the application.

Access to R2 from the application uses infrastructure credentials that are held only on the server side. Those credentials are never sent to the browser or exposed in any application response.

The application’s records — organisations, users, cases, clients, hearings, tasks, subscriptions, and the metadata that describes uploaded documents — are stored in a managed MongoDB cloud database used by the service. Access to the database is over an authenticated connection and is restricted to the application server.

• The application does not expose the database directly to the browser or to any third party.
• Database credentials are held only on the server side and are never sent to the browser or included in any application response.
• The application relies on database-level unique indexes to prevent duplicate subscriptions, duplicate payment records and duplicate webhook events, so that billing state stays consistent.

A firm can invite a client to a read-only portal for a matter that firm handles for them. Portal access is not open — it is created only by an authenticated invitation from the firm.

• An invitation is stored as an invitation record with an expiry, and the invitee sets their own password when they accept it.
• A client account is a distinct account type (the client role) linked to a specific client record, and it cannot see the firm's internal notes, other clients, other matters or firm-wide data.
• The firm chooses what to publish to the portal — the client sees only the updates the firm makes visible.
• Revoking a client's access to the portal is done from within the application by the firm.

Paid subscriptions are processed through Razorpay. When you subscribe, checkout runs on Razorpay and returns you to Advocate Diary on completion. Razorpay handles the payment transaction itself.

• Advocate Diary does not store card numbers, CVV, UPI IDs, UPI PINs, net banking credentials or any other payment instrument credentials. These are entered into and handled by Razorpay.
• Razorpay's webhook notifications for your subscription are verified against a shared signing secret before they are processed, so unsigned or forged notifications are rejected.
• The application stores subscription and payment records returned by the gateway — plan, status, gateway reference IDs, payment amount and date — so that your account, receipts and access are correct.
• Razorpay's own handling of your payment details is governed by Razorpay's terms and privacy policy.

The application is served over HTTPS. Sign-in, application traffic, document uploads and downloads, password resets and payment redirects all travel over encrypted connections between your browser and our servers.

Password reset links refuse to be issued unless the configured application base URL is HTTPS, so a reset link is never emitted over a plain-text URL.

Advocate Diary is provided on an “as is” and “as available” basis. We do our reasonable best to keep the service available, but we do not publish a fixed uptime percentage or a guaranteed availability commitment, because that is not something we have committed to.

We do not claim zero data loss. Backups and disaster recovery capabilities depend on the database and storage services used to run the application; we do not publish a specific recovery-point or recovery-time objective, because none has been established for the service. You remain responsible for keeping your own records of matters, dates and deadlines that are important to you.

Access to the servers, database and storage that run Advocate Diary is restricted to the small set of systems and people that operate the service, using authenticated credentials that are not shared with third parties.

• Infrastructure credentials (database, storage, payment gateway, email) are stored as server-side environment secrets and are never sent to the browser or included in any application response.
• We do not publish specific infrastructure details, connection strings, bucket names or key material — they are not part of what a user of the service needs to know, and disclosing them would reduce security.
• Third-party services used by the application (Cloudflare R2 for document storage, Razorpay for payments, an email delivery provider, cloud hosting) receive only what they need to perform their function.

Some things stay in your hands. You are responsible for:

• Keeping your password confidential and not sharing your sign-in credentials — each team member should have their own account.
• Choosing a strong password (at least eight characters) and not reusing one from another service.
• Signing out on devices that are not yours, including shared devices and court-room devices.
• Giving the correct role to each team member you add, and removing access when someone leaves.
• Inviting a client to the portal only at an email address you have verified with that client, and revoking access when it is no longer appropriate.
• Meeting your own professional and confidentiality obligations towards your clients, including deciding what to record about a matter.

If you believe your account has been accessed without authorisation, contact us at supravat111@gmail.com so we can help.

If you find a security issue in Advocate Diary — for example a way to see data outside your own organisation, a way to reach a document without being signed in, or a way to bypass a permission — please tell us at supravat111@gmail.com. Please include enough detail for us to reproduce it, and please do not publish it before we have had a reasonable chance to fix it.

We do not publish a specific response-time or fix-time commitment for security reports, because we have not made one — but we do take reports seriously and reply from a person.

In the interest of being accurate rather than impressive, Advocate Diary makes no claim to any of the following:

• ISO/IEC 27001, SOC 2 or PCI DSS certification for Advocate Diary. If certification is ever obtained, this page will be updated.
• End-to-end encryption of application data (traffic between your browser and our servers is over HTTPS; that is not the same thing as end-to-end encryption).
• Zero data loss, or absolute protection from breaches, or immunity to service disruptions.
• A guaranteed uptime percentage or a published service-level agreement.
• Any "military-grade" or similar marketing security label.
• Any compliance certification that has not been independently verified.

We prefer to describe what the application actually does — organisation-scoped access, authenticated document downloads, hashed passwords, Razorpay-handled payments, signed webhooks — and to update this page as the service changes, rather than to claim more.