Legal basis analysis for data processing
QR Branding API — GDPR Art. 6
| Field | Value |
|---|---|
| Controller | QR Branding (Quartzon) |
| Date | 2026-03-08 |
| Version | 1.0 |
1. Principle of lawfulness (Art. 6)
All processing of personal data must rely on at least one of the legal bases in Art. 6(1) GDPR. Each QR Branding processing activity and its corresponding legal basis is analyzed below.
2. Analysis by processing activity
2.1 Generating QR codes containing personal data
| Aspect | Analysis |
|---|---|
| Activity | The user submits QR content that may include personal data (a vCard with name, email, phone and address; geolocation; email addresses) |
| Legal basis | Art. 6(1)(b) — Performance of a contract |
| Justification | The processing is necessary to perform the service the user has contracted through RapidAPI. Without processing the content, the requested QR code cannot be generated |
| Proportionality | Minimal: only the strictly necessary content is processed, in memory, with no storage |
| Less intrusive alternative | None: the QR content IS the data to be encoded |
2.2 AI-generated QR codes
AI generation works in two modes:
- QR Branding's own accounts (the AI designer on qr-branding.com and the managed endpoint
POST /api/qr/ai/generate-managed): QR Branding sends the design prompt to an LLM provider of its internal fallback chain (Groq, Google Gemini, OpenAI) with its own API keys. These providers act as QR Branding's processors and are listed on the subprocessors page. - BYOK (Bring Your Own Key) (the endpoint
POST /api/qr/ai/generate): the customer supplies their own API key and chooses the provider; QR Branding does not use its own accounts for these requests.
| Aspect | Analysis |
|---|---|
| Activity | The user submits a design prompt. QR Branding forwards the prompt to an LLM provider: with its own keys (site and managed endpoint) or with the customer's key (llmApiKey, BYOK endpoint) |
| Model | QR Branding's own accounts with Groq, Google (Gemini) and OpenAI, or BYOK (Bring Your Own Key) with the provider chosen by the customer |
| Legal basis | Art. 6(1)(b) — Performance of a contract |
| Justification | The user explicitly requests an AI-generated design: on the site and the managed endpoint by triggering an AI generation; on the BYOK endpoint also by selecting the provider and supplying their own API key. The processing is necessary to carry out that specific request |
| Proportionality | Only the design prompt and the generation parameters are sent to the LLM. QR content, IP addresses and identification data are NEVER transmitted. On the BYOK endpoint, the customer's API key is neither stored nor logged |
| Note | The user actively chooses to use AI generation and the prompt they send. On the BYOK endpoint they also choose the LLM provider and supply their own API key, and the relationship with the LLM provider is a direct one between the customer and the provider |
2.3 Rate limiting
| Aspect | Analysis |
|---|---|
| Activity | Counting requests per identifier (RapidAPI user, subscription ID, anonymized IP) to limit the rate of use |
| Legal basis | Art. 6(1)(f) — Legitimate interest |
| Legitimate interest | Protecting the availability of the service for all users and preventing abuse and excessive costs |
| Balancing test | |
| — Controller's interest | High: without rate limiting, a single user could exhaust resources or generate prohibitive costs |
| — Impact on the data subject | Minimal: only a pseudonymous identifier is used to count requests, data is held in volatile memory (2 min), and IP addresses are anonymized |
| — Reasonable expectation | Yes: API users expect rate limiting as standard industry practice |
| — Safeguards | Ephemeral data (2 min), IP anonymization, tracking cap (50K IPs), no logging of identifiers |
| Outcome | The legitimate interest clearly prevails given the minimal impact on the data subject |
2.4 Telemetry and diagnostics (Application Insights)
| Aspect | Analysis |
|---|---|
| Activity | Collecting performance metrics, errors and request metadata (no PII) |
| Legal basis | Art. 6(1)(f) — Legitimate interest |
| Legitimate interest | Keeping the service reliable and available, and diagnosing problems quickly |
| Balancing test | |
| — Controller's interest | High: without telemetry, incidents cannot be detected or resolved |
| — Impact on the data subject | Minimal: PII removed from error messages, API keys redacted, IP addresses anonymized |
| — Reasonable expectation | Yes: monitoring is standard practice for cloud services |
| — Safeguards | 90-day retention, PII-free logging, IP anonymization, API key redaction |
| Outcome | The legitimate interest clearly prevails |
2.5 RapidAPI authentication
| Aspect | Analysis |
|---|---|
| Activity | Verifying the X-RapidAPI-Proxy-Secret header on every request |
| Legal basis | Art. 6(1)(f) — Legitimate interest |
| Justification | Protecting the service against unauthorized access |
| Note | The secret is server data, not user data. No personal data at all is processed in this step |
3. Legal bases NOT relied on
| Legal basis | Art. | Why is it not used? |
|---|---|---|
| Consent | Art. 6(1)(a) | No explicit consent is collected. It is not needed: the processing relies on contract and legitimate interest. Relying on consent would create additional obligations (withdrawability) with no benefit |
| Legal obligation | Art. 6(1)(c) | No legal obligation requires the processing of this data |
| Vital interests | Art. 6(1)(d) | Not applicable: the service does not process data to protect vital interests |
| Public interest | Art. 6(1)(e) | Not applicable: this is a private commercial service |
4. Special categories of data (Art. 9)
QR Branding neither requests nor requires special categories of personal data (ethnic origin, health, sexual orientation, etc.).
However, the user could include such data in QR content (e.g. a QR code containing medical data). In that case:
- QR Branding acts as a technical processor that encodes data without interpreting it.
- Responsibility for processing the special categories lies with the user who decides to include them.
- The legal basis in this scenario would be the explicit consent of the data subject, which the user must obtain before encoding the data.
- QR Branding does not store this data and discards it immediately after generation.
5. Children's data (Art. 8)
- QR Branding is a B2B/B2C API service aimed at developers and businesses.
- It is not directed at children under 16.
- No age data is collected and no age verification is performed.
- If a user includes children's data in QR content, responsibility for obtaining parental consent lies with the user.
6. International transfers (Art. 44-49)
| Destination | Legal basis for the transfer | Provider |
|---|---|---|
| EU/USA (Azure) | Online Services Terms + SCCs | Microsoft Azure |
| USA | Platform terms | RapidAPI |
| USA | Each provider's data processing terms (see the subprocessors page) | Groq, Google (Gemini), OpenAI: AI generation with QR Branding's accounts |
Note on LLM providers: with QR Branding's own accounts (the site and the managed endpoint), design prompts are transferred to Groq, Google (Gemini) or OpenAI, which act as QR Branding's processors. On the BYOK endpoint, prompts are transferred to the provider the customer chooses (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek or Qwen, or their own OpenAI-compatible endpoint) using the customer's own API key. Responsibility for that transfer lies with the customer, who maintains a direct contractual relationship with the provider; QR Branding acts as a technical intermediary.
Using the standard QR generation endpoint involves no transfer to LLM providers (processing takes place exclusively on Azure).
7. Review
This legal basis analysis must be reviewed:
- When new processing activities are added
- When the data processed by existing activities changes
- When LLM provider policies change
- At least once a year
Document generated on 2026-03-08.