Testing environment (validicate.dev). Credentials here may be test data; the production site is validicate.com.
Sign inVerify

Privacy notice

How Validicate handles data

Validicate lets anyone check a learning credential and lets the people who earned credentials keep and share them. This notice says who is responsible for the personal data involved, what we hold, why, who receives it, for how long, and what you can ask of us. Last updated 30 October 2026.

Who is responsible

Validicate is provided by Fondaris SLU, which operates Acadasco: NIF B26927095, Calle Guayedra 1, 35009 Las Palmas de Gran Canaria, Las Palmas, Spain. Write to us about personal data at privacy@acadasco.com. We have not appointed a data protection officer; that address reaches the people responsible for data protection.

Two organisations are responsible, for different things:

  • Holder accounts and profiles, sign-in, the sign-in log, issuer accounts and the security of the site: Fondaris is the controller.
  • Credential records: the issuer that granted the credential (an academy or other organisation) is the controller. It decides to issue, correct, revoke or delete the credential and to have it verifiable here; we store the record and publish its verification page on the issuer's behalf and on its documented instructions, as its processor (GDPR Art. 28). Every issuer outside Acadasco's own academies signs a data processing agreement with us before its first credential is accepted; Acadasco academies are covered by their agreement with Acadasco. Questions about a credential's content go to the issuer, and we pass on any we receive.

What we hold

  • Credential records, sent to us by the issuer: the holder's name and email address, the title, the issuer, the dates of issue, expiry and revocation, and the evidence summary (completion date, hours, lessons). For a program certificate, the courses completed. For a degree, the level, school, credits, final grade, honours, graduation date and a transcript summary listing the courses that counted with their credits and grades. Each record keeps the payload exactly as sent, the issuer's signature over it and which of the issuer's keys made it, and may carry the issuer's mark that the holder is a minor. The email address is used only to let the person it was issued to claim the credential.
  • Holder accounts: your email address, the name, handle and headline you enter, which credentials you chose to show and in what order, whether you show a degree's grades, and whether your profile is published. Signing in for the first time creates the account; there is no password.
  • Sign-in with Google or LinkedIn, if you choose it: the provider's identifier for your account there and the email address it confirms is verified. Nothing else from the provider is kept: not your name, picture or contacts, and not the provider's access token, which is used once to read the address. You are signed in to the account for that address, as an email link to it would.
  • Issuer accounts, for organisations that issue credentials here: the organisation's name, legal name, tax number, address and domain, the Validicate accounts that manage it, the public keys and API key fingerprints it registered, the issuer terms and data processing agreement it accepted (word for word, with who accepted them and when), and a history of what was done to it and by whom (sign-up, domain proof, approval, suspension, key changes). An organisation's own private key is never sent to us; an API key is stored only as a one-way hash.
  • An organisation's workspace, for organisations that issue from Validicate: its members (their accounts, roles and which of its brands they work for), the invitations it sends (the address invited, the role, who invited and when, and a one-way hash of the link, never the link), its brands (names, logos, colours, website, LinkedIn page id), and a log of every action taken in it: which member, API key or Validicate operator did what, to which item, and when, naming what changed but never a value typed into it, a secret or a recipient's address, with a one-way hash of the IP address.
  • A key Validicate holds for an organisation, if it chooses one to issue from Validicate: an Ed25519 signing key generated for that organisation alone, whose private half is kept encrypted, used only to sign on the instruction the organisation gives through its members, and never shown, exported or logged. Each credential records whether it was signed with such a key or with the organisation's own, and its verification page says which.
  • Credentials an organisation issues from Validicate, as its processor: each recipient's email address and name, the language, the organisation's own fields for them and whether they are under 18, as the organisation gave them; the spreadsheet itself is read once and never kept. For each, whether the email announcing it was sent, whether its claim link was opened from it and whether the credential was claimed; never whether the email was opened. The claim link is kept as a one-way hash, with a copy encrypted so a reminder can carry the same link; it never signs anyone in by itself (claiming emails a sign-in link to the address). If the issuer deletes the credential, the recipient's details and the link are erased with it.
  • Second factor, for workspace members who change anything: the secret of your authenticator app, kept encrypted, the last code accepted, and one-way hashes of your backup codes; for each browser, when it last proved the code and how many wrong codes it entered. The sign-in log records each code accepted, refused or that signed a browser out.
  • Sign-in records: for each sign-in link, a one-way hash of the link with the email address it was sent to and when; for each signed-in browser, a one-way hash of the session token and its expiry. The links and tokens themselves are never stored.
  • The sign-in log: one entry for each attempt to sign in and its outcome (link requested, signed in, link expired, link already used, refused), with your account if you have one or otherwise a one-way hash of the email address entered, the time, your IP address and your browser's user agent. It never contains a sign-in link or token.
  • Each credential's history: what happened to it and when (issued, corrected, revoked, deleted by the issuer, joined an account, shown or hidden on a profile, grades shown or hidden, embedding switched on or off), naming only whether the issuer or the holder did it, never what the record said.
  • Lookup counts: how many times a credential was looked up each day, by way of its verification page, its Open Badge files, its embedded badge or the employer API. A count and nothing else: we never record who looked, their IP address, their browser or where they came from.
  • Employer API keys: for each organisation we give a key to, its name, the contact it gave us, a one-way hash of the key, when it was created and last used, and whether it was revoked.
  • Technical logs of requests to the site: at our servers, the address requested, the time, the response status and the forwarded chain of addresses, which includes your IP address. A sign-in link is removed from these logs before they are written, and the application's own log records only the kind of page requested, never a credential code, a profile handle or an address. Logs at our content delivery network are anonymised.

Why, and on what legal basis

  • Holder accounts, profiles, sign-in emails and sign-in with Google or LinkedIn: to provide the account you ask for when you sign in (GDPR Art. 6(1)(b)).
  • Issuer accounts: to perform our agreement with the organisation (Art. 6(1)(b)); for the people who manage it, our legitimate interest in dealing with the organisation's representatives and in keeping a record of what each agreed and did, so that we can prove it (Art. 6(1)(f)).
  • An organisation's workspace, its log and its invitations: to perform our agreement with the organisation (Art. 6(1)(b)), and our legitimate interest, and the organisation's, in knowing who did what in its name (Art. 6(1)(f)). A key we hold for it: processed on the organisation's documented instruction, as its processor. Your second factor: to keep an organisation's issuing secure, our legitimate interest and the organisation's (Art. 6(1)(f)).
  • Credential records and verification pages: processed on the issuer's behalf, on the issuer's legal basis, usually its legitimate interest or its contract with you in letting others check a credential it granted. The issuer's own privacy notice describes it.
  • The sign-in log: to investigate attacks on accounts and abuse of the sign-in, such as someone requesting links for addresses that are not theirs. This is our legitimate interest in keeping accounts secure (Art. 6(1)(f)), and we weighed it against yours: the log holds no link and no content, keeps a hash rather than the address of anyone without an account, and is deleted after twelve months.
  • A credential's history and lookup counts: kept on the issuer's behalf as part of its credential record, so the issuer and the holder can see what happened to the credential and how often it was checked.
  • Employer API keys: to provide the API the organisation asked for (Art. 6(1)(b)) and to stop its misuse (Art. 6(1)(f)).
  • Technical logs and security: our legitimate interest in keeping the service secure and available, and in detecting abuse (Art. 6(1)(f)).

We make no automated decisions about you, build no profiles for marketing, show no advertising and run no analytics.

What is public

  • A verification page is public by its code: anyone with the code or the link can open it and check the credential. It shows the holder's name, the title, the issuer, the dates, the status and the evidence; for a degree, the level, school, credits and the courses that counted. Grades are not shown (a degree's final grade, honours and per-course grades) unless the holder chooses to show them for that credential from their account; they never appear in the page's description for search results and link previews. The page never shows the email address.
  • Search engines are asked not to index a verification page, unless its holder has published a profile and shows the credential on it. A credential the issuer marked as a minor's is never indexable and never appears on a profile. Credential pages are not listed in our sitemap. Hiding a credential from your profile does not make its verification page private: it stays verifiable by its code.
  • A profile is visible to nobody else until its holder publishes it. Once published it shows the name, headline and the credentials the holder marked visible: a credential from an Acadasco academy is shown until the holder hides it, one from any other issuer is hidden until the holder shows it, is listed in our sitemap and may be indexed by search engines.
  • The Open Badges files of a credential (its .json export, and the same credential signed by Validicate as a .jwt) are public by its code too, never indexed, and follow the same rule for grades. They identify the holder by a salted one-way hash of the email address, as the Open Badges standard provides: someone who already knows the address can confirm it is the holder's, and nobody can read the address from the file. Whether a signed badge has been revoked is published in a status list that holds one bit per credential position and nothing else; a badge signed before the issuer corrected or deleted the credential reads as revoked there, and a signed badge file is good for a year, after which the holder downloads a new one.
  • An embedded badge exists only if its holder switches it on for that credential, and only while the credential is shown on their profile; never for a credential marked as a minor's. It shows the name, the title, the issuer, the date and the status, never grades or the email address, and links to the verification page.
  • Organisations with an employer API key can look up a credential whose code they already know, or check a badge someone gave them. They receive exactly what the verification page shows, nothing more.

Who receives data

These providers process data for us under data processing agreements, each only for the service named:

  • Hetzner Online GmbH (Gunzenhausen, Germany) hosts the site and its database in Germany.
  • BunnyWay d.o.o. (bunny.net, Medvode, Slovenia) delivers the pages through its content delivery network and answers for our domain names; visitors are served from a location near them, and its request logs are anonymised.
  • Amazon Web Services EMEA SARL (Luxembourg) sends sign-in emails through Amazon SES in the European Union (Ireland), and keeps our encrypted backups in Germany and Spain.

Others receive data only because of what you or an issuer chose:

  • Issuers' web hosts: an issuer's logo is loaded from the address the issuer supplied, so that host receives your IP address when a page shows the logo.
  • LinkedIn, only if you choose "Add to LinkedIn": your browser opens LinkedIn with the credential's title, issuer, dates, link and code.
  • Google or LinkedIn, only if you choose to sign in with them: your browser goes to the provider, which tells us your account's identifier there and your verified email address. Each is responsible for its own sign-in under its own privacy notice.

The site's typefaces are served from our own servers; apart from issuers' logos, no page loads anything from a third party to display itself.

Where

Data is stored and processed in the European Union: the database in Germany, sign-in emails sent from Ireland, backups in Germany and Spain. Hetzner and bunny.net are established in the European Union, so no transfer outside it takes place. Amazon Web Services EMEA SARL belongs to a group based in the United States; should Amazon access data from outside the European Union, that transfer is covered by the European Commission's standard contractual clauses, which are part of AWS's data processing addendum, and by Amazon's certification under the EU–US Data Privacy Framework.

How long

  • Holder account and profile: until you delete your account, which you can do yourself at any time. A Google or LinkedIn sign-in goes with the account.
  • Issuer accounts: a sign-up that never proves its domain, that proves it and is not reviewed, or that we do not approve, is deleted 30 days after it was made, proved or refused, with what it accepted. An approved organisation's records are kept while it issues credentials here. To stop abuse of issuer sign-up and domain checks we count attempts by a one-way hash of the IP address for one hour and delete the count after a day.
  • An organisation's workspace: members, brands and the keys we hold for it are kept while the organisation is with us and deleted with it; a held key's private half is destroyed as soon as the key is revoked or retires, and its public half is kept so what it signed stays verifiable. An invitation is deleted 30 days after it was accepted, withdrawn or expired. The workspace's log is kept while the organisation exists and for one year after it is deleted.
  • Recipients of what an organisation issues: kept with the credential, as the organisation decides; a draft it deletes is deleted with its recipients. A claim link works for 180 days, and is forgotten 30 days after it was used or expired.
  • Your second factor: until you turn it off or delete your account.
  • Credential records: for as long as the issuer keeps the credential verifiable here. A revoked or expired credential stays verifiable as such, so that someone checking it learns it is no longer valid, until the issuer instructs us to delete it, including when the issuer grants a holder's request for erasure. A deleted credential's page then answers that it does not exist.
  • Sign-in records: a sign-in link works for 20 minutes and a session lasts 30 days. The record of a link is deleted once 24 hours have passed since it was used or expired; the record of a session when you sign out or once it has expired. We check every hour.
  • The sign-in log: twelve months, then deleted by the same hourly check. If you delete your account, its entries keep only a one-way hash of your address until then.
  • A credential's history: as long as the credential record. When the issuer deletes the credential its history and its lookup counts are deleted too, and only the fact that the issuer deleted it, under its code, is kept.
  • Lookup counts: 24 months, then deleted by the hourly check.
  • Employer API keys: while the key is in use; twelve months after it is revoked, deleted with the organisation's name and contact.
  • Technical logs: at our servers, fourteen days, then deleted.
  • Backups: data deleted from the service remains in encrypted backups for up to 35 days, after which it is gone.

Your rights

You can ask for access to your data, its correction or deletion, a restriction of its use, a copy in a portable format, and you can object to processing based on legitimate interest. Write to privacy@acadasco.com; we answer within one month and may ask you to confirm you control the email address concerned.

  • Your account: from your account you can hide any credential from your profile, show or hide a degree's grades, unpublish the profile, and delete the account. Deleting it removes your profile, your handle, your sessions and your link to the credentials at once; the credential records themselves stay with the issuer's records.
  • A credential's content or its verification page: the record is the issuer's statement, so correcting, withdrawing or deleting it is the issuer's decision. Write to the issuer, or to us and we forward your request to the issuer without undue delay and tell you what it decides.

You also have the right to complain to a data protection authority: in Spain the Agencia Española de Protección de Datos (aepd.es), or the authority where you live or work.

Children

Holder accounts are for people aged 14 or over, the age from which Spanish law (LOPDGDD Art. 7) lets a person consent to the processing of their own data; signing in confirms you are. Credentials of younger people are issued under the issuer's responsibility. An issuer can mark a credential as a minor's: its page is then never indexed by search engines and it never appears on a profile. A parent or guardian can write to the issuer, or to us, about a minor's credential.

Cookies

Validicate sets one cookie, validicate.session, when you sign in. It keeps you signed in for up to 30 days, is not readable by scripts, and is strictly necessary for the account you asked for, so it needs no consent. If you sign in with Google or LinkedIn, a second, validicate.oauth, holds that sign-in together for at most ten minutes and is then removed. We use no analytics or advertising cookies.

Security

Pages are served only over encrypted connections, sign-in links and session tokens are stored as one-way hashes, credential records are accepted only with a valid signature by a key the issuer registered with us and the issuer's own API key (or, for what an organisation issues from Validicate, by a key we hold for it, encrypted, used only on its instruction), changes in an organisation's workspace need a second factor, and backups are encrypted.

Changes

When this notice changes we update the date above, and we tell holders by email before a change that affects how their data is used.