Legal · for businesses

Partner Terms

Effective date: 27 October 2026
They govern use of FinLens by a business. They are not the terms your customer agrees to.

The agreement between Value Garage Private Limited and a business that integrates FinLens: what we deliver — an index of the emails with files that our fixed searches find in your customer's Gmail, with the text of each, then the files you ask for — and how long you have to collect it, the Google restrictions that travel with both, what you are responsible for once they arrive, and how either of us stops.

1. Which document this is

FinLens is a product of Value Garage Private Limited (CIN U66190DL2025PTC453505), a company incorporated in India with its registered office at Flat no. 26, Vandana Apartment, East Delhi, Delhi — 110092 ("FinLens", "we", "us"). These terms are an agreement between us and the business that integrates FinLens ("you", "the client"). "You" here is a company, never a consumer.

There are two agreements. This page governs your integration: the API, the credentials, the documents we hand you and what you may do with them. The Terms of Service are between us and the individual whose mailbox is read; your customer accepts them by continuing through the FinLens connection flow, and they say at §14 that they are not the agreement a business integrates under. Neither document gives the other's counterparty any right: your customer cannot enforce this page, and you acquire nothing under the Terms of Service. They are written to agree; if they ever do not, tell us.

Our Privacy Policy is what your customer reads about our handling of their data. It is not a data-protection agreement between you and us; §4 covers that.

These terms take effect when the first credential is issued to you or when you first call the API, whichever is earlier. A written order form or agreement signed by both parties prevails over this page where they conflict — but nothing in an order form waives §3, because those obligations are not ours to waive.

2. What FinLens delivers, and when

FinLens lists the emails in your customer's Gmail that are likely to carry their financial documents, with their permission, and fetches the files you then ask for:

1. You create a session — POST /v1/sessions — with your own reference for the customer and a return URL. (Document types and named institutions, which earlier versions of the API took, are accepted for a transition and ignored: the index is made by the same searches for every client and every customer, and nothing you send changes them.) You receive our link, valid for 60 minutes, which sends your customer straight to Google.
2. Before you send it, you show your customer FinLens's standard disclosure (Schedule 1) in your own app, as §5.1 requires. It names you by your registered name as the only recipient. There is no FinLens consent page: the disclosure is what your customer reads before deciding.
3. Your customer opens the link and grants gmail.readonly access on Google's screen. That completes the consent: we record it, with you as its recipient, and return your customer to your return URL. We read nothing of their Gmail yet: we tell your webhook endpoint that the consent is granted (consent.granted), and the consent waits for you to ask. If they decline at Google or untick Gmail, the session does not end: they see our page, which names you and offers Try again beside Return to your registered name; you are told (integration docs §11); and they may try again on the same link until it expires.
4. When you ask, we check, and give you an index. You ask once, when your feature needs your customer's documents, with POST /v1/sessions/:id/refresh on the consent's own session; that starts the consent's first check. Until you ask, we read nothing of your customer's Gmail. We then run seven fixed searches in your customer's Gmail, with Gmail's own search, on Google's side. They are the same for every client and every customer, and each looks, over its own period, for email with a file attached that is likely to be one kind of financial document: (1) proofs of identity and address (KYC), over the last ten years; (2) loan papers — sanction and offer letters, disbursement and repayment schedules, key fact statements, interest certificates, NOCs and no-dues letters, loan statements — over ten years; (3) property papers — allotment and possession letters, agreements for sale, sale deeds, demand letters and payment receipts — over five years; (4) consolidated account statements of investments, over 45 days; (5) fixed-deposit advices, over a year; (6) card statements, over 100 days; and (7) email your customer sent, with a file, to banks, lenders, housing-finance companies and builders, over five years. Searches 1, 2, 3, 6 and 7 consider only email with a PDF, JPEG, PNG, ZIP or Word file attached, and leave out calendar invitations and a fixed list of routine mail — brokers' and exchanges' daily reports and contract notes, food, travel and ride bookings, payment services, invoices, tickets, invitations, webinars, newsletters and one-time codes. The searches match subjects, file names, senders' and recipients' addresses and dates, not meaning: an email in the index may not be a financial document, and a document whose email matches no search is not listed. No search has a cap, and an email found by more than one is listed once. We judge no sender ourselves: an email that matches a search is listed whoever sent it. We never read email in Spam, Trash, Drafts or Chats. A picture embedded in an email, such as a logo or a signature image, is not listed as a file, and neither is a file larger than 25 MiB (26,214,400 bytes), the most we fetch. The index is usually ready within a few minutes of your asking: we read about a hundred emails a minute, as fast as Gmail allows one mailbox, and the searches usually find a few hundred. We write it in pages of up to 500 emails as we read it, and each page can be pulled as soon as it is written, while the check goes on. Each part can be collected for 3 hours after it is ready. You can fetch files from the pages you have while the rest are still arriving (one fetch of a consent at a time). The session says how many pages and entries there are so far, and whether the index is complete. Two things stop a check early, and the summary then says so with truncated: a safeguard against a read that never ends, set far beyond any real mailbox; and, for a consent given on version 4 of the disclosure, the 5,000 emails that version named, on a check with no earlier index to start after (a refresh of a consent none of whose indexes you pulled, §16). The index has one entry per email: its date and time; the sender's name; its From and To addresses; its subject line; the text of the email; whether it was received or sent; which of the searches found it; for an email received, whether Gmail confirmed when it delivered it that it came from the sender's domain — Gmail's own DKIM, SPF and DMARC results, as Gmail recorded them; a reference to its conversation, the same for every email of one conversation within the consent and meaningless outside it; and for each file its name, content type, size and a reference. The text of the email, the sender's name, Gmail's results and the conversation reference come only with consents given on version 6 of the disclosure or later (§16). Nothing else of the email: no Cc or Bcc, none of its other headers, and none of Gmail's own identifiers.
5. Your registered webhook endpoint is notified, once we have added its host to our outbound list (integration docs §11.1). You then pull the index, every page of it (GET /v1/sessions/:id/index?page=N): each part can be collected for 3 hours after it is ready. We keep no copy of a page after that, and no other list of your customer's email.
6. You ask for the files you need, by their references, on any day while the consent lasts (§3.5 says which). We fetch only those from Gmail. A request carries references and nothing else: we accept no name, PAN, date of birth, mobile number or other identity, and a request that sends one is refused. You are notified, and you pull the files within three hours. We read nothing inside any file, and no person reads one.
7. For the consent's term — up to six months from your customer's approval — you may also ask us to check again for new email: POST /v1/sessions/:id/refresh on the consent's own session. Each refresh is a new session with its own check and its own index — each part of it can be collected for 3 hours after it is ready — and runs the same searches over only email that arrived since the check whose index you last pulled began. One check runs per consent at a time, at least an hour apart. Nothing widens a consent: another recipient needs a new session and a new approval.

How a consent ends. When its term runs out; when you call DELETE /v1/sessions/:id/consent, which you must do when your customer withdraws in your app (§5.2); when we end it at your customer's request to us, through our grievance officer or a request to delete what we hold; or when Google refuses our grant, because your customer removed FinLens in their Google account, left it unused for six months, or changed their password. Each time we revoke our access at Google and delete our copy; any index or documents of that consent you have not yet pulled are deleted at once and can no longer be pulled; every reference you hold for that consent stops working; and you are told with consent.expired or consent.revoked to your webhook endpoint, and in the consent block on GET /v1/sessions/:id. Until it ends we hold our access to your customer's Gmail, encrypted, whether or not you have asked for anything; a consent you never ask about ends in the same ways, having read nothing.

What each file is. The file you asked for, exactly as it was sent, whatever its type. We neither open it nor read it, and we do not check it for malware: that is yours to do (§3.5). A password-protected file reaches you still protected; we hold nothing that would open it, and never a password. With each file come the details its index entry gave — nothing read from the file itself. These terms, like the integration documentation, call a delivered file a document. The interface is described in the integration documentation, which is part of these terms to the extent it describes behaviour, and is not a promise of future behaviour.

Your registered name cannot be corrected. The name you give us at onboarding is the name the standard disclosure must carry, the recipient our record of every consent names, and the name our pages show your customer — so it must be your registered name exactly as on the contract. There is no rename. A wrong name means being provisioned again as a new client and abandoning the old one, including its credential.

3. Google Limited Use, flowed down to you

This clause applies to every index and every entry and reference in it, to every document and every field we deliver with it, and to anything you derive from any of them.

3.1 The one use you are permitted

You may use what we deliver — the index and the documents, at the first check, at every refresh and at every request — only to provide and improve the user-facing feature in your app in which your customer was shown the standard disclosure and from which they were sent to Google. Not a different purpose you form later, and not a purpose you would have to explain to them afterwards. Within that feature the index has one use only: choosing, or letting your customer choose, which files to ask for (§3.5).

3.2 What you must not do

• Do not transfer the index or the documents onward, except where necessary to provide or improve that same feature; for security purposes; to comply with applicable law; or as part of a merger or acquisition, after your customer has been notified and has consented. Anyone who receives either under one of these exceptions is bound by this clause as you are.
• Do not sell them.
• Do not let a person read them — an index entry included — except where your customer has affirmatively agreed to that specific access, where it is necessary for security, abuse investigation or legal compliance, or where the law requires it. Record why whenever a person does.
• Do not use them for any other purpose — including building or sharing profiles of, or datasets about, individuals, or developing or improving any general-purpose product or system — and do not supply them to anyone who would.
• Do not re-identify, enrich or combine them with other sources for a purpose your customer was never told about.
• Comply with every other Limited Use requirement of the Google API Services User Data Policy that applies to information obtained from Google APIs.

3.3 What this clause does not bend to

• Consent does not waive it. These are obligations we owe Google. No consent you collect from your customer releases you from any of them.
• It flows down. It binds your affiliates, agents, contractors and sub-processors, and you are responsible for what they do as if you had done it.
• It survives termination, for as long as you hold anything we delivered or anything derived from it, whichever party ended this agreement.

3.4 What a breach costs

A breach of this clause is a material breach, and we may suspend you immediately on discovering one (§10), without a cure period: a Limited Use breach by one client puts at risk the Google verification the whole platform runs on, and with it every other client's customers.

You will cooperate promptly with any Google enquiry, assessment or audit that touches data we delivered to you, and give us the information we reasonably need to answer one.

3.5 The index, and what you fetch

The index lists the emails our fixed searches find, whoever they are from or to, so it carries more than the files you need: each email's text and subject line, the names of its files, and the names and addresses of the people it was sent from and to, including people who are not your customers. The searches match words, not meaning, so an entry may be personal mail. We verify no sender: an email in the index may not be from whom it says, and where an entry says Gmail confirmed an email came from its sender's domain, that is Gmail's record of the email's delivery, not our check of who sent it or of what it says. On top of §3.1 to §3.4:

• Fetch only what the service needs. Ask only for the files the service you described to your customer needs. The index lists everything so that you can choose; asking for everything it lists, in case it proves useful, is not that.
• Use the index only to choose. Not to profile your customer, to rate or assess them, to decide anything about them, or to learn anything about them from whom they write to, what their emails are called or what they say; and never for advertising or marketing, to them or to anyone else.
• Choose by software, or let your customer choose. A person at your organisation, or acting for it, may read an index entry only as §3.2 allows.
• Protect it as you protect the documents (§4.2): encrypted at rest, open only to the people and systems the feature needs, kept out of your logs, and never passed to an analytics, monitoring or other third-party service.
• Treat the text of every email as sensitive, and as untrusted. It is the email as its sender wrote it, and may hold a password or the rule for one, a one-time code, an account or card number, or other personal data of your customer or of someone else; we neither look for nor remove any of it. Protect it as personal data, as you protect the documents (§4.2). Never write it to a log, an error report, a support ticket, or an analytics or monitoring tool. Use it only to serve that customer's own documents, in the feature they were shown, and for nothing else. Delete it with the rest of the index when the consent ends. Its links are as the sender wrote them: never follow one automatically.
• Delete it when the consent ends — at its term, on a withdrawal by any route, or when we tell you it has ended — with every reference in it, and sooner once the service no longer needs it. The documents you fetched are kept under your own retention rules (§4.2); the index is not: it never outlives its consent.
• A reference is for asking us for that one file, for that customer, while the consent lasts, and for nothing else. It is sealed: only we can use it, and it stops working when the consent ends. Do not try to read what it carries, alter it, or use it under another consent.
• Scan every file you fetch for malware, with current anti-malware software, before a person opens it or another system takes it in. We verify no sender and open no file, so a file we deliver may be phishing or malware however its email, its sender's name and address, Gmail's results and the file's name look. Do not open or run a fetched file automatically before it has passed the scan, and treat one that fails as hostile: quarantine or delete it, and do not pass it on.
• Send no identity. A request carries references and nothing else. Do not send us your customer's name, PAN, date of birth, mobile number, a password or any other identity; we accept none and open no locked file. A file that arrives locked is between you and your customer.

4. Your data-protection obligations

Every data-protection duty between us is in this clause.

4.1 Who is what

FinLens takes your customer's permission directly. We decide how the mailbox is queried, what an index carries, what is fetched and delivered, and how long anything is kept, and the individual gives permission to us — on Google's screen, which names FinLens, after you have shown them our standard disclosure. So we act as a Data Fiduciary under India's Digital Personal Data Protection Act, 2023 ("the Act") for the collection, not as a processor acting on your instructions.

4.2 What that makes you responsible for

• Notice. Tell your customer what you do with the index and the documents, and keep it accurate.
• A lawful basis for your own processing, which you also represent to us on every session (§5).
• Purpose limitation, accuracy and reasonable security safeguards over your copy.
• Your own retention rules, and erasure when your purpose is served or consent is withdrawn — and for the index, its deletion when the consent ends (§3.5).
• Responding to requests from the individual about your copy, and publishing a grievance route they can reach.
• Breach notification. A personal data breach affecting your copy is notified to the Board and to the affected individuals by you, as the Act requires of you.
• Your own privacy policy, published, accurate and reachable by your customer, covering what you do with the index, the documents and the fields delivered with them, how long you keep them, and how an individual reaches you. You may not present ours as covering your handling, or tell a customer that FinLens's retention answers a question about your copy.

4.3 Withdrawals, erasure and refusals

4.4 Agreements and providers

There is no data processing agreement between us: we do not process your customers' data on your instructions, and each of us is a Data Fiduciary for its own processing (§4.1).

Our sub-processors are published on our Trust page, with each provider's purpose, the data it can access and its location; a new one is listed there before it touches any data. No index or document is sent to any provider of ours: both are handled only in our own systems, and nothing reads what is inside a document. No provider receives anything derived from your customers' email, and no AI service is used.

5. What you represent on every session

On each session you create (a refresh included), each time you ask for a consent's first index, and on each request for documents, you represent and undertake that:

• The person is your customer and has asked you for this. You do not create a session speculatively, for a prospect who has not asked, or on anyone else's behalf.
• You hold your own lawful basis for collecting and processing what we deliver, independent of the permission your customer gives us (§4).
• What you ask for, the service needs: each file you request is needed for the service you described (§3.5), and you scan it before use.
• You have established who they are, and that they are 18 or older. There is no age check in the connection flow; we rely on your onboarding (Terms of Service §4).
• You send no identity of your customer and no password, with a session or a request (§3.5).
• The return URL is one you control, and the registered name is truly yours.

5.1 Before you send a link: the standard disclosure

There is no FinLens page between Google's screen and your app, so what your customer reads before deciding is FinLens's standard disclosure, and showing it is your obligation. For every link you send — every new session, not once per customer:

• Show the standard disclosure in Schedule 1, in your own app, before you send or open the link, in the feature that will use the index and the documents, so that the feature your customer sees is the one §3.1 lets you use them for.
• Unaltered. Fill in only its marked places, each with your registered name exactly as we provisioned it. Add, remove, reorder or reword nothing. Nothing else on the screen may contradict it or describe the documents as going to anyone but you.
• In full, where the decision is made. The whole text must be visible on the screen from which your customer chooses to continue to Google — not behind a link, a tooltip or a collapsed section — with a way not to continue that is as easy to use as the way forward.
• The current version. When we change Schedule 1 (§16), links you send after the change carry the new text. From the effective date of these terms that is version 8 (version 9 if sending is switched on for you), and versions 1 to 7 may not be shown.

A link sent without the disclosure is a material breach of these terms (§10).

5.2 While a consent lasts

Your customer's consent lasts up to six months (§2). For as long as it does:

• Give your customer a way to withdraw inside your own app, as easy to find and use as the step where they agreed, and when they use it, call DELETE /v1/sessions/:id/consent straight away. That call makes the withdrawal real on our side: we revoke our access at Google and delete our copy, any index or documents of the consent you have not yet pulled are deleted at once and can no longer be pulled, your references stop working, and no refresh or request runs again. Do not make withdrawal conditional, and do not send them to us instead. They may also withdraw through us or at Google, and §4.3 applies whichever route they take.
• Ask for the first index, a refresh, or documents only to provide the feature your customer approved, and use what you receive only for that feature (§3.1, §3.5). We read your customer's Gmail only when you ask (§2), so ask when the feature needs their documents. A consent is not a standing feed of your customer's email or documents.

6. Credentials

Access to the API is a key id and an API secret, issued to you by an operator. There is no self-serve signup.

• You hold the secret. Store it as you would a production database password. Do not embed it in a mobile or browser client, commit it, send it over a channel you would not send a password over, share it, or let another business create sessions under it.
• Everything done with your credential is attributed to you and is your act under these terms.
• Rotation is yours to request. We issue a second credential and show it once; your existing one keeps working until you confirm you have cut over and we revoke it. Nothing expires it on its own, so tell us when you are done.
• Tell us immediately if a credential is or may be exposed. We may revoke a credential without notice where we reasonably believe it is compromised.
• Your webhook signing secret is handed over on the same terms — once, in the response to POST /v1/webhooks — and cannot be recovered; losing it means rotating the endpoint.
• Revocation and suspension are different. Revoking a credential disables that credential. Suspension acts on you as a client and leaves your credentials untouched (§10).

Your API secret signs one request — POST /v1/tokens, which returns a short-lived bearer token — and every other call carries that token (integration docs §4). A signed request with clock skew beyond ±5 minutes is rejected, so run NTP. Every authentication failure returns the same 401 with the same message; quote the request id to us for a real answer.

7. Prohibited uses

In addition to §3, you must not:

• create a session for a person who has not asked you for the service it delivers, or for a mailbox you do not believe belongs to that person;
• disclose an index or any entry in it, a delivered document, or a field delivered with one, to anyone other than the individual it concerns and those permitted under §3;
• use a reference other than as §3.5 allows, or try to learn what it carries;
• resell, syndicate or otherwise make FinLens available to another business — as a reseller, a white label or an intermediary — without a written agreement with us that says so;
• try to reach another client's sessions, documents or webhooks, or to find out whether a session id exists on another client's account;
• probe, scan, overload or interfere with the service, or get round a security control, a rate limit, the limits on refreshes in §2 or the window in §8;
• present a delivered document, an index entry, or a field delivered with either, as verified, certified, attested or assessed by FinLens. We do not authenticate any email or its sender — the results an entry gives from Gmail are Gmail's, not ours — we do not read, scan or certify any file, and we produce no score, rating or opinion about anyone;
• state or imply that FinLens has evaluated your customer, or attribute a decision of yours to us;
• use the FinLens or Value Garage names, marks or design without our written permission.

Security researchers acting in good faith within the scope on our Trust page are not caught by the interference bullet. Write to security@finlenstech.com first, and never test against a real person's mailbox.

8. The pull window is the retention window

• Collection is your responsibility. Pull on notification, or poll and pull promptly. Each page of an index and each delivery states its deadline (integration documentation).
• After a window closes we report it as purged rather than 404, so you can tell "your three hours are up" from "wrong id".
• Your retention is your decision and your obligation, under §4, your own policy and your own regulator — for the documents; the index goes when its consent ends (§3.5). The three hours is a fact about our systems only.
• We cannot recall, retrieve, alter or delete an index or a document once it has left us.

Whether a fresh consent made necessary by a missed window is chargeable is a commercial question for §12.

9. What we do not promise

The service is provided as is. Specifically:

• No service level, uptime, completion-time or support commitment, here or anywhere else, and nothing on this site creates one by implication.
• No security certification. No ISO 27001 or SOC 2, and no third-party penetration test. Google's CASA assessment, which FinLens passed, is an assessment, not a certification (Trust page; what we do not claim is listed there too).
• No sandbox, test mode or fixture data.
• No guarantee that a file exists, is found, or can be opened. We list only the email §2's searches find, and fetch only what you ask for: a document whose email matches no search is not listed. An email your customer deletes from Gmail after it is listed can no longer be fetched. We open no file, so a password-protected file arrives protected. The index is usually ready within a few minutes of your asking, but we give no time by which a check ends (§2).
• No guarantee that a consent lasts its full term. Your customer can withdraw at any time, and Google ends a grant when your customer changes their Google password or leaves it unused for six months. We learn of an ending at Google at your next refresh or request, which fails, and the consent ends.
• No check of senders, and no check of files. We do not verify who sent an email — Gmail's results in an entry are Gmail's record of its delivery, not our check — whether a file is genuine or complete, or whether it is safe to open. A file from an email that claims to be from a bank may not be, whatever Gmail recorded (§3.5).
• The text of an email is as its sender wrote it. We turn a formatted email into plain text and keep its links, but we do not check, correct or filter what it says. Text longer than 100,000 characters is cut short, and the entry says so.
• We read nothing inside a file. A content type is what the email declared, not what we found. Where an index entry or a field we deliver and the file disagree, the file governs (§2). No person at FinLens reads a file.
• Gmail only.
• Field names and shapes can still change before the first production integration. After that, a change becomes a coordinated breaking change and will be handled as one.

To the fullest extent permitted by law we exclude implied warranties of merchantability, fitness for a particular purpose and non-infringement. We do warrant that we will provide the service with reasonable skill and care.

10. Suspension & termination

We may suspend you where we reasonably believe there has been a material breach of these terms — immediately and without a cure period for a breach of §3 or §7 — where a credential of yours is or may be compromised, where law or Google requires it, where continuing would put end users at risk, or for non-payment, once commercial terms exist, that remains unpaid after notice. We will tell you why, at the address you gave us.

You may stop at any time by ceasing to create sessions. There is nothing to cancel and no minimum commitment.

Either party may terminate these terms on reasonable written notice to the other, or immediately by written notice for a material breach not cured within a reasonable time after written notice of it.

Sections 3, 4, 7, 8, 11, 13, 14, 15 and this sentence survive termination.

There is no rename and no de-provision. A client whose registered name is wrong is provisioned again as a new client. A client that leaves is suspended and has its credentials revoked, not deleted, because its records must be kept.

11. Confidentiality & intellectual property

Credentials are confidential without qualification: your API secret, your webhook signing secret and your key id. Beyond those, each party protects the other's confidential information with at least reasonable care, uses it only to perform this agreement, and returns or destroys it on termination — except information that is public, independently developed, or lawfully obtained elsewhere.

Ours stays ours. The FinLens platform, the API and its contracts, the connection flow, this website and the FinLens and Value Garage names and marks are ours or licensed to us. You have a non-exclusive, non-transferable right to use the service for its purpose during the term, and nothing more. No licence is granted by implication.

Your customer's email and documents are your customer's. Neither of us acquires ownership of them. We acquire no rights beyond listing, collecting and delivering them under the consent given, and we do not keep them. You acquire what your own agreement with your customer gives you.

12. Commercial terms

Fees are agreed per client, in writing, during onboarding. There is no published price list, and nothing on our site is an offer or a quotation. The unit of pricing, the rate, the currency, taxes including GST, invoicing frequency and payment terms are set in the executed order form.

The platform has no billing system. It counts each client's completed scans per period; any usage-based charge is billed by hand from that count until a billing system exists.

We do not charge your customer anything. Terms of Service §1 tells them so, and nothing agreed between us may contradict it: you may not present a FinLens fee to the individual whose mailbox is read.

13. Limitation of liability

To the extent permitted by law, and subject to the last paragraph of this section:

• The cap. Each party's total aggregate liability arising out of or relating to these terms is limited to the fees you paid us under these terms in the twelve months before the event giving rise to the claim.
• Indirect loss. Neither party is liable for indirect, incidental, special or consequential loss, or for loss of profit, revenue, business, goodwill or anticipated savings.
• We are not liable for a document that could not be found or opened (§9), for an error in an index entry, or in a field delivered with a document where the document was delivered with it, or for an index or a document you did not collect inside the window (§8).
• We are not liable for what you do with an index or documents after delivery, for decisions you take on them, or for your handling, retention or disclosure of them.

What the cap and the exclusion of indirect loss do not cover. Neither applies to: fraud or wilful misconduct; a party's breach of its data-protection obligations (§3 and §4), of §7, or of its confidentiality obligations (§11); your indemnity under §14; or any liability that cannot be limited or excluded under Indian law — including liability for fraudulent misrepresentation, for death or personal injury caused by negligence, and any liability under the Digital Personal Data Protection Act, 2023.

14. Indemnity

You agree to indemnify us against claims, losses and reasonable costs arising from your breach of §3, §5 or §7 — in particular from a session created for a person who did not ask for it, and from a use of delivered data that Google's Limited Use requirements do not permit. This does not extend to anything arising from our own breach, negligence or unlawful act.

15. Governing law & jurisdiction

These terms are governed by the laws of India, and the courts at Delhi have exclusive jurisdiction over any dispute arising out of or in connection with them. If you have a complaint, raise it with us first (§17).

16. Changes to these terms

We may update these terms. A revised version is posted here with a new date, and the version in force when a session is created governs that session; we do not apply a later version to something already delivered.

We notify material changes to you in advance, at the address you gave us. A change to §3 that a change in Google's own policy requires may take effect on Google's timetable, with as much notice as that allows.

The standard disclosure in Schedule 1 is versioned with these terms. When it changes, links you send after the change carry the new text (§5.1). A change to what your customer is asked to agree to applies only to consents given after it — never a silent widening of one already given.

Six months, and we read when you ask: version 8 of the disclosure took effect on the effective date of these terms, and replaced version 6; version 9 replaced version 7. Each is the version it replaces, word for word, but for two things: your customer's consent now lasts six months from their approval, where it lasted twelve; and it says that we look in their Gmail when you ask for their documents, and that the list is usually ready within a few minutes of your asking. Versions 1 to 7 may not be shown for any link you send from that day; show version 8, or version 9 if sending is switched on for you. Nothing else changes in what the index lists or what you may fetch. A consent given on version 6 or 7 keeps its twelve months, unless something ends it sooner. In the API, a new consent's expiresAt is at most 180 days after approval, and earlier when your customer chose time-limited access on Google's screen and Google's access ends first; the integration documentation gives the detail.

What changes for you on that date: we read when you ask. For every client, a consent given from that day reads nothing when your customer approves. We record the consent and our access to their Gmail, tell your webhook endpoint with consent.granted, and run the consent's first check only when you ask for its index, with POST /v1/sessions/:id/refresh on the consent's own session (§2); later refreshes work as before. Until you ask, we read nothing, and we hold our access, encrypted, until the consent ends — at its term, or sooner (§2). A consent you never ask about ends at its term, having read nothing. A consent given before that date is unaffected: its first index was made when it was given. In the API, the consent's session waits as awaiting_request until you ask, and session.ready for its first index comes only after you have; the integration documentation says what an existing integration must change.

Sending (21 October 2026). These terms add Schedule 2 (sending on your customer's behalf) and version 7 of the disclosure in Schedule 1. Both apply only if we switch sending on for you, after you sign Schedule 2. Nothing changes for you otherwise, and version 6 stays the text you show.

Version 6 of the disclosure took effect on 20 October 2026, and replaced version 5. Versions 1 to 5 may not be shown for any link you send from that day; show version 6 instead. Version 6 changes what the index lists and what each entry carries. The index no longer lists every email with a file attached: it lists what seven fixed searches find — the same for every client and every customer, run by Gmail's own search, each over its own period (§2) — and is usually ready within a few minutes. Each entry of a consent given on version 6 also carries the text of the email, as its sender wrote it (§3.5 says how you must treat it), the sender's name, for received email Gmail's own results on whether it came from the sender's domain, and a reference to its conversation. Every entry says which of the searches found it. Its marked places take your registered name and nothing else.

What changes for you on that date. A consent given on version 4 or 5 continues: its first index was made as that version described and is not made again; each refresh runs version 6's searches over email that arrived since the check whose index you last pulled began — or, if you pulled none of its indexes, over each search's own period — so it lists fewer emails than that version described; and its entries carry no text of the email, which those versions told your customer FinLens never received, and no sender's name, Gmail results or conversation reference, so nothing reaches you under it that its version did not describe. In the API: an index entry may carry bodyText, the email's text, and always carries matchedBy, the searches that found it; pages written before that date carry neither. The integration documentation gives the detail.

Version 5 took effect on 18 October 2026 and replaced version 4: the first list went back through your customer's whole Gmail history, where version 4's stopped at the newest 5,000 emails; every index was served in pages of up to 500 entries (GET /v1/sessions/:id/index?page=N), each pullable as soon as it was written and collectable for 3 hours after it was ready; and a page that does not exist is refused with index_page_not_found, as it still is.

Version 4 took effect on 17 October 2026 and replaced versions 2 and 3, which may not be shown since. It brought in the index as version 5 kept it, but for its cap: every email in your customer's Gmail that has a file attached, received and sent, from or to anyone, and files of every type; no list of verified institutions, no kinds of document, no unlocking of password-protected files, and no reading of other email to find institutions. A consent given on version 2 or version 3 had been given for a narrower list and could not be widened, so every one ended that day: each grant was handed back to Google, every reference in its indexes stopped working, and you were told with consent.revoked. In the API from that day: a session takes no document types or named institutions (accepted for a transition and ignored); an index entry carries no institution, category or document type; a request for files takes references only, and one that sends an identity is refused; files of any type are listed and delivered, exactly as received; and you must scan every file you fetch (§3.5).

Version 3 took effect on 16 October 2026, later that day than version 2, and added a read of other received email to find institutions FinLens had not verified, with organisation domain names sent to Anthropic in the United States to be labelled; that read and that provider end with version 4. Version 2 took effect on 16 October 2026 and told your customer about the index, which version 1 did not; the consents given on version 1 ended that day.

17. Contact

Partnerships and this agreement · partners@finlenstech.com
Integration and API access · developers@finlenstech.com
Security reports · security@finlenstech.com
Privacy questions · privacy@finlenstech.com
Grievance officer (DPDP) · Suraj Agarwalla — privacy@finlenstech.com

Value Garage Private Limited · CIN U66190DL2025PTC453505
Registered office: Flat no. 26, Vandana Apartment, East Delhi, Delhi, India — 110092

Schedule 1. The standard disclosure

This is the text §5.1 requires you to show, in your own app, before you send each link. Show it as written. Fill in only the marked places, each with your registered name exactly as we provisioned it. The same text is published at finlenstech.com/consent-disclosure. Versions 8 and 9 replaced versions 6 and 7 on the effective date of these terms (§16).

If sending is switched on for you (Schedule 2), show version 9 below instead of version 8, as written. It is version 8 with sending added. The same text is published at finlenstech.com/consent-disclosure.

The disclosure's "6 months" is the term every consent is given under today. Its "asks for your documents" is your request for the consent's first index, which starts its first check (§2). Its "in this app" is the in-app withdrawal §5.2 requires you to provide. Its "list" is the index (§2), its "fixed searches" are the seven searches §2 describes, its "text of the email" is each entry's email text, which §3.5 says how to treat, and the files you ask for from it are only those the service you described needs (§3.5).

Schedule 2. Sending on the user's behalf

This Schedule applies only if we have switched sending on for you. We do so only after you have signed it and passed our onboarding checks, and we may switch it off at any time.

1. Permission. You may ask FinLens to send an email from a user's Gmail only if the user approved sending on Google's screen, after you showed them version 9 of the standard disclosure (Schedule 1), as written — or version 7, for a consent given before the effective date of these terms.
2. Confirmation of every email. Before each request, show the user, in your own app, the full email: the recipient, the subject, the message and the name of any attachment. Send the request only after the user taps a clearly labelled Send control for that email, and give us the time of that tap. You warrant that it is true.
3. What may be sent. One recipient, chosen or confirmed by the user. No Cc or Bcc. Plain text. An attachment only from the user's own documents on your list. Nothing automatic, scheduled, bulk or promotional, and nothing on behalf of anyone but the user.
4. Limits. We apply a daily limit for each user and may refuse any request. Do not split, retry or route around a refusal.
5. Records. Keep evidence of each confirmation (the time, the user, the email shown) for 12 months, and give it to us on request within 5 business days.
6. Suspension. We may switch sending off for you at once, without notice, on any breach of this Schedule, any complaint, or any request from Google. You indemnify us for any breach of this Schedule (§14).