Goro Privacy Policy

Effective date: 2026-08-01 Last updated: 2026-08-01

This policy describes what the Goro gateway does with personal data. Every factual claim in it was checked against the running code and the live database on 2026-08-01. Where something is not enforced by code, or is not known, this document says so rather than rounding it up.

1. Who we are

Goro is a pay-per-call gateway that lets software agents call third-party data tools through a single account, a single API key and a single prepaid balance. It runs at usegoro.ai, app.usegoro.ai, api.usegoro.ai, mcp.usegoro.ai and docs.usegoro.ai.

The controller for the personal data described in section 4 of this policy is:

PROMPTIFY S.R.L. Strada Prof. Nicolae Oblu, Nr. 24A, Bloc B2A, Etaj 2, Ap. 22, Municipiul Iasi, Judetul Iasi, Romania Trade register number: J22/1745/06.06.2023 Company registration number (CUI): 48270068 EUID: ROONRC.J22/1745/2023 VAT number: RO48310979

Note that the VAT number is not "RO" plus the company registration number, which is the usual Romanian pattern. Both numbers are correct as written.

Contact for privacy matters: hello@usegoro.ai

Data protection officer. We have not appointed one. Article 37(1)(b) makes a DPO mandatory where core activities consist of regular and systematic monitoring of data subjects on a large scale, and at current volume this service is not operating at that scale. That is the only thing carrying the answer. The catalog is largely people-data endpoints, which is exactly the fact pattern Article 37(1)(b) is tested against, so this position depends on volume and not on product shape, and it is revisited as volume on those endpoints grows.

Because PROMPTIFY S.R.L. is established in Romania, the GDPR (Regulation (EU) 2016/679) applies directly, and the Romanian supervisory authority is the ANSPDCP.

2. The two data relationships. Read this section first.

Goro touches personal data in two completely different ways, and they carry completely different responsibilities. Conflating them is the single biggest way to misunderstand this service.

Relationship A: data about you, our customer

When you create an account, top up a balance, create an API key or call the API, we process personal data about you. Your email address, your workspace, your API key metadata, your billing records, your usage history.

For this data, we are the controller. We decide why it is collected and how it is used. Section 4 covers it. If you want your own data corrected, exported or deleted, section 9 is yours.

Relationship B: data you collect about other people, through us

Goro's catalog was 56 endpoints on 2026-08-01, 53 of them callable, and most of them retrieve data about people. LinkedIn profiles, LinkedIn people search by first and last name, employees of a named company, X follower lists, Instagram and Facebook and TikTok posts and comments, Reddit authors, YouTube commenters, Amazon reviewers, Google Maps listings and reviews, and a prebuilt EU Amazon seller contact database. Section 5 lists the endpoints that carry the highest personal-data exposure.

When you call one of these, you choose the target, the purpose, the volume and the fields. We validate your input against the endpoint's published schema, fill in any defaults that schema declares, and pass the result to the execution provider. We do not narrow your query, we do not filter the result, and we do not check who you are looking up or why. The provider's results come back to you as they arrived.

About those defaults, because it matters and it is easy to skip. Our validator runs with schema defaults enabled. A field you leave out is filled with the default our schema declares, and the filled copy is what goes upstream. On some endpoints that default decides how much personal data comes back. twitter.followers defaults getFollowers to true and returns 200 followers as its floor. The LinkedIn people-search endpoints default profileScraperMode to Short, which is the least revealing of the three modes, but it is still our choice and not yours. inspect shows you every default before you run anything. Calling an endpoint without overriding a default is an instruction to use that default. That is the honest construction and it is the one that keeps the roles below intact. It is not a strong construction.

Our position on this data. For the content of your run inputs and run outputs, Goro acts as a processor on your behalf. You are the controller. You determine the purposes and means. We process only on your instruction, and your API call is that instruction.

What that means for you, in plain terms:

You need a lawful basis under Article 6 for every person you collect data on. We do not have one for you and we cannot supply one. "The data was public" is not a lawful basis under the GDPR. Nor is "the tool let me."
You are responsible for Article 14 notice. When you obtain personal data from a source other than the data subject, you generally have to tell that person, within a month, that you hold their data, why, and what their rights are. Nobody in this system does that for you. Goro does not contact the people in your results, and it has no way to. Failure to give Article 14 notice is the single most commonly enforced failure in this exact business model.
You are responsible for handling requests from the people in your results. Access, erasure, objection, all of it. Those requests come to you, not to us. If one reaches us, we will route it to you as described in section 10.
You are responsible for special category data. Some endpoints can surface data revealing health, religion, politics, trade union membership or sexual orientation, whether or not you were aiming for it. Public group membership, post content and profile detail all do this. Article 9 applies and its conditions are narrow.
Direct marketing off this data is not merely your risk, it is prohibited. The Acceptable Use Policy at https://usegoro.ai/legal/acceptable-use, clause 6, bans cold email, SMS, DM and automated connection campaigns built on contacts obtained through Goro, and clause 2 bans assembling, enriching, licensing or reselling personal data obtained through Goro. Do not read this policy as saying you may do those things provided you handle the ePrivacy rules yourself. You may not do them at all. Where you have a permitted use that still involves contacting a person, the ePrivacy Directive and its national implementations apply on top of the GDPR, and satisfying them is yours.
A Data Processing Agreement applies to you. It is published at https://usegoro.ai/legal/dpa, it is incorporated into the Terms of Service, and it takes effect when you accept the Terms or first send personal data through the Service, whichever is earlier. It is the Article 28 contract that makes this a processor relationship rather than a compliance hole. Nobody signs a separate copy of it, and there is no signature workflow in the product.

Where our processor claim is weakest, stated honestly. We are not a neutral pipe in every respect. We choose which endpoints exist in the catalog. Our schemas fill in defaults, and on some endpoints those defaults change how much personal data a call collects. We hold the results in our own database for up to 24 hours. And when a complaint arrives we read the results of the runs in question, not only the metadata. A regulator could look at those four facts and conclude that we are a controller, or a joint controller, of the scraped data rather than a processor of it.

We are not drafting around that. This policy records the position we take and the reasons it is contestable, and it does not bind a supervisory authority or a court. If the answer turns out to be joint controllership, the Terms, this policy, the Acceptable Use Policy and the Data Processing Agreement all move together, and we will publish the change here.

One thing that used to weaken the claim much further no longer does. Article 28(3)(g) requires a processor to be able to delete the personal data it holds at the end of the service. For run data we now can, and by default we already do: run inputs are never stored, and run outputs are deleted within 24 hours whether or not anyone asks. Section 6 has the detail. What we still cannot do on a button is close an account and erase the account record itself, and section 9 says so plainly.

Everything below applies to Relationship A unless it explicitly says otherwise.

3. Who this service is for

Goro is a business service, sold to companies and to developers acting in a professional capacity. It is not designed or marketed for consumers, and it is not for anyone under 18. We do not knowingly collect personal data from children.

We do not check this at signup. There is no age gate and no eligibility check in the signup flow. Anyone with a Google account or a working email address can create a workspace and pay. So the business-use statement in the Terms is a warranty from you, not a control on our side. If you are in fact a consumer, the mandatory consumer law of the country you live in applies to you whatever the Terms say, and Terms section 7.4 says the same thing.

4. Data we collect about you, and why

4.1 Account and identity

What. Your email address, and the Supabase Auth user record created for you. Sign-in is either Google OAuth or an emailed one-time code. We never see or store a password. On first sign-in we create one workspace for you, holding your user id, a display name derived automatically from the local part of your email address, and later your Stripe customer id.

If you sign in with Google, the authentication record also holds the identity fields Google returns for that account. We request no scopes beyond the basic ones, so that is limited to your Google account identifier, your email address and whether Google has verified it, and the basic profile information Google attaches to a sign-in, such as your name and profile picture. We do not ask Google for anything else, and we do not read your Gmail, your contacts, your calendar or your Drive.

Why. To create your account, authenticate you, and attach your balance and usage to you. One workspace per user is enforced at the database level.

Legal basis. Article 6(1)(b), performance of the contract you asked us to enter into.

4.2 API keys

What. When you create an API key we show you the raw key once and never store it. We keep a SHA-256 hash of it, the first 12 characters for display, an optional label you choose, the creation time, the last time it was used, the revocation time if you revoked it, and the rate limits that apply to it.

Why. To authenticate your calls, apply rate limits, and let you manage and revoke keys. Lookup happens by hash, so a database breach does not hand an attacker usable keys.

Legal basis. Article 6(1)(b), and Article 6(1)(f) for the security benefit of hashing.

4.3 Run inputs

What. Nothing. We do not store run inputs.

Your input is passed to the third-party execution provider and nowhere else. It exists in our systems only for the moments it takes to validate it, price the call and hand it over.

This was previously the most sensitive thing we held: looking up a named person put that person's name, profile URL or email address into our database as part of your run record, unredacted. That column no longer exists, and an automated test fails if anyone adds it back.

There is now exactly one exception, and it is a file rather than a field. The video endpoints can animate a starting image, and you may send that image inline instead of as a link. When you do, the file itself is written to a private store for as long as the generative provider needs to fetch it, and no longer. It is the only input this Service stores anywhere, and section 4.16 sets out what happens to it. Everything else in this subsection is unchanged: no run input is written to our database, and there is still no column that could hold one.

Why. Not applicable. We record which endpoint ran, what it cost, how many rows it returned and when. Not what was asked.

Legal basis. Not applicable to the input itself. Our lawful basis for the run record we do keep is Article 6(1)(b) and Article 6(1)(f).

4.4 Run outputs

What. The rows a run produced, held only until you collect them, and in no case longer than 24 hours. For voice.speak this also covers the audio file itself, which is generated speech rather than a database row.

This is the most sensitive category in this policy, so it is worth being exact about. Results are held for handover, not kept. A run's rows are written to our database when the run finishes, and are deleted:

shortly after your first successful fetch of them, or
24 hours after the run finished, whichever comes first, collected or not.

A scheduled job enforces both. It runs inside the database every ten minutes, and the 24 hour ceiling is a deadline stored on the row itself rather than a rule that only exists in application code, so a bug in the application cannot quietly turn this buffer into permanent storage.

Generated audio is a second system, on the same deadline. voice.speak returns speech as a file, not as a row, so the audio is written to a private file store and handed to you as a link that expires. It is worth naming separately because it is a different system with a different failure mode, even though it holds the same data under the same rule: the file store has no database deadline behind it, so its deletion is enforced by a scheduled job alone. That job deletes an object once you have collected the run, and sweeps the store for anything older than 24 hours regardless of what the run record says, so an object cannot survive a lost or broken run row. The link expires on the same 24 hour clock, so it stops working at the moment the file goes. Nothing in the store is publicly readable: every link is signed and time limited, and there is no unsigned address that would work.

The deletion job for generated audio runs every ten minutes, on the same clock and from the same scheduler as the database purge, so the rows and the audio files disappear together rather than on two different rules. A second, daily run is scheduled independently as a backstop, so a failure of the primary scheduler still bounds retention rather than leaving it unbounded.

Two separate things have to be true for this claim to hold, and both are: the signed link expires on the 24 hour clock, which bounds who can reach an object, and the job deletes the object itself. Expiry alone is not deletion, and this paragraph should not be read as claiming otherwise.

Why it works this way. Slow endpoints do not return inside a request. Your agent starts a run, gets a run id and polls for the result. That handover needs somewhere for the rows to live in the meantime. Previously we held nothing and re-read the execution provider's copy on each poll, which meant that whenever that copy was unavailable a caller who had already paid received a row count and no rows. Holding the result briefly is what makes a paid run reliably collectable.

What this means for you. We can produce your results only inside that window, so keep anything you need. If you want a result gone sooner, fetch it: collection is what triggers deletion.

Retention. Until collected, then a short grace period for retries. 24 hours maximum in all cases.

Legal basis. Article 6(1)(b): delivering the result you paid for is the contract. The window is the shortest one that makes delivery reliable. For scraped personal data inside a result, you are the controller and we act on your instructions as processor, as set out in section 2.

One thing the 24 hour rule does not cover. A voice model created by voice.clone is not a result and is not deleted on this clock. It is the only durable object the Service produces, it is kept until you delete it or until the workspace that owns it is deleted, and the recordings you supply to create it are the most sensitive input the catalog accepts. Section 4.14 covers both, and it is the section to read next.

4.5 Run metadata

What. For each run: the workspace, the endpoint slug, the status, how many items came back, the quoted and final cost, the provider's run id, any error, and the created, started and finished timestamps. It contains nothing that came back from the provider except the count of it.

Why. Billing, your usage dashboard and CSV export, support, capacity planning and abuse detection.

Legal basis. Article 6(1)(b) for the service and billing, Article 6(1)(f) for abuse detection.

4.6 Wallet and ledger

What. Your balance and promotional credit, and an append-only ledger of every movement: credits, holds, captures, releases, refunds, promotional credit, each with an amount, the run or Stripe reference it belongs to, the balance after it, a note recording the promotional and cash split, and a timestamp.

Why. This is the money record. It is what makes "failed calls are not charged" auditable rather than a marketing claim, and it is our accounting record.

Legal basis. Article 6(1)(b) for the service, Article 6(1)(c) for the statutory obligation to retain accounting records.

4.7 Payment data, saved cards and automatic top-ups

What. Your Stripe customer id and the references to your checkout sessions and payment intents.

We never see or store your card number. Checkout is hosted by Stripe on Stripe's own pages. The card details go from your browser to Stripe and never pass through our servers.

Your card is saved. Every top-up checkout session is configured so that Stripe saves the card against your customer record for later off-session use. This happens on every top-up, not only the first, and it happens whether or not you ever switch on automatic top-ups. The card is held by Stripe, never by us. There is no self-serve way to remove a saved card. Email hello@usegoro.ai and we will remove it.

Automatic top-ups exist and can charge that saved card without you present. The rule is off until you turn it on. You turn it on yourself, on the Wallet page, and you set both numbers: the balance that triggers it (at least $5) and the balance it tops you back up to (at least $10 above the trigger). It cannot be enabled without a saved card. Once it is on, a run that leaves your available balance below your trigger causes a charge to that card for the difference, without any further prompt. You can turn it off in the same place at any time.

Two things about it we would rather you learned here than from a statement. We do not send you anything before or after an automatic charge, because the product has no outbound email at all. And the charge appears on your card as a Goro wallet auto-reload. Your ledger records it like any other credit.

Legal basis. Article 6(1)(b) for taking payment and for carrying out the automatic top-up rule you configured, Article 6(1)(c) for tax and accounting records.

4.8 Discovery telemetry

What. When you use discover and nothing in the catalog matches well enough, we store your raw free-text search query along with your workspace id and the best score we found.

Your query text is stored as you typed it. If you searched for a person by name, that name is stored.

Why. Misses tell us which capabilities to add next. This is the only product analytics we run.

Retention. 90 days, then deleted by a scheduled job in the database. We chose deletion over scrubbing or hashing because a hashed query cannot be read by the person deciding what to build, which is the only reason the row exists.

Legal basis. Article 6(1)(f), our legitimate interest in knowing what our customers cannot find. You can object under Article 21. See section 9.

4.9 OAuth and MCP records

What. Two different things, and the difference matters.

For authorization codes and access tokens issued against your account, we store only hashes, along with scopes, expiry, the bound resource and which API key authorised the session. Expired codes and tokens are deleted by a scheduled job that runs daily.

Separately, our MCP server implements open dynamic client registration (RFC 7591). Any client that connects can register itself without signing in, and we store the client id it was issued, the client name it supplied and its redirect URIs. These records are not linked to any account, so they are not attributable to you and cannot be deleted as part of your data. They can be created by anyone who can reach the endpoint, and we rate limit registration by IP address and store nothing else about the registrant.

These registration rows are kept indefinitely, on purpose. A registration is what a connected client presents every time it refreshes, so ageing one out breaks a working connection with no way for the client to tell why. The row holds a client id, a self-chosen client name and redirect URIs, and nothing else.

Why. To operate the remote MCP server securely and let you revoke access.

Legal basis. Article 6(1)(b) and Article 6(1)(f).

4.10 IP addresses, device and session data

What. When you sign in, our authentication provider records the IP address and browser user agent of the session, and keeps an authentication audit log that also records IP addresses. This data sits in our own database, not only in a hosting provider's logs. We also process the IP address of unauthenticated requests to the OAuth registration and authorization endpoints, in memory, to apply a rate limit.

Why. To keep you signed in, to let you and us see where an account was accessed from, and to blunt automated abuse of the endpoints that do not require a login.

Retention. Set by our authentication provider's own defaults. Nothing in our code prunes these tables, and Those defaults are set by the provider rather than by us, so section 6 names the provider as the owner of that window rather than stating a number we do not control.

Legal basis. Article 6(1)(b) for delivering the sign-in you asked for, Article 6(1)(f) for security and abuse prevention.

4.11 Logs

What. Server logs from our hosting provider containing request metadata, IP addresses, run ids, endpoint slugs, provider run ids, cost figures and Stripe session ids.

No part of our code writes run input content or run output content to a log. Every deliberate log line in the codebase was read and none of them carries the content of what you sent or what came back.

That is a statement about the code we wrote, and it is narrower than "your data can never appear in a log". Our routes funnel unexpected failures through a single catch-all that logs the error object it was handed. An error thrown by a library or by an upstream provider can carry its own context, and we do not inspect or strip it before logging. We do not know of a path today where that context includes run content, and we have not proved that none exists. The hedge is the true version, so the hedge is what is published.

Why. Debugging, security, uptime and abuse investigation.

Legal basis. Article 6(1)(f).

4.12 Cookies

We set only the cookies needed to keep you signed in to app.usegoro.ai. They are session and refresh cookies set by our authentication provider.

We run no analytics scripts, no advertising pixels and no third-party trackers on the app or on the landing site. Neither codebase depends on an analytics, error-reporting or tracking package. We checked the live responses from usegoro.ai and app.usegoro.ai on 2026-08-01, including the sign-in page, and no cookie is set before you sign in, by us or by our hosting provider. Because the sign-in cookies are strictly necessary to deliver a service you asked for, no consent banner is required for them. If we ever add analytics, this section changes and a consent mechanism goes up first.

4.13 What we do not do

We do not sell your personal data. Plain meaning: we do not hand your account, billing or usage data to anyone in exchange for money or anything else of value, beyond the subprocessors in section 7 who are paid to run the service. "Sale" is also a defined term in some US state laws, and section 13 explains how that reads here.
We do not use your run inputs or run outputs to train models.
We do not use your run inputs or run outputs for our own purposes, or aggregate them across customers, or resell them.
We do not send marketing email. Today we send no email at all except sign-in codes.

The third and fourth bullets are commitments, not enforced controls. Our server code runs with a database key that bypasses row level security, which is normal for a service backend and also means an operator with that key can read any workspace's stored run outputs during the window they exist. There is no audit log recording when that key is used. We mean the commitment, and Terms section 13 and the DPA make it contractual, but you should know that what stops it is a promise rather than a mechanism.

4.14 Reference audio and cloned voices

Numbered 4.14 and placed after the other run categories rather than beside them, because the Data Processing Agreement and the sections below cite these subsection numbers by hand. Read it directly after 4.4.

Read this one even if you skim the rest of section 4. Every other category in this policy is data we receive about people because you asked us to retrieve it from somewhere it was already published. This is the only one where you upload a recording of an identifiable person, so that a machine can reproduce their voice. It is the sharpest thing in the product and it is not comparable to a scraped profile.

What. When you call voice.clone, you give us up to 20 web addresses. We fetch the audio at those addresses and pass it to our voice provider, which builds a reusable voice model from it. A recording of a person speaking identifies that person, and the model built from it can speak as them.

What we store, exactly. Not the audio. The recordings exist inside our infrastructure only in memory, for the seconds it takes to fetch them and hand them on, and are never written to our database or to our file store. We do not keep the addresses you gave us either. What we keep is one row per voice: your workspace, the provider's id for the model, the label you chose, how many samples it was built from, and the consent statement you attested to with the timestamp you attested it.

What our voice provider stores, which is the part that matters. The voice model itself, held under Goro's account indefinitely, until you delete it. It is the only durable thing the Service produces: every other call is stateless and leaves nothing behind. Deleting it with voice.delete, or from the Resources page in the app, removes it at the provider and not only from our records. There is no expiry: a voice that expired on its own would not be a reusable voice, which is the point of having one.

Two things do delete it without you asking, and both exist because "until you delete it" is not a promise we could keep otherwise. Deleting your workspace deletes its voices at the provider. So does the loss of the record that connects a voice to you, however that happens. A daily job reconciles what the provider is holding against what our own records still account for, and deletes anything the records no longer do. This closes a gap that would otherwise be permanent: a voice model is stored under our account, not yours, so if the row naming it as yours disappeared we would have kept a recording-derived model of a real person with nothing left that could ever identify it for deletion. Every model we create is tagged at the provider so it can be found again, and the job only ever deletes models carrying that tag.

Reference recordings. Fish Audio builds the voice model from the recordings you supply and we do not retain them. The recordings are fetched, held in memory for the length of the request, and passed to the provider. Nothing writes them to our database or our storage.

Consent, and what our consent flag is and is not. voice.clone refuses to run unless you set consent_attested to true on that call. There is no default and it is not remembered between calls. What you are attesting is stated on the field itself: that the person whose voice the recordings capture has given documented consent to have their voice cloned and synthesised for this use, and that you can produce that consent if we ask.

That flag is a record of what you told us. It is not verification. We cannot hear who is in an uploaded file and we do not try to. Nothing checks whether the consent exists, whether the speaker is who you say they are, or whether the recording is of a real person at all. It exists so that there is a timestamped record of the claim you made, which we will produce if the person whose voice was cloned comes to us, and act on under the Acceptable Use Policy.

Isolation. A cloned voice belongs to the workspace that created it and cannot be used by any other. A voice id from a different workspace is refused exactly as one that does not exist, so no customer can use, list, delete or even confirm the existence of another customer's voice. This is enforced in our own database on every call, because the provider cannot enforce it: from its side every voice on the account is Goro's.

Retention. Reference audio: not retained by us at any point. The voice model: until you delete it, or until the workspace that owns it is deleted, whichever comes first. The ownership and consent row: kept while the voice exists. When a voice is deleted because its workspace was, we keep one record of the deletion itself (the provider's id for the model and the id of the workspace that owned it, and nothing else) for as long as it takes to confirm the model is gone at the provider. That record is what makes the deletion possible, and it carries no recording, no label and no consent text.

Legal basis. Article 6(1)(b), delivering the capability you paid for. For the person whose voice is cloned, you are the controller and their consent is yours to obtain and to evidence, as set out in section 2. If the model amounts to biometric data in your use of it, Article 9 applies to you as well as Article 6. Nobody has given us advice that the attestation flag discharges anything on our side. It ships because it is better than nothing.

4.15 Budget rules and automatic top-up settings

What. If you set a daily or monthly spending cap, we store the workspace it belongs to, the period, the amount and whether it blocks or only notifies. If you configure automatic top-ups, we store the workspace, whether the rule is on, the trigger and target amounts, the Stripe payment method id, and the outcome of the last attempt.

Why. To apply the rules you set.

Legal basis. Article 6(1)(b).

4.16 Input images for image-to-video

Numbered 4.16 and placed at the end for the same reason 4.14 sits where it does: the sections below and the Data Processing Agreement cite these subsection numbers by hand. Read it directly after 4.3, which it is the only exception to.

What. The video endpoints can animate a still image rather than generate from a prompt alone. An image you choose to animate is very often a photograph of a person, so it is a category of personal data in its own right and not a variation on a prompt. There are two ways to supply one and they differ in what we hold, so they are described separately.

A link. You give us a public http or https address and we pass that same address to the generative provider. We fetch it once ourselves first, to check that what is there really is an image and is not enormous. Those bytes exist in our infrastructure only in memory, for the length of that check, and are never written anywhere. We do not keep the address either. An image you have already published stays exactly as published, and we do not make a second copy of it.

The file itself, sent inline. You send the image's own bytes with the call. We write them to a private storage bucket, hand the provider a link to that object which is signed and expires, and delete the object on a schedule. This intake exists because the alternative was worse. Without it, an agent holding a photograph on a laptop had to publish that photograph to a public file host to produce a link the model could read, which creates a permanent, world-readable copy of someone's picture purely to satisfy an API. Nothing here is published: the bucket has no public read, there is no unsigned address that works, the object's name is random and per-workspace, and the only link that exists is unguessable and time limited.

Retention: 30 minutes, not 24 hours. The link is signed for 30 minutes and a scheduled job deletes the object on the same clock, sweeping the bucket by age every ten minutes. Nothing about the object is derivable from your run record, deliberately, so the sweep reads the bucket itself rather than working backwards from a run. Thirty minutes is the longest any video run in the catalog may still be waiting for the provider to start the generation that reads the image, which is the last moment it can be needed; past that we have already abandoned the run. In practice an object lives for the length of one generation, and the worst case is 30 minutes plus the ten minute gap between sweeps.

What the provider receives. The signed link, and through it the image. For the link intake it receives your original address instead. Either way the generative provider fetches the image and, as section 7 says of everything else it returns, holds what it generates on its own storage under its own retention.

What we check before any of this. The file has to be a JPEG, PNG or WEBP, decided by reading the file's own leading bytes rather than by any type you declare, and it has to be within a size limit. A file that is not an image is refused before anything is stored or sent.

Retention. Link intake: not stored at any point. Inline intake: 30 minutes maximum, and normally the length of one generation. We keep no record of the image, its name, its address or its content afterwards.

Legal basis. Article 6(1)(b), delivering the capability you paid for. For a person in the photograph, you are the controller, as set out in section 2. A photograph of an identifiable person is personal data whether or not the endpoint knows it, and if you use it in a way that makes it biometric data, Article 9 applies to you.

5. Endpoints that carry personal data

Most of the catalog returns data about identifiable people. The endpoints below carry the highest exposure. This list is here so you cannot say you were not told.

Being told is not the same as being allowed. The Acceptable Use Policy sets hard conditions on every endpoint in this section, including a ban on building or selling people datasets out of the results, a ban on marketing to contacts found through them, and a requirement that you can state your lawful basis in one sentence if we ask. Read it before you call any of them.

The counts below were true on 2026-08-01. The catalog changes, and the live catalog in the app is authoritative.

Professional profiles and contact discovery. Seven LinkedIn endpoints. Full profile records including work history, education, skills and, where the provider can resolve one, an email address or phone number. linkedin.profile in particular takes profile URLs only, has no privacy switch of any kind, and its published output includes an email address and a mobile number whenever the tool can resolve them. People search by first and last name with filters for location, employer, school, job title and industry. People search by free-text service description. Employee lists for a named company, filterable by title, seniority, function, location and tenure, which in practice builds an org chart with contact details. On those three search endpoints the amount of profile detail is a mode you choose. It defaults to the least revealing one, and a "full + email search" mode is available if you select it. A named individual's posts, with the identities of people who reacted and commented available as a paid extra. Post search by keyword and author. Job postings, which can name a hiring contact. Several of these return up to 1,000 profiles per call.

Social graphs and social content. The complete follower list, and optionally the following list, of an X account, with handle, display name, bio, location, counts, verification status, join date and profile image. The follower list is returned by default and the smallest request the tool accepts is 200 followers. X profiles by handle, up to 50 handles a call, returning display name, bio, location, website, follower and following counts, tweet and media counts, verification status and type, whether the account is protected, join date, and profile and header images. Tweet search by advanced query, which can be pointed at one named person. Instagram profiles, posts, hashtag feeds with author handles, keyword search returning profiles and places with addresses and coordinates, and any public Instagram URL including comments. Facebook page details including a contact email, public profile and page feeds with resolved profile identities, comments and threaded replies with author name and profile, public group posts, reviews with reviewer identity, and events with venue address, organisers and attendance counts. TikTok profiles and posts. Reddit posts and comments with author usernames. YouTube comment authors and comment text, plus channel data and full spoken transcripts.

Commerce and location. An EU Amazon seller contact database, explicitly a lead product rather than a live scrape, returning business name, business type, registration and VAT number, email address, phone number and business address, filterable by member state. Amazon reviews with author name, rating, text, date and attached media, across 20+ regional domains including EU ones. Google Maps places with name, address, phone, website and coordinates. Google Maps reviews, which do carry the reviewer's identity: the endpoint's published output includes the reviewer's display name, their Google profile URL, their reviewer id, their local guide status and their total review count, alongside the review text, rating, date and any photos they attached.

Generic search. Web search and news search are generic, but a query for a person's name returns that person's data.

Generative endpoints, which are a different shape of risk. The image and video endpoints take a prompt you write. A prompt is free text and can name or describe a real person, so it can carry personal data even though the endpoint is not a people-lookup tool. The video endpoints go further: every one of them can take a starting image to animate, and an image someone wants animated is very often a photograph of a person. That image can be a link, or the file's own bytes sent inline, and the inline form is the only input this Service stores anywhere. Section 4.16 covers it. What comes back is a file hosted by the generative provider, and section 7 explains that the provider keeps it for longer than we keep anything.

Voice, and it does not belong in any of the groups above. voice.transcribe takes a recording you supply and returns the words in it, so it carries whoever is speaking. voice.clone goes further than anything else in the catalog: you upload recordings of an identifiable person in order to build a model that speaks as them. It is the only endpoint where the personal data comes from you rather than from a platform, the only one that produces something durable, and the only one that requires an explicit consent attestation before it will run. Section 4.14 covers it in full and the Acceptable Use Policy clause 10 sets the conditions.

Three points about this list.

Pseudonymous is still personal. A Reddit username plus that account's posting history is identifying, and it can reveal special category data.
Business contact data is often personal data. For sole traders, one-person sellers and home-based businesses, the "business" address, phone and email are a person's address, phone and email. This applies to most of what the EU Amazon seller endpoint returns.
Group membership, likes and follower graphs are inference-rich. They can reveal health conditions, religion, politics and sexual orientation whether or not that was your intention. Article 9 does not care about your intention.

6. How long we keep things

The table below is what the code does, not what we intend. Where a period is enforced by a scheduled job, it says so and names the cadence. Where nothing enforces it, it says that too, in the same column, because a retention period nobody enforces is worse than no stated period at all.

Data	How long	What enforces it
Run inputs	Never stored	The column does not exist. An automated test fails if anyone adds it back
Run outputs	Until you collect them, and never more than 24 hours	A database job every ten minutes, against a deadline stored on the row itself. Enforced in the database rather than only in application code
Generated audio (`voice.speak`)	The same rule: until collected, never more than 24 hours	A scheduled job every ten minutes, on the same clock as the database purge, deleting the object from the private file store and sweeping the store by age so an object cannot survive the loss of its run row. A second daily run as an independent backstop. The signed link expires on the same clock
Input images sent as a LINK to a video endpoint	Never stored	The image is fetched, held in memory for the length of one type and size check, and the link is passed to the generative provider. Nothing writes the bytes or the address to our database or our file store
Input images sent INLINE to a video endpoint	30 minutes	A scheduled job every ten minutes, the same job and the same cadence as the generated-audio sweep, deleting by age from the private bucket. The signed link expires on the same 30 minute clock. Nothing about the object is derivable from the run record, so the sweep reads the bucket rather than the runs. See section 4.16
Reference audio submitted to `voice.clone`	Never stored	The recordings are fetched, held in memory for the length of the request, and passed to the voice provider. Nothing writes them to our database or our file store, and we do not keep the addresses either. What the provider does with them afterwards is a separate question, marked as set out in section 4.14 and section 7
Cloned voice models	Until you delete them, or until the workspace that owns them is deleted. No expiry beyond that, deliberately	`voice.delete` and the Resources page remove the model at the provider as well as here. A database trigger preserves the provider's id before our record can be erased, and a daily job deletes the model at the provider and reconciles its list against ours. Only models we created are ever selected, by a tag applied at creation
Discovery miss queries	90 days	A database job, daily
Expired OAuth codes and access tokens	Deleted after expiry	A database job, daily. Expiry stops them working immediately; the job is what stops them existing
Dynamic OAuth client registrations	Indefinitely	Nothing, deliberately. See section 4.9. These rows are not attributable to any account
Wallet and ledger entries	10 years from the end of the financial year in which the entry was made, the Romanian statutory accounting retention	Nothing automated. No job prunes them at any age. Ten years has not elapsed for any entry, so nothing is overdue, but deleting them when it does is manual work by a person and not a scheduled job
Run metadata (endpoint, status, costs, timestamps, error)	10 years, the same period, because it is part of the billing record	Nothing automated, same as the ledger. Run metadata carries no scraped content, which is why it can be kept this long without carrying the risk
Stripe customer id and payment references	The same as the ledger	Nothing automated on our side. What Stripe itself keeps is set by Stripe
Account, workspace, email, API key records	For as long as the account exists. Revoked keys are kept as revoked rather than deleted, so past runs stay attributable	Nothing automated, and there is no account closure flow. We delete an account by hand when you ask. See section 9
Sign-in sessions, which carry an IP address and a user agent	Until the session expires or you sign out. Our authentication provider's own defaults govern this	The provider. Nothing in our code prunes them. The separate authentication audit log is empty: that feature is not enabled on our plan, so no sign-in audit trail with IP addresses is being accumulated
Data held at the execution provider (the dataset or file your run produced)	Theirs, not ours	The provider. kie.ai states 14 days for generated media. Apify's dataset retention is set by Apify under our account's plan, not by us. Fish Audio's is set out in section 7
Server logs	Our hosting provider's own retention window, which it sets and we do not	The provider. We do not export, copy or retain them ourselves

Two things this table should not be read as saying.

Deleting our copy is not erasure of the data. The dataset your run produced also sits at the execution provider, on their clock, and our purge does not reach it. For the generative endpoints the file we hand you a link to is hosted by that provider for a stated 14 days, which is longer than we keep anything.

And we do not take our own database backups. Point-in-time recovery is a paid feature our database provider does not offer on the plan this project runs on, and we have not configured any separate backup of our own. Whatever internal copies our provider keeps for its own disaster recovery are outside our control and we cannot reach them to purge. We are telling you that rather than letting a retention table imply a completeness it does not have.

Why short retention on run outputs matters more than it looks. Every day a scraped dataset sits in our database is a day of exposure for people who never heard of Goro, never agreed to anything, and cannot come to us to get it removed because they do not know it is here. Short retention is the single strongest control available in this architecture, and it is the one this system leans on hardest.

7. Subprocessors

These are the third parties that process personal data on our behalf. The column that matters is what each one actually receives. This table is our subprocessor list. When we add or replace one, we publish the change here and the "Last updated" date changes with it, 30 days before the new subprocessor starts processing.

Subprocessor	Role	What it receives
Supabase	Database, authentication, file storage, access control. EU region (`eu-central-1`)	Everything we hold: your account and email, your workspace, your API key hashes, your wallet and ledger, your sign-in sessions including IP address and user agent, run outputs including all scraped personal data in them for the 24 hours they exist, generated audio files for the same period, and any starting image you send a video endpoint inline, for the 30 minutes set out in section 4.16
Apify	Execution provider for the scraping and search endpoints	Your run input, as validated and default-filled. Apify runs the tool and holds the resulting dataset on its own platform, under its own retention rules rather than ours. Note: every customer's runs execute under one single Goro platform token, so Apify sees Goro as its customer and does not see you
Third-party tool authors	The independent developers who publish the tools each Apify endpoint maps to. Roughly twenty across the catalog	Your run input, as processed by their code. Their code is what actually handles the data. They are hosted by Apify, so our contract runs through Apify, and we have no contract with any of them individually. We do not name them individually, because the mapping from an endpoint to the tool behind it is deliberately not published
kie.ai	Execution provider for the image and video generation endpoints	The prompt text you send, plus any generation parameters, plus the starting image where you give a video endpoint one. A prompt is free text and can name or describe a real person, and an image is very often a photograph of one. kie.ai fetches that image, either from the address you supplied or from the expiring private link we hand it, and it is subject to kie.ai's own retention rather than ours from that point. kie.ai returns a URL to media it hosts on its own storage and states a 14 day retention for that media, which is longer than Goro's own 24 hour ceiling, so a result URL can outlive our copy of the run. As with the other execution providers, every customer's calls run under one Goro account, so kie.ai sees Goro as its customer and does not see you. kie.ai publishes a 14 day retention for generated media, and its polling guidance says result URLs typically expire after 24 hours. Collect what you need inside 24 hours and the difference does not arise
Fish Audio	Execution provider for the voice endpoints only	For `voice.speak`, the text you send. For `voice.transcribe`, the audio file itself, which if it is a recording of a real person carries their voice, and a voice identifies a person. For `voice.clone`, the reference recordings you supply, plus the label you choose. This is the most sensitive thing any subprocessor in this table receives, because it exists so that a person's voice can be reproduced. As with Apify, every customer's calls run under one Goro account, so Fish sees Goro as its customer and does not see you, and every cloned voice on that account is Goro's from Fish's point of view, which is why the workspace boundary in section 4.14 is enforced in our database rather than theirs. Goro uses Fish Audio's paid synthesis models and its paid transcription model. Fish's note that requests may be used to improve model quality is published against its free model, which Goro does not expose. On that basis we do not treat submitted audio or text as retained by Fish Audio beyond the processing of the request. The cloned voice model is different and is retained by design: it is held indefinitely until deleted through `voice.delete` or the app, which deletes it at Fish and not only in our records. Deleting the owning workspace also deletes it at Fish, through a daily reconciliation job; models we did not create are never selected by it. We call Fish Audio's paid models. Its model-improvement note is published against the free model, which we do not expose. Audio and text submitted through these endpoints are processed to fulfil your request and are not retained by us
Stripe	Payments and hosted checkout	The email address and card details you enter on Stripe's own checkout page, plus whatever billing details Stripe requires for your payment method, and the amounts and references. We create a Stripe customer record carrying only your workspace id. We do not send Stripe the email address on your Goro account. Stripe receives no run data
Vercel	Hosting and DNS	Request metadata and server logs: IP addresses, timestamps, paths, run ids, endpoint slugs, cost figures. No code path of ours logs run input or output content
Google	Optional sign-in provider	The authentication handshake only, if you choose Google sign-in. No run data

On the third-party tool authors. Each Apify endpoint maps to a tool published by an independent developer, not by Apify and not by us. Their code is what actually processes your input and produces your results. Two positions are available on where they sit: either they are our subprocessors, in which case we owe you a flow-down we have no contract to deliver, or they are Apify's subprocessors, in which case the chain runs through Apify and Apify owes it. We have not established which is right, and we would rather say that than pick the convenient one.

8. Where your data is processed

Our database is hosted in the European Union, in the eu-central-1 region.

The subprocessors listed in section 7 operate internationally, and some processing takes place outside the European Economic Area. Where it does, we rely on the transfer terms in each provider's own published data processing agreement. Vercel in particular is a US company and its logs hold IP addresses.

Here is the uncomfortable part, stated rather than dressed up. We have not negotiated bespoke transfer terms with any of these providers, we have not executed a separate set of Standard Contractual Clauses with any of them, and we do not hold a signed set we could send you. For each recipient, the specific contracting entity, the processing location and the transfer mechanism are things we would have to go and establish, and we have not. If you need executed Standard Contractual Clauses in place before you send personal data through the Service, tell us before you send it, because today the answer would be no.

What replaces this section when that work is done is one row per recipient naming the contracting entity, the processing location and the mechanism relied on, plus a transfer impact assessment for every transfer not covered by an adequacy decision. Until then this is what is true, and offering you a copy of a safeguard we do not hold would be worse than saying nothing.

We do not send scraped results or run inputs anywhere beyond what section 7 describes for each recipient.

9. Your rights, as our customer

Under the GDPR you have the right to:

Access the personal data we hold about you, and get a copy.
Rectify data that is wrong or incomplete.
Erase your data, subject to the accounting records we are legally required to keep.
Restrict processing while a dispute about accuracy or lawfulness is resolved.
Portability: receive the data you gave us in a structured, machine-readable format.
Object to processing we base on legitimate interests. This applies to the discovery telemetry in section 4.8 in particular.
Withdraw consent where we rely on it. We currently rely on consent for nothing.
Complain to a supervisory authority. Ours is the Romanian ANSPDCP, and you can also complain to the authority where you live or work.

How to exercise them. Email hello@usegoro.ai. We respond within one month, extendable by two further months for complex requests, and we will tell you if we extend.

What you can do yourself today:

View your workspace, keys, budgets, balance and usage in the app.
Export your run history as CSV. Note that the export deliberately contains metadata only: run id, endpoint, status, costs, item counts, duration, timestamps and error details. It does not export run inputs or outputs, because we do not hold them.
Revoke any API key at any time.
Delete any cloned voice, which deletes it at the voice provider too.
Turn off automatic top-ups.

There is no self-service account deletion. No button, no endpoint, no closure flow. Email hello@usegoro.ai and we will do it by hand, against the database. That is the honest description of the mechanism, and here is what it does and does not reach.

Deleted: the personal data we hold about you. Your account and its email address at our authentication provider, your workspace and its name, your API key records, your budget rules and your automatic top-up rule, including the reference to your saved card.
Deleted upstream too: any cloned voice your workspace owns is removed at the voice provider, not only in our records. That part cannot be skipped by whoever performs the deletion, because the database preserves the provider's id for the model before our record of it can be erased, and a daily job does the upstream deletion and reconciles what the provider holds against what we still account for.
Kept: your ledger entries and the run metadata attached to them, for the statutory accounting period in section 6. That is an Article 17(3)(b) restriction on erasure, not a preference. Neither contains anything that came back from a provider: the ledger is amounts, references and timestamps, and run metadata is which endpoint ran, when, what it cost and how many rows it produced.
Those two facts pull against each other in the same database, because the accounting records hang off the account record. So this is a careful manual operation rather than a single delete, and it is done by a person who has to get it right. We would rather tell you that than describe a button that does not exist.
Your remaining balance is not forfeited. Whatever cash is left is refunded to the card you paid with, under Terms section 7. Promotional credit is not cash and is not refunded. We do not think a data protection right should cost you money to exercise, which is why the Terms say the same thing.

Portability is handled the same way, by hand and over email, against the database. The CSV export is a convenience, not our answer to a portability request.

10. If your data was collected through Goro and you are not our customer

If you believe a Goro customer has collected personal data about you through this service, here is the honest position.

We are usually not the right party to ask. The customer who ran the query decided to collect your data and decided what to do with it. Under the GDPR they are the controller and your rights run against them. We do not know why they collected it, what they did with it afterwards, or where else it now lives.

We almost certainly do not have it. We never store what a customer asked for, and we delete what came back within 24 hours. So unless your request reaches us inside that window, there is nothing about you in our database to find. That is not an evasion, it is the design, and it is the reason retention is treated as the main privacy control in this product rather than an afterthought.

What we will do. Write to hello@usegoro.ai with enough detail to identify the data. We will:

Look for data matching your request in what we currently hold, and tell you honestly what we found, including when the answer is that we hold nothing.
Where we do find it and we hold it as a processor, contact the customer who collected it and pass on your request, so they can respond to you as the controller. We do that by hand, from a mailbox, because the product has no outbound email of its own.
Delete or restrict what we hold where we are permitted or required to, and where doing so does not break our legal obligations to keep accounting records. That is also manual: an operator running a statement against the database.
Tell you what we did.

Two limits on step 1 that you should know about rather than discover. Run outputs are stored as unindexed JSON, so there is no search over their contents; finding a specific person's record inside the window means scanning, and at volume that is not reliably possible. And Article 11 does not require us to acquire additional information purely to identify you. We rely on that, and relying on it is not the same as being able to look, so we are saying both.

What we cannot do. We cannot tell you what a customer subsequently did with your data, we cannot compel them to respond to you, and we cannot remove your data from the original source it came from, or from the execution provider's own copy of the dataset your data appeared in.

We do not notify people whose data is collected through Goro. That duty, under Article 14, sits with the customer who ran the query. We are telling you this plainly rather than leaving you to discover it.

Reporting abuse. If what you are reporting is misuse rather than a data request, the same address works, and the Acceptable Use Policy sets out what we do about it. That process is manual and we do not monitor customer runs proactively. The controls that exist are real but blunt: we can revoke every API key on a workspace, cancel runs in flight, delete stored outputs, and close the account. Closing an account means removing the account itself, because revoking keys alone does not stop a signed-in user creating a new one.

11. Security

API keys are stored only as SHA-256 hashes. The raw key is shown once and never written down. A database leak does not yield usable keys.
OAuth authorization codes and access tokens are stored only as hashes.
Row level security is enabled on every table in the application schema. A signed-in user can read only their own workspace's rows. The only table any signed-in user can read in full is the endpoint catalog, which contains no personal data.
Payment card data never reaches our servers. Checkout is hosted by Stripe.
No code path of ours writes run input or run output content to a log. See section 4.11 for the limit on that statement.
Rate limits are applied to the authenticated API, per API key and per workspace, and are counted in the database rather than in process memory so they hold across servers. Responses carry headers showing where you stand against them, so you can see a limit approaching without first hitting it. There is also a cap on how many runs one workspace can have in flight at once, enforced inside the same database transaction that moves money.
All traffic is served over TLS, and plain HTTP is redirected rather than served. Confirmed against the live domains on 2026-08-01.

Four limits, stated plainly rather than buried:

Server-side code runs with a key that bypasses row level security. That is normal for a service backend, but it means route-level authorisation is what actually separates workspaces on the API, not the database. It also means an operator with that key can technically read any workspace's stored run outputs during the 24 hours they exist. Section 4.13 says we do not, and we mean it, but you should know what the architecture permits, and that there is no audit log recording when that key is used.

Run outputs are stored unencrypted at the application layer, inside a database that is encrypted at rest by our provider. There is no per-workspace key and no field-level encryption of scraped content. Short retention was chosen over encryption because for this data it is the stronger and cheaper control. That was a choice, and you should know it was made.

The MCP endpoint is not covered by the request-rate limiter. It authenticates separately, and the limiter sits in the wrapper the HTTP API routes share. The concurrency cap still applies to it, because that lives on the money path itself, but its request rate does not. This is a known gap rather than an oversight.

We have no formal security certification, no penetration test, and no independent audit. There is no ISO 27001 certificate and no SOC 2 report. There is also no intrusion detection, error monitoring or alerting.

Breach notification. Two duties apply here and they are not the same, because of the two relationships in section 2.

For personal data where we are the controller, which is your account, key, wallet and billing data, we will notify the supervisory authority within 72 hours where required, and notify you without undue delay where the risk to you is high.
For the run outputs we hold as your processor, Article 33(2) applies instead. We will notify you without undue delay after becoming aware of any personal data breach affecting that data. There is no high-risk threshold on that duty and no 72 hour grace on it. You then decide what to report onward as controller, and to whom.

"Becoming aware" is doing a lot of work in that promise, and we are not going to pretend otherwise. With no monitoring, no alerting and no audit log of privileged access, becoming aware today means somebody noticing. The obligation is real and we will meet it from the moment we know. What we cannot honestly claim is that we would know quickly.

12. Automated decision-making

We do not carry out automated decision-making that produces legal or similarly significant effects about you within the meaning of Article 22. Spending caps, insufficient-balance blocks, rate limits and automatic top-ups are contractual controls you configure or agree to yourself, not profiling. We build no profile of you and make no inferences about you.

13. If you are in the United States

This policy is written to the GDPR because our contracting entity is in the EU. That does not make US law irrelevant. The Service is sold in US dollars, over the public internet, with no geographic restriction at signup, so US customers can and will use it.

On your own data as our customer. We do not sell or share it in any sense, including the statutory senses used in California and the other state privacy laws. We do not disclose it for cross-context behavioural advertising, we run no advertising or analytics at all, and the only third parties who receive it are the subprocessors in section 7, who are paid to run the service and are not permitted to use it for anything else.

On the data you collect through us about other people. This is the same question as section 2, in a different vocabulary. We obtain personal data on your instruction and hand it to you, and we do not retain, use or disclose it for any purpose of our own, which is the substance of what a service provider commits to. We take that position for the same reasons we take the processor position, and it is contestable in the same places and for the same four facts. Somebody could argue that handing personal data about US residents to a paying customer is a "sale" under a broad statutory reading. That argument does not depend on us crossing any revenue threshold to be worth taking seriously.

On thresholds. The California CPRA and the newer state laws each have their own applicability thresholds based on revenue and on the volume of consumers whose data is processed, and B2B contact data has been in scope in California since 2023. We have not carried out a formal assessment, and at current volume we do not believe we cross any of them. That changes with growth rather than staying settled, and it is reviewed as volume grows.

14. Changes to this policy

We may update this policy. The version in force is always the one published at https://usegoro.ai/legal/privacy, with the "Last updated" date at the top.

A change that materially affects how we handle your personal data takes effect 14 days after we publish it. Any other change takes effect when published. Publication is the notice, and that is a deliberate choice rather than a convenience: the product has no outbound email, so we have no reliable way to reach you individually and we are not going to promise one we cannot keep. Sign-in codes are the only email the system sends. If we add outbound email later, we will also notify account holders directly, and this paragraph will change.

The Terms of Service, the Acceptable Use Policy and the Data Processing Agreement carry the same clause, the same period and the same channel.

15. Contact

hello@usegoro.ai

PROMPTIFY S.R.L. Strada Prof. Nicolae Oblu, Nr. 24A, Bloc B2A, Etaj 2, Ap. 22, Municipiul Iasi, Judetul Iasi, Romania Trade register number J22/1745/06.06.2023, CUI 48270068, EUID ROONRC.J22/1745/2023, VAT RO48310979

You can complain to the Romanian supervisory authority (ANSPDCP) or to the authority in your own country.

Related documents. Terms of Service (https://usegoro.ai/legal/terms), Acceptable Use Policy (https://usegoro.ai/legal/acceptable-use), Data Processing Agreement (https://usegoro.ai/legal/dpa).