JeinGet an API key
Legal

Data Processing Agreement

Last updated: 27 September 2026 · Version 2026-09-27

This Data Processing Agreement ("DPA") under Article 28(3) GDPR is part of the Terms of Service of Jein (jein.dev) (https://jein.dev/terms/, version 2026-09-27). It applies where the Customer acts as a controller under the GDPR, between that Customer who accepted the Terms (controller, "Customer") and

Setorli Blagogee
c/o Autorenglück #40488
Albert-Einstein-Str. 47
02977 Hoyerswerda
Germany
E-mail: privacy.jein@snblago.com

(processor, "we"). You accept it by accepting the Terms at signup; no signature is needed. If you need a countersigned copy for your records, write to privacy.jein@snblago.com. If the Terms and this DPA conflict on the processing of personal data, this DPA prevails.

1. Subject matter and duration

1.1 We process personal data that the Customer sends to the Jein API, including through the playground in the dashboard ("Customer Data") in order to return model outputs, as described in the Terms and the documentation at https://app.jein.dev/docs/.

1.2 This DPA runs as long as the Terms. It ends when the contract ends, except for obligations that by their nature continue.

1.3 This DPA does not cover data we process as a controller (account, API key, usage and log data, and request content for purely personal or household use). That processing is described in our Privacy Policy (https://jein.dev/privacy/).

2. Nature and purpose of processing

2.1 Nature: receiving the request over an encrypted connection (through our hosting provider's edge network, see section 8.4), validating it, converting the text into model inputs, running the Laya model, and returning the output. All of this happens in memory, within a single request.

2.2 Purpose: providing the API to the Customer. We do not use Customer Data for any other purpose. In particular we do not store it, log it, analyse it, use it to train or improve models, or disclose it to third parties other than the subprocessors in section 8.

2.3 Storage: none. Customer Data is never written to a database, file, log, cache or backup by us, and API responses are not cached at the edge. It exists only in the memory of our servers for the duration of the request, which is limited by a request deadline.

2.4 Please do not send Customer Data to our support or contact e-mail addresses; they are not part of the API. Correspondence about your account is processed as described in the Privacy Policy. If a message nevertheless contains Customer Data, we use that data only to answer the request and delete it when the request is closed, unless the law requires us to keep it. For such data, this DPA applies only to confidentiality (section 5), security (Article 32 GDPR), personal data breaches (section 9) and deletion (this section); our e-mail provider processes such messages as a subprocessor listed in Annex 2.

3. Types of personal data and data subjects

3.1 Types of data: whatever personal data the Customer chooses to include in the request text (the state, instructions, questions and criteria of a request) and, as a result, in the output. We do not require or request any personal data in requests.

3.2 Data subjects: the persons the Customer's request text relates to, as determined by the Customer (for example the Customer's own users, customers or employees).

3.3 The Customer may send special categories of personal data (Article 9 GDPR) or data about criminal convictions (Article 10 GDPR) only where the Customer has a legal basis for doing so (Terms section 5.1).

4. Instructions

4.1 We process Customer Data only on the Customer's documented instructions, including with regard to transfers to third countries, unless Union or Member State law requires otherwise; in that case we inform the Customer before processing, unless that law prohibits it (Article 28(3)(a) GDPR).

4.2 The Terms, this DPA and each API request sent with the Customer's API key are the Customer's complete instructions. Further instructions must be given in text form and must be technically feasible within the Service.

4.3 We inform the Customer without undue delay if we consider that an instruction infringes the GDPR or other data protection law (Article 28(3) second subparagraph GDPR).

5. Confidentiality

Everyone we authorise to process Customer Data is bound to confidentiality or is under an appropriate statutory obligation of confidentiality (Article 28(3)(b) GDPR). At present, the only person with access to production systems is the operator named above.

6. Security of processing

6.1 We take the technical and organisational measures required by Article 32 GDPR, as described in Annex 1.

6.2 We may adapt the measures to technical progress, provided the level of protection does not fall below the level described in Annex 1.

7. Assistance

7.1 Data subject requests: because we do not store Customer Data, we hold nothing we could disclose, correct or erase for a data subject. If a data subject contacts us directly about Customer Data, we forward the request to the Customer without undue delay, where we can identify the Customer, and do not answer it ourselves.

7.2 Articles 32 to 36 GDPR: we assist the Customer in ensuring compliance with its obligations on security, breach notification, data protection impact assessments and prior consultation, taking into account the nature of processing and the information available to us, in particular by providing this DPA, Annex 1 and information about the model and the Service.

7.3 On request we provide the information about the models that is available to us (model identity and version, published model cards, known limitations and evaluation results) which the Customer needs to explain the logic involved to data subjects (Articles 13(2)(f), 14(2)(g) and 15(1)(h) GDPR).

8. Subprocessors

8.1 The Customer gives general authorisation for us to engage subprocessors (Article 28(2) GDPR). The subprocessors that process Customer Data at the date of this DPA are listed in the section "Subprocessors for Customer Data" at https://jein.dev/subprocessors/, with their location and the transfer mechanism; they are approved.

8.2 We inform the Customer at least 30 days before adding or replacing a subprocessor, by e-mail to the address of the Customer's account and by updating the list. The Customer may object in text form within those 30 days on reasonable data protection grounds. If we cannot address the objection, either party may terminate the contract with effect from the date the change takes effect. Where a subprocessor intends to engage or replace its own subprocessors for Customer Data, we inform the Customer without undue delay after we receive the subprocessor's notice, and in any case before the change takes effect where the subprocessor's notice allows this; the Customer may object in text form within 30 days of our notice on reasonable data protection grounds; if we cannot address the objection, either party may terminate the contract with effect from the date the change takes effect or, if that date has already passed, from receipt of the termination.

8.3 We impose on each subprocessor, by contract, the same data protection obligations as set out in this DPA, in particular sufficient guarantees for appropriate technical and organisational measures. We remain liable to the Customer for our subprocessors as for our own conduct.

8.4 Customer Data is processed on our servers in the EU (Frankfurt, Germany). Requests reach these servers through our hosting provider's edge network, operated by Cloudflare, Inc., which terminates the encrypted connection at the location nearest to the client, which can be outside the EU, and forwards the request without storing it. Where a subprocessor or its parent company is established in a third country, or processes at such an edge location, the transfer is based on an adequacy decision (in particular the EU-U.S. Data Privacy Framework) and, in addition, on the EU Standard Contractual Clauses, as stated in the list.

9. Personal data breaches

We send notices under this DPA to the e-mail address of the Customer's account. We notify the Customer without undue delay, and at the latest within 48 hours after becoming aware of a personal data breach affecting Customer Data. The notice contains, as far as available, the information under Article 33(3) GDPR; information not yet available is supplied as soon as it is. We take the measures necessary to secure the data and to reduce possible adverse consequences.

10. Deletion and return

We do not retain Customer Data beyond the request, so at the end of the contract there is nothing to return or delete. Should any Customer Data nevertheless remain with us, we will, at the Customer's choice, return or delete it and delete existing copies, unless Union or Member State law requires storage (Article 28(3)(g) GDPR). Data we hold as a controller is deleted as described in the Privacy Policy.

11. Information and audits

11.1 We make available to the Customer the information necessary to demonstrate compliance with Article 28 GDPR, primarily this DPA, Annex 1 and written answers to reasonable questions.

11.2 If this information is not sufficient in a specific case, the Customer or an auditor it mandates may carry out an audit, including an inspection (Article 28(3)(h) GDPR). The auditor must be bound to confidentiality. We may object to an auditor only if there are concrete indications that it is not bound to confidentiality, is not independent of the Customer's audit purpose, or would use the information to compete with us. We state the grounds in text form; the Customer may then name another auditor.

11.3 As a rule, audits are announced at least 30 days in advance, take place during normal business hours without disrupting operations, and happen at most once a year. Additional audits, or audits at shorter notice, take place where they are objectively necessary, in particular after a personal data breach, on the order of a supervisory authority, or where there are concrete indications that this DPA is not being complied with. Each party bears its own costs. Inspections of our subprocessors' data centres are replaced by their certifications and audit reports.

12. Liability and final provisions

12.1 Liability is governed by the Terms (section 12); Article 82 GDPR remains unaffected.

12.2 Changes to this DPA follow the procedure for changes to the Terms (Terms section 14), except that a change which lowers the protection of Customer Data or the Customer's rights under this DPA requires the Customer's express consent. Such a change is in particular one that removes or weakens a measure in Annex 1, or changes any other provision of this DPA to the Customer's disadvantage. Changes of subprocessors follow section 8.2. German law applies; the venue is that of the Terms.

Annex 1: Technical and organisational measures (Article 32 GDPR)

Pseudonymisation and encryption

  • All public connections to the website, dashboard and API use HTTPS (TLS), terminated at our hosting provider's edge network (Cloudflare), which also filters bot and attack traffic.
  • Customer Data is never stored, so it is not included in any database, backup or log.
  • Inside the hosting platform, requests travel from the API to the inference workers over the provider's private network without additional encryption; the workers accept inference requests only if they carry a shared secret.
  • API keys are stored only as SHA-256 hashes; the plaintext key is shown once at creation and never stored.
  • Session and login cookies are encrypted and authenticated (AES-256-GCM), HttpOnly and SameSite=Lax; session cookies use the __Host- prefix.
  • The database connection requires TLS. The managed database encrypts data at rest.
  • Application logs contain request and trace ids, method and route, status and error codes, error descriptions, timings, where applicable model and token counts, and internal ids (account, key, user); no IP addresses, user agents, e-mail addresses or request content.

Confidentiality: access control

  • Physical access: our application servers and database run only in DigitalOcean data centres in Frankfurt (region FRA1); connections are received by the edge network described above. Physical security is provided by DigitalOcean and covered by its independent audit reports (such as SOC 2). We operate no own servers.
  • System access: administration through the DigitalOcean and Auth0 control panels and GitHub, each with an individual account, and through direct, password-authenticated database sessions with the owner role or the application role for documented maintenance and data-subject requests. Only the operator has administrative access.
  • Data access: the database enforces row-level security on the tables for accounts, logins, API keys, usage records, monthly usage totals and pending identity-provider deletions, so a request can only read and change the rows of its own account; the application's database role has column-level grants and cannot change quotas. Separate database roles are used for migrations and for the application. The deletion log is exempt from row-level security; the application may only add entries to it.
  • Customer access: dashboard login via Auth0 with verified e-mail addresses, OpenID Connect authorisation code flow with PKCE, sessions of at most 12 hours, CSRF protection on every form; API access only with a valid, non-revoked API key. Keys can be revoked at once in the dashboard.
  • Separation: the inference workers have no database access; they receive only the request and are reachable only on the hosting provider's private network, authenticated with a shared secret.
  • Secrets: stored as encrypted environment variables of the hosting platform; never committed in plaintext (the app specification in source control holds only the platform-encrypted values).

Integrity

  • Changes to the software are made through version control (GitHub); proposed changes and the shared branches are tested automatically in CI; release images are built by CI from a tagged commit; the API and worker images record that commit.
  • Request validation rejects malformed input before processing; request size is limited to 1 MiB.
  • The dashboard sends a restrictive Content Security Policy, X-Content-Type-Options: nosniff and a same-origin referrer policy; pages showing secrets are not cached.

Availability and resilience

  • Managed PostgreSQL with daily backups and point-in-time recovery for 7 days (Customer Data is not part of it).
  • Rate limits per account and per IP address, and concurrency limits per account and overall (all in memory only), protect against overload; health checks restart unhealthy instances.
  • Model weights are pinned to a fixed version and loaded at start.

Procedures for regular testing and evaluation

  • Automated unit and integration tests, including tests that the database schema matches the documented personal-data inventory and that row-level security isolates accounts.
  • Review of these measures at least once a year and after every significant change or security incident.
  • A written procedure for personal data breaches (notification to the Customer within 48 hours, see section 9).

Data minimisation and deletion

  • No storage of request content or outputs; no training on Customer Data.
  • On account deletion, the account's e-mail address is deleted immediately and all API keys are revoked. The identity-provider user id is kept only on a deletion work list until the user at the identity provider is deleted, at the latest one month after the account deletion.

Annex 2: Subprocessors

See the section "Subprocessors for Customer Data" at https://jein.dev/subprocessors/. That list forms part of this DPA.