Privacy Policy

1.Who we are, and how to reach us

Gango Tech Ltda. is a Brazilian company, registered under CNPJ 50.086.381/0001-41. We build and operate small business software, and we operate the Meta Business App and the messaging service described in section 2.

Privacy channel: privacy@gango.tech. Every request, question or complaint about this document or about personal data reaches us there, and that is the channel through which a data subject exercises the rights in article 18 of the LGPD (Law 13.709/2018).

We qualify as a small-scale processing agent under Resolution CD/ANPD nº 2 of 27 January 2022, and we therefore maintain a published channel for data subjects instead of formally appointing an officer, in the form that resolution permits. The channel is the address above. There is no separate name to find, and no request depends on reaching a particular person.

2.Scope, and which document controls

This policy covers two things: the Meta Business App operated by Gango Tech Ltda., through which a business connects a WhatsApp number, and notify-core, our messaging service, which receives Meta’s callbacks at a single webhook endpoint and delivers the messages our products ask it to send.

It does not replace the privacy policy of any product. GerTruck and Ternavi each publish their own policy in Portuguese, addressed to the people who actually use them, and each of those is the controlling disclosure for that product — including on what that product collects, who its controller is, and which messaging provider it uses today. Where this document and a product policy differ about that product, the product policy governs.

We state the boundary this way on purpose. A Gango-level document written for one reviewer cannot be the place where a tenant learns how their own product behaves; that belongs in the document that tenant accepted. What this policy answers is the question a reviewer of the Meta app is entitled to ask: what we do with the data the WhatsApp Business Platform puts in our hands.

• •Product policies. GerTruck: gertruck.com.br/privacidade. Ternavi: ternavi.com.br/privacidade.
• •Language. The Portuguese version of this policy prevails between Gango Tech Ltda. and its Clients, under article 46 of the Consumer Protection Code and article 423 of the Civil Code. This English version exists so that the same commitments can be read by Meta and by anyone outside Brazil.
• •Channel terms. The obligations a Client takes on by connecting a number are in the WhatsApp Business Platform Client Terms, which are a separate document.

3.The three roles we can occupy

Our role changes with the data, and the role decides who answers you. This is the first thing to settle, because a request sent to the wrong party is a request that waits.

Operator, for what a Client entrusts to us

Everything a Client — a truck center, a veterinary clinic — registers or generates about its own customers, and everything it hands to us for delivery, we process on that Client’s instructions and for that Client’s purposes. The Client is the controller: it decides what to collect, for what, on which legal basis, and for how long. We are the operator, under articles 5, VII and 39 of the LGPD, and we answer to the Client, with the joint liability that article 42, §1 attaches to an operator that departs from the law or from lawful instructions.

Controller, for our own account data

We decide on our own account about the Client’s registration data, the credentials its systems use to reach our API, the connection record for each WhatsApp number, our billing of the Client, and the access, usage and security records of the service. For those, we are the controller and we answer to you directly.

Tech Provider, towards Meta

Where a Client connects its own WhatsApp Business Account and its own access token, we act as a Tech Provider under section 5.b of Meta’s Platform Terms: we operate the integration on the Client’s behalf, the Client remains responsible for its own messaging, and the obligations that flow down to us are in sections 11, 12 and 16 of this policy.

4.How the integration works

There is no hidden step here, and the mechanics matter for the rest of the document.

• •The account and the token are the Client’s. A Client connects its own WhatsApp Business Account by supplying the number’s identifier and an access token it issued itself, in a screen of the product it uses. We never ask for a token by chat, e-mail or support ticket.
• •The token is verified before it is stored. We call Meta’s Graph API with the supplied credentials first; only a number that answers as connected is written to our database. A token Meta rejects is never persisted, and neither is a rotation that fails verification.
• •One webhook. All of Meta’s callbacks — delivery statuses, inbound messages, template and account updates — arrive at a single endpoint of notify-core, whose signature is verified on every request before anything is read from the body.
• •Graph API v23.0. That is the version our client pins, and it is where the field names used in section 5 come from.
• •Platform numbers. Some products send from a number that Gango Tech Ltda. itself holds, rather than from a number of the Client. In that case the number is ours, the WhatsApp business profile identifies it as ours, and the consequences of that — for the profile a recipient sees, and for Meta’s free service-message allowance, which belongs to the number — are described in the Client Terms.
• •Disconnecting deletes our copy of the token, and only our copy. The token stays valid at Meta until the Client revokes it in Business Manager. We say so plainly because the opposite assumption is the one that leaves a live credential in place.

5.What we collect

Platform Data, from the WhatsApp Business Platform

Platform Data is Meta’s term for what the WhatsApp Business Platform gives us. In our case it is:

• •The recipient's phone number in international format — the identifier WhatsApp uses for a person on the network.
• •The content of the messages sent and received: text, media captions, file names, and the answers a person submits in an interactive flow.
• •Identifiers of media, never the media itself: an identifier, a media type, a caption and a file name.
• •Meta's message identifier (wamid) and the delivery statuses returned for it: accepted for sending, delivered, and failed, with the error the platform reported.
• •Billing metadata Meta returns for a message: whether it was billable, its category, the pricing type and pricing model. These rows are keyed by the message identifier and the number, and hold no recipient address.
• •Template metadata: the template's name, language, the category requested and the category Meta granted, and its review status.
• •The number's identifier and, where the Client has one, the WhatsApp Business Account identifier — which is how Meta organises the invoice.
• •The 24-hour service window per contact, which records when that contact last wrote in, because it decides whether free-form text may be sent at all.

The Client’s access token

We store the access token the Client supplies, because the service needs a usable credential at every send. What we do with it, and what we do not claim about it, is in section 16.

Data a Client enters, by reference

The data a truck center holds about its customers and vehicles, and the data a clinic holds about tutors and patients, is listed in full in that product’s own policy, and we process it as operator. This document does not restate those lists, because a second list would be a second source of truth and the two would drift.

Data we hold as controller

• •The Client's registration data and the contact details of the people who administer its account.
• •The credential its systems use to reach our API, stored only as a hash.
• •The connection record of each number: state, the moment it first connected, and the counters that govern its sending limits.
• •Our own billing of the Client, and the monthly counters described in the Client Terms.
• •Access, usage and security records of the service, including the raw copy of each webhook call described in section 13.

6.What we do not collect

These are refusals with code behind them, not aspirations, and each one is the reason a category above is shorter than a reader might expect.

• •Media bytes. When a product needs an image, a document or an audio file that arrived over WhatsApp, our service fetches it from Meta and streams it straight through, with caching switched off. Nothing is written to disk, to a bucket or to the database. The plan had been to store media in our own object storage; it was not done, and the reason was privacy rather than effort.
• •Read receipts. Meta reports when a message is read. We do not record it. Our delivery statuses stop at delivered, and there is no open tracking, no click tracking and no pixel anywhere in the service. Keeping the read event would have turned a delivery log into reading surveillance that nobody asked for.
• •WhatsApp profile names. We do not store the display name a person set on their WhatsApp profile. We know a recipient by a phone number, and that is the whole of it.
• •Contact lists and message history. We do not import a Client’s address book and we do not read conversation history from anywhere. A conversation exists for us only from the message that passes through us onward.
• •Full card, bank account or national identification numbers over WhatsApp. We do not send them and we do not ask for them in a message. A payment always happens on the payment institution’s own page, reached by a link.
• •No clinical record over WhatsApp. Ternavi’s notice to a family member carries the clinic’s name, the animal’s name and a personal secure link. The hospitalisation record — messages, photographs, parameter sheets, the dossier — stays inside the platform, behind that link, and is not sent over the channel.

7.Why we process it

• •To deliver the messages a Client asks us to deliver, and to receive the replies to them.
• •To keep a delivery record, so that a Client can show what was sent, when, and what the platform answered.
• •To enforce the channel's own limits: the per-number sending rate, the warm-up ramp for a newly connected number, the daily ceiling, and the check that blocks a template whose category Meta granted differently from the one requested.
• •To hold a queue rather than lose it when a number stops being able to send, and to release it when the number returns.
• •To count service messages per number per month, so that a Client can see its position against Meta's free allowance.
• •To answer support requests, to keep the service secure and to prevent abuse of the channel.
• •To comply with legal and regulatory obligations, and to exercise our rights in a proceeding.

The limit that comes with Platform Data. Data we obtain from Meta about a person is used only as reasonably necessary to support messaging with that person. It is not used to enrich a profile, to target anything, or for any purpose the person’s own conversation does not serve. This is section 3.a of Meta’s Platform Terms and it is also article 6, I and III of the LGPD; we would hold the same line without either.

The messages our products send are service notices — a renewal falling due, an update on a hospitalised animal — and they are sent as utility templates or inside an open 24-hour service window. We do not use the channel to advertise our own products to a Client’s customers.

8.Legal bases

Each category has its own basis under article 7 of the LGPD, and we do not carry one basis across categories to save a paragraph.

• •Execution of contract (art. 7, V) — the Client’s registration and account data, the connection record of each number, our billing, and the delivery of every message, which is the service itself.
• •Legitimate interest (art. 7, IX) — the access, usage and security records, the signature verification and raw webhook copy that make a callback auditable, the sending limits, and the prevention of abuse of the channel. The balancing for each of these is the ordinary one: the processing is what keeps the service working and safe, it is within the expectation of anyone using it, and none of it feeds a decision about a person.
• •Compliance with a legal or regulatory obligation (art. 7, II) — the records the law requires us to keep, listed as criteria in section 13, and the retention floor that applies to a veterinary clinical record.

Where we act as operator, the basis is indicated by the Client as controller, and it is documented in that product’s policy. GerTruck’s renewal reminders, in particular, rest on the truck center’s legitimate interest under article 7, IX, with an unsubscribe link in every reminder, exactly as section 6 of GerTruck’s policy states. This document does not restate that analysis and does not modify it — two formulations of the same balancing test, in two places, would be one formulation too many.

An objection we record for a recipient is honoured at delivery time, checked immediately before the message is dispatched, under article 18, §2. We record it on request, by hand: there is no self-service screen and no endpoint a Client can call to register one, as section 17 says. Nothing in this policy asks a data subject to consent to anything, and Meta’s opt-in requirement is a contractual requirement of a third party, not an LGPD consent.

9.What we never do

• •We do not sell, licence or purchase Platform Data, and we do not sell personal data of any kind.
• •We do not use Platform Data, or anything a Client entrusts to us, to train artificial intelligence models.
• •We do not use it to discriminate against anyone, or to make or support any decision about a person's eligibility — for credit, insurance, employment, housing, education or a public benefit.
• •We do not build profiles of the people a Client messages, and we run no automated decision-making that produces effects on a person.
• •We do not use the platform for surveillance, and we do not make Platform Data available to anyone who would.
• •We do not attempt to re-identify data that has been anonymised, and we do not combine Platform Data with data from another source to identify someone.
• •We do not share one Client's data with another Client, in aggregate or otherwise.

The first two items are the same commitment the product policies make in their own words, and they are deliberately identical in substance: a Client reading both documents must not find two different promises about the same thing.

10.Who else processes the data

We do not sell personal data. We share it only with suppliers that support the operation of the service, each restricted to the minimum its function needs:

• •Meta Platforms — the WhatsApp Business Platform. Receives the recipient’s phone number and the content of the message, because that is what delivering a WhatsApp message consists of.
• •Resend — transactional e-mail, in the United States. Receives the recipient’s e-mail address, their name where applicable, and the content of the message. Nothing else: no attachment, no exported report.
• •Amazon Web Services (S3), region sa-east-1 — storage of the files products hold (vehicle photographs and documents, registration paperwork, clinical media and dossiers) and of the daily database backups. In Brazil.
• •Google Cloud, region southamerica-east1 — the virtual machine that runs the applications and the shared database. In Brazil, in São Paulo.
• •Asaas IP S.A. — payment institution, in Brazil, for GerTruck’s payments module. Receives the registration data of the truck center and, when a charge is issued, the name, tax number, e-mail and telephone of the customer to be charged.
• •Sentry — application error capture, for Ternavi, and only when it has been configured. Receives technical execution traces, with request body, cookies, query string and e-mail addresses removed before sending. While it is not configured, nothing goes by that path.
• •notify-core — our own service, not a third party. It is listed here for transparency: it is what handles the life cycle of a WhatsApp number and the delivery of every message, and there is no other company on that path.

We may also disclose data to comply with a legal obligation or an order of a competent authority. A change of supplier, of destination or of what a supplier receives changes this policy before the change is deployed, as section 20 says.

11.How one Client's data is kept apart from another's

Separation is enforced at every read and every write, and it rests on two facts rather than on a convention:

• •The calling application is identified only by its credential. The API key resolves to exactly one application, and that resolved application is the only source of the application identifier the rest of the service uses. No request body, query parameter or header can name a different one — there is no schema anywhere in the service that accepts such a field. An inactive application is refused exactly as a bad key is.
• •Inside an application, everything is scoped to an opaque tenant identifier. That identifier is supplied by the product and is deliberately not a foreign key to anything: our messaging service does not know, and cannot come to know, what a tenant is in the Client’s product. It is immutable and it is not editable from any settings screen.
• •Inbound messages route by the number, and an unknown number routes nowhere. A callback is matched to a connected number by Meta’s number identifier. If no connected number matches, the callback produces no event for anyone — not for the nearest Client, not for a default tenant. It is counted and it stops.

12.Our record of Clients

Section 5.b of Meta’s Platform Terms requires a Tech Provider to keep an up-to-date list of the Clients on whose behalf it accesses the platform. We keep that record: for every connected number we hold the application it belongs to, the tenant identifier that owns it, the WhatsApp Business Account it sits under, the moment it first connected, and its current state. We make that record available to Meta on request.

13.How long we keep it

The part that is automated, and that runs whether or not anyone asks: ninety days. A daily job in our messaging service takes every message whose sending has finished — sent, abandoned or skipped — and older than 90 days, and erases from it the recipient address and the message payload, stamping the moment it did so. What survives is the delivery record: which provider carried it, the platform’s message identifier, the resulting status, when it was sent, and the identifiers that tie it to an application and a tenant. A message still waiting to be sent is deliberately left alone.

Two other kinds of row are on the same 90-day cut, and both hold a phone number:

• •The 24-hour service window rows, one per contact, which hold the contact's number in plain digits because they decide whether free-form text may be sent. These rows are deleted outright, not blanked. The cut is 90 days rather than 24 hours on purpose: sending only ever looks at the last day, so a looser cut costs nothing and a tighter one would risk deleting a window still in force.
• •The delivery receipts Meta returns, from which the recipient identifier is removed from the stored payload while the receipt itself is kept.

GerTruck

GerTruck keeps data for as long as the purposes in its own policy require and for as long as legal, regulatory, accounting and tax obligations require. There is no automatic purge routine in GerTruck — erasure is a procedure carried out on request. The criteria we apply are:

• •Charges issued and the double-entry ledger: kept for five years from the close of the financial year in which the operation occurred, to meet accounting, tax and bookkeeping obligations and for the regular exercise of rights (arts. 7, II and VI, and 16, I of the LGPD).
• •Copies of registration verification documents: kept while the purpose of resubmission and proof before the payment institution lasts, that is, while the payments module is active for that company. Once the module ends, the file is erased on request through the privacy channel, keeping only the record of the document type, the moment of submission and the review status. The documents delivered to the payment institution follow its own regulatory retention periods, over which we have no say.
• •Audit trail: kept for as long as the contractual relationship lasts and, at a minimum, for six months, in the form of article 15 of Law 12.965/2014. The trail records the action, its author and the moment; it does not store the content of customer, contact or vehicle records.

Ternavi

Ternavi does have a retention routine, and two honest qualifications come with it. A clinical record is kept for a period the clinic sets, with a floor of 60 months encoded in the platform, because a veterinary record is subject to a duty of custody and article 16, I of the LGPD expressly reserves that case.

14.International transfer

The database, the applications, the files products store and the backups are in Brazil, in São Paulo. That is an architectural decision, not an accident: the largest categories of personal data we handle are simply not subject to the international transfer regime of articles 33 to 36 of the LGPD.

Processing outside the country remains, and only these:

• •WhatsApp (Meta) — delivery of messages, on global infrastructure. Receives the recipient’s phone number and the content of the message. Basis: article 33, IX combined with article 7, V — the transfer is necessary to perform the communication service that was contracted. Delivery over Meta’s network is inherent to the channel: there is nothing to sign and nothing to substitute.
• •Resend — transactional e-mail, in the United States. Receives the recipient’s e-mail address, their name where applicable, and the content of the message. Basis: article 33, IX combined with article 7, V — delivering the message is the performance of the contracted service itself.
• •Sentry — application error capture, for Ternavi, active only when it has been configured. Receives technical execution traces, with request body, cookies, query string and e-mail addresses removed before sending. The region of processing follows the organisation in which the service is configured; while capture is disabled, no data leaves the country by that path, and the applicable article 33 basis will be stated here when it is enabled.

The bases in article 33 are alternative, not cumulative. A transfer is lawful if any one of them supports it, and we publish the one that holds today rather than the one we would like to have. We do not invoke contractual clauses under Resolution CD/ANPD nº 19/2024 for these transfers, because none are in force with these suppliers: a basis published without being verified would be a transparency failure under article 6, VI, in the one paragraph that exists in order to be precise.

We record, for transparency, a point that choosing a region does not resolve: cloud suppliers are foreign companies, and remote administrative access from abroad, under those suppliers’ own contracts, may constitute processing outside the national territory. We prefer to state it rather than omit it.

15.Where the data lives, and whether it can be restored

• •Applications and the shared PostgreSQL database run on a single virtual machine in Google Cloud's southamerica-east1 region, in São Paulo.
• •Files products store — vehicle photographs and documents, registration paperwork, clinical media, PDF dossiers — are in Amazon S3, region sa-east-1, in Brazil.
• •Backups of every database are taken daily to Amazon S3, region sa-east-1, under a 30-day lifecycle rule, separate from the production environment.

Restorability is evidenced, not asserted. A backup nobody has restored is a file, not a backup, so we run restore drills into a throwaway database and record the result with a date. The drill of 7 September 2026 restored GerTruck’s latest dump and validated it: 40 tables, 6,948 rows, foreign keys intact.

16.Security

The measures below are the ones we can point at. We describe what exists, not what a security section usually says.

• •All traffic is carried over TLS: browser to application, application to supplier, and every call to Meta's Graph API.
• •API keys are stored only as a hash. Only the hash is persisted, so the key itself cannot be recovered from our database, and a lookup compares hashes.
• •Passwords in the products are stored only as hashes, never in readable form, and single-use verification codes are stored as hashes with a short validity and an attempt limit.
• •Every callback from Meta is verified by HMAC over the exact bytes received, compared in constant time, and the verification fails closed: an unsigned request, a wrong signature or an empty app secret rejects everything, and the rejection happens before anything is written to the database.
• •Each application connects to PostgreSQL as a dedicated least-privilege role that owns only its own database, with connection revoked from PUBLIC. Never as the database superuser.
• •Recipient addresses are masked when read for support: a phone number keeps only its last four digits and an e-mail keeps at most two characters of its local part. The same masking is applied inside free text, because a provider's error message quotes the number or the address verbatim.
• •Access is controlled by role, and the products keep an append-only audit trail of relevant actions, including access to personal data.
• •Databases are backed up daily, in Brazil, with dated restore drills as described in section 15.

The Client’s access token

The token is never returned by any API response and never written to any log. That is not a policy statement resting on discipline: the response shape our API publishes has no field for it, and a compile-time contract check fails the build if the shape our code returns stops matching the shape we published. The token leaves our service in exactly one direction, as an authorization header to Meta.

No method of transmission over the internet or of electronic storage is absolutely secure, and no system is wholly immune to incidents. Faced with a security incident that may bring relevant risk or harm, we act under the LGPD and Resolution CD/ANPD nº 15 of 24 April 2024. Where the incident reaches data we process as operator, we inform the controlling Client without undue delay, with the elements we hold, so that it can assess the risk and meet its own duties; notifying the national authority and the affected data subjects is then the Client’s responsibility as controller, and we cooperate technically. Where the incident reaches data of which we are controller, that duty is ours and we will meet it without undue delay.

17.How to ask us to delete data

The instructions, in one screen, with no login and no form, are at /legal/data-deletion. In summary: write to privacy@gango.tech with the words “data deletion”, the phone number in international format, and the name of the business if you know it. Do not send documents, card numbers or identification numbers — we never ask for them.

We acknowledge on receipt and answer within five business days, whether the answer is that it is done or a reasoned statement of what cannot be done and why. The rights differ materially depending on who is asking, so the deletion page separates three cases:

• •A WhatsApp end user. We know you by a phone number and nothing else. We stop messaging you — an objection is checked at delivery time, so it catches even messages already queued — and we erase the number and the content from the delivery log, leaving the delivery record. We cannot delete a message from your phone, from Meta, or from the business that messaged you: that business is the controller, and we forward your request to it within five business days and support it technically.
• •A Client business. Disconnecting a number deletes our copy of the token; it stays valid at Meta until you revoke it in Business Manager yourself. Tenant deletion is a manual procedure within five business days — GerTruck has no automatic purge and no tenant-delete code path, and we say which of the two applied to your request.
• •A data subject exercising article 18. The answer is per product, because the products differ: Ternavi has anonymisation and export that a clinic runs on the spot, with the limits in section 13; for GerTruck the truck center is the controller and we forward within five business days, applying the retention criteria in section 13 to whatever remains with us.

18.Reporting a security vulnerability

If you have found a vulnerability in our software or in this site, write to security@gango.tech. Please include what you did, what you observed and anything needed to reproduce it.

• •We acknowledge receipt and tell you what we found. We do not require prior authorisation for good-faith research, and we will not pursue a reporter who acts in good faith.
• •Please do not access, alter or exfiltrate data belonging to anyone else, and do not degrade the service. If you encounter personal data, stop and tell us instead of collecting it.
• •Please give us a reasonable period to fix the issue before disclosing it publicly.
• •We do not run a paid bounty programme. We do credit a reporter who asks to be credited.

A report that concerns the WhatsApp channel specifically — abuse of a number we operate, messages you believe were sent without a lawful basis — reaches the same address, and we treat it with the same clock.

19.Children and adolescents

Our products are contracted by businesses and are not directed to children or adolescents. We do not knowingly process the personal data of a child, and we collect nothing for that purpose. Where a child’s data does appear in a Client’s records, the Client is the controller and article 14 of the LGPD applies to that Client, with its best-interest standard and its requirement of specific consent by a parent or guardian.

20.Changes to this policy

This policy is versioned and dated: it is version 1.0, last updated 12 September 2026. The Portuguese version carries the same version and the same date, and a revision that landed in only one of the two would be two documents in force rather than one.

• •A new supplier, a new destination outside Brazil, or a change in what an existing supplier receives changes this policy BEFORE the change is deployed. That ordering is the rule, not a courtesy: a policy updated afterwards documents that we knew and shipped anyway.
• •Relevant changes are communicated to Clients by e-mail or in the platform, and the date at the top of this document is updated.
• •We keep the superseded versions. Ask at the privacy channel for the wording in force on a given date, and we will send it.

21.Complaints

Three channels, and they are not alternatives to each other in every case:

• •Us. privacy@gango.tech, for anything in this document and for any data of which we are controller under section 3.
• •The Client. Where the Client is the controller — everything a truck center holds about its customers, everything a clinic holds about tutors and patients — the complaint belongs with that Client, which publishes its own channel. If you send it to us, we forward it within five business days and support the Client technically; we do not answer on the merits in that Client’s place.
• •The ANPD. You may lodge a complaint with Brazil’s National Data Protection Authority at any time, under article 18, §1 of the LGPD. You do not have to come to us first, and doing so does not waive anything.

Disputes about this policy are governed by Brazilian law, with the courts of São Paulo, State of São Paulo, Brazil as the agreed forum, on the terms and with the qualification stated in the Client Terms. Nothing here restricts a data subject’s right to go to the authority or to a court.