Privacy policy

DataCEVA Authentication Broker · last updated 10 September 2026

This service is an authorisation broker. It holds the access it has been granted to third-party accounts — Google Analytics, Google Search Console, Google Ads, Meta Ads and similar — on behalf of DataCEVA and its clients, so that DataCEVA's applications can read that data without each one storing credentials of its own.

1. Definitions

• Service — the DataCEVA Authentication Broker at broker.dataceva.com, described in this document.
• Provider — a third-party platform whose account you authorise, such as Meta or Google.
• Platform Data — information the Service obtains from a Provider, including the tokens a Provider issues and the identifiers of the accounts selected.
• Client — the organisation that engaged DataCEVA and on whose behalf a connection is made.
• Operator — a DataCEVA staff member who administers the Service.

2. Our role, and who controls what

Where DataCEVA holds a connection on behalf of a Client, that Client is the controller of the data reached through it and DataCEVA acts as a processor on their instructions. For the limited personal data the Service holds about the person who granted access and about Operators — described below — DataCEVA is the controller. If you are unsure which applies to you, write to [email protected] and we will tell you.

3. What is collected

From the person granting access

• Provider account identifier and email address. Read once, immediately after consent, from the Provider's own identity endpoint. It identifies which account a connection belongs to, so that an Operator can tell one connection from another and see who to contact when a connection needs renewing.
• The access and refresh tokens the Provider issues. Encrypted at rest.
• Which scopes the Provider granted, which can be narrower than what was requested.
• The accounts, properties or sites selected during the connection — their Provider identifiers and display names.
• The list the Provider offered to choose from, held only for the life of the authorisation attempt — at most thirty minutes — so that the choice shown and the choice submitted are the same list. It is discarded with the attempt; only what was selected is kept.

From Operators of this Service

• Name, email address, a password hash, and an authenticator secret. Two factors are required; there is no configuration that reduces this to one.
• An append-only record of configuration changes and administrative actions, including who made each one.

Technical records

• Request records. Timestamp, method and path, response status, duration, a request identifier, the calling application and Client, and — for requests that reach the Service over the network — the IP address and browser user-agent string they arrived with.
• Steps within an authorisation attempt, so that a connection which fails part-way can be diagnosed: which step was reached, which Provider was called, how long it took and what it answered.
• A count of how often each connection has issued a token, and when it last did.

Records are passed through a redaction filter before they are written, and a database rule rejects any record whose contents look like a credential. Tokens, authorisation codes and secrets are therefore not present in them. Successful, fast, routine read requests may be sampled rather than recorded individually; failures are always recorded.

Cookies

One cookie, set only while an authorisation is in progress and only on this Service's own domain. It holds a random value that ties the authorisation to the browser that started it, which is what stops someone who obtains a part-finished link from completing it elsewhere. It expires after thirty minutes, is cleared when the authorisation finishes, and is not readable by JavaScript. There are no advertising, analytics or cross-site cookies, and none that persist beyond the flow.

4. What is deliberately NOT collected

• The data the tokens grant access to. This Service does not proxy Provider API calls and holds no analytics, advertising or search data. Applications call the Provider directly with a token they obtain here.
• Provider passwords. Authentication happens on the Provider's own site; the broker never sees a credential for a third-party account.
• Anything about end users of our Clients' websites.

5. How the information is used

Each category is collected for one purpose and used for that purpose only:

• Tokens — to obtain short-lived access tokens for DataCEVA's applications, and to keep a connection working by renewing it before it expires.
• Account identifier and email — to tell connections apart, and to contact the right person when a connection needs re-authorising.
• Selected accounts and granted scopes — to know what a connection covers, and to report when a Provider granted less than was asked for.
• Technical records — security, fault diagnosis, and abuse prevention.
• Operator records — authentication, and an accountability trail for administrative actions.

None of it is used for advertising, marketing, profiling, automated decision-making, model training, or any purpose unrelated to operating this Service.

6. Platform Data obtained from Providers

Platform Data is used solely to provide the connection and reporting services a Client has engaged DataCEVA to deliver, on that Client's instructions. DataCEVA:

• does not sell, rent or licence Platform Data, and does not share it with data brokers, advertising networks or any onward recipient beyond those named in section 9;
• does not use Platform Data to build or enrich profiles of individuals, to target advertising, or to make automated decisions about people;
• does not combine one Client's Platform Data with another's — each Client's connections and data are separated from every other Client's;
• handles Platform Data in accordance with the terms and policies of the Provider it came from, in addition to this policy.

7. How tokens are protected

• Encrypted with AES-256-GCM under a two-level key scheme. Each stored token has its own data key, which is itself encrypted under a master key held outside the database. Possession of a database copy alone does not yield a token.
• Bound to their context. Each encrypted value is cryptographically tied to the Client, the Provider and the specific field it belongs to, so ciphertext cannot be moved between records and still be readable.
• Separated by database role. The application's ordinary database account has no privilege at all on the table holding encrypted tokens; only one narrow code path, using a separate account, can read it.
• Never written anywhere else. Not to the cache, not to disk, not into a record, not into an error message, and not into a URL.
• Transmitted over TLS only, to Providers and to callers alike.

No method of transmission or storage is completely secure, and we do not claim otherwise. What we can state is what the Service does: the protections above are implemented, and the boundary between the application account and the token store is enforced by the database rather than by convention.

8. Who can reach what

• An application can obtain tokens only for the Client, Provider and services it has been granted, and only with its own credential. A request for anything else is refused.
• An Operator can see connections, their status and the account that granted them. Secrets are shown once when created and are not readable afterwards; revealing or rotating one requires a recent re-authentication.
• No one can read a stored token through the Service's interfaces. There is no screen and no endpoint that displays one.

9. Who the information is shared with

The Service is hosted on DigitalOcean, which provides the application platform, the database and the cache it runs on. Data is held in the region the deployment is configured for; DataCEVA will tell you which on request.

Beyond that, the only recipients are:

• The Providers you connect. Google, Meta and similar receive the authorisation requests and token exchanges the Service makes on your behalf, under their own terms and privacy policies.
• DataCEVA's internal alerting, where it is enabled. A notification that a connection needs attention may name the Client, the Provider and the email address of the account that granted it, so that whoever is on call knows who to contact. It never contains a token.

There are no other recipients. The Service uses no analytics, advertising, session-recording or profiling tools.

Legal disclosure. DataCEVA may disclose information where required to do so by law, or where necessary to comply with valid legal process, to protect the rights, property or safety of DataCEVA, its Clients or the public, or to investigate suspected fraud or a security incident. Where a business transfer occurs, information may pass to the acquiring party subject to this policy. A stored token cannot be produced in readable form by disclosure of the database alone.

10. International transfers

The Service runs in a single region chosen for the deployment, and personal data is not routinely transferred elsewhere. Where information does move between countries — because an Operator administers the Service from another country, or because a Provider processes a request in its own region — DataCEVA takes steps to ensure it remains protected in line with this policy and applicable law.

11. Retention

• Tokens are kept while a connection is live. Deleting a Client or a Provider revokes its grants and overwrites the stored ciphertext immediately.
• Configuration objects are recoverable for seven days after deletion, then removed permanently. That window recovers configuration only — never access, which ends at once.
• In-flight connection attempts, and the account list offered during them, expire after thirty minutes.
• Request and diagnostic records are kept for thirty days by default and then deleted permanently.
• Operator sessions expire after twelve hours.
• Records of configuration changes and administrative actions are kept indefinitely. They cannot be edited or deleted by the application, and they survive deletion of the objects they describe — that is what makes them an accountability record rather than a log. They hold who did what and when; they do not hold credentials.

12. Deleting your data

You can have the information this Service holds about a connection deleted at any time, and you do not need an account here in order to ask.

• Write to [email protected] from the address associated with the connection, or ask your DataCEVA contact. Say which Provider account is concerned. We will revoke the grant at the Provider and destroy its stored tokens, and confirm when it is done. We aim to complete a request within thirty days, and sooner where the applicable law requires it.
• Or remove the application yourself at the Provider, as described in section 13. That revokes access immediately; writing to us additionally deletes what the Service still holds.

What deletion removes: the stored tokens, the Provider account identifier and email, and the selected account identifiers. What survives, and why: the append-only record that a connection existed and was deleted, and by whom. It holds no credential and no Provider data, and it is what allows DataCEVA to demonstrate afterwards what was done.

13. Revoking access

Access granted to this Service can be withdrawn at any time, and in two independent ways:

• At the Provider. Removing this application from your Google or Meta account security settings revokes the tokens immediately. The broker detects the revocation and marks the connection as needing reconnection.
• Through DataCEVA. Ask your contact, or write to [email protected], and the grant will be revoked at the Provider and its stored tokens destroyed.

14. Your rights

Depending on where you live you may have rights of access, correction, deletion, restriction, portability and objection, and the right not to be treated differently for exercising them. These include rights under the EU and UK General Data Protection Regulations and, for California residents, the California Consumer Privacy Act as amended by the CPRA. DataCEVA does not sell personal information and does not share it for cross-context behavioural advertising.

Write to [email protected] and we will respond within the period the applicable law requires. Where DataCEVA processes data on behalf of a Client, we will direct a request to that Client where they are the controller, and tell you that we have done so. You may also complain to your local data protection authority.

15. Children

This Service is used by businesses and their administrators. It is not directed at children, is not offered to anyone under 16, and does not knowingly collect personal data from children. If you believe a child has provided information here, write to [email protected] and it will be deleted.

16. Links to other sites

Completing a connection sends you to a Provider's own website to sign in and approve access. Those sites are not operated by DataCEVA and are governed by their own terms and privacy policies, which you should read. This policy covers only this Service.

17. Changes to this policy

Material changes will be reflected in the "last updated" date above and, where the change affects what is collected or who can reach it, notified to affected Clients. Continuing to use the Service after a change takes effect means accepting the updated policy.

18. Contact us

DataCEVA, Chicago, Illinois, United States.
Privacy enquiries and deletion requests: [email protected]