Legal
Smol API Data Processing Addendum
For customers whose files contain personal data. It sets out what we do with that data as your processor, who else handles it, and how it is protected and deleted.
1. Scope and roles
1.1This addendum is part of the Smol API Terms of Service (the “Terms”). It applies whenever the files you send contain personal data and a data protection law applies to that data. “Data protection law” means the EU General Data Protection Regulation (the “GDPR”), the UK GDPR, the Swiss Federal Act on Data Protection, and any other law on personal data that applies to you or to us.
1.2“Customer personal data” means personal data in your content: the files you send, the files we return, the file names you give us and the metadata you attach to a job.
1.3For customer personal data you are the controller and Smol is your processor. If you are yourself a processor for your own customers, Smol is your sub-processor, and you confirm that your instructions to us are the ones your controller has authorised.
1.4For account data (your email address, billing details and usage records) Smol is a controller in its own right. That processing is described in the API privacy notice, not in this addendum. Annex 1 lists it for completeness.
2. What is processed, why and for how long
2.1The subject matter, nature, purpose and duration of the processing, and the kinds of personal data and of people involved, are set out in Annex 1.
2.2In short: we receive a file, compress or convert it or remove its metadata, return the result, and delete what we held. We do nothing else with it.
3. Your instructions
3.1We process customer personal data only on your documented instructions. Your complete instructions are the Terms, this addendum, each API request you make (its operation and options) and the settings you choose in the dashboard, such as how long results are kept.
3.2If a law that applies to us requires other processing, we tell you first, unless that law forbids it.
3.3We tell you if we believe an instruction breaks data protection law. We are not obliged to check your instructions for lawfulness, and we do not inspect your files to do so.
4. What we commit to
4.1Confidentiality. Everyone we authorise to handle customer personal data is bound by a duty of confidentiality.
4.2Security. We apply the measures in Annex 2, as required by Article 32 of the GDPR. See also section 8.
4.3Sub-processors. We use other processors only as section 6 allows.
4.4Requests from individuals. We help you, as far as we reasonably can, to answer people who exercise their rights over their data. We do not index or search the contents of files and keep them only briefly, so we usually cannot find a person’s data. If someone contacts us about data in your content and we can tell that it concerns you, we pass the request to you and do not answer it ourselves.
4.5Your own duties. Taking into account what we do and the information we hold, we help you meet your duties on security, breach notification, impact assessments and consulting a regulator (Articles 32 to 36 of the GDPR).
4.6Deletion and return. We delete customer personal data as set out in section 10.
4.7Showing that we comply. We give you the information you need to check that we meet this addendum, and allow audits, as set out in section 11.
5. What you are responsible for
5.1You are responsible for having a lawful basis for the personal data you send, for telling the people concerned, and for sending only what the processing needs.
5.2You choose how long results are kept, whether to have them delivered to your own storage, and when to delete a job. You keep your API keys secret.
5.3You are responsible for deciding whether the measures in Annex 2 are adequate for the data you send. Note in particular that the service is not end-to-end encrypted, and that we hold no independent audit report at present.
6. Sub-processors
6.1You give us a general authorisation to use sub-processors. The current list is on the sub-processors page, which forms Annex 3.
6.2We bind each sub-processor by a written contract to data protection duties no weaker than those in this addendum, and we remain responsible to you for what it does.
6.3We give at least 30 days’ notice, by email to the address on your account and on the sub-processors page, before a new sub-processor starts to handle customer personal data. Where we must replace a sub-processor urgently for security or continuity, we give as much notice as we can.
6.4You may object within the notice period on reasonable data protection grounds. We will discuss it with you in good faith. If we cannot resolve it, you may end the affected service before the change takes effect, and we refund any plan fee for the period after the end date.
7. International transfers
7.1Smol is based in the United States, and our hosting sub-processor runs a global network. Customer personal data may therefore be processed in the United States and in any country where that network operates. Storage and processing limited to the European Union is planned but is not available yet; we do not offer a fixed region today.
7.2European Economic Area. Where you transfer customer personal data that is subject to the GDPR to us in a country without an adequacy decision, the Standard Contractual Clauses approved by Commission Implementing Decision (EU) 2021/914 form part of this addendum. Module Two (controller to processor) applies where you are a controller, and Module Three (processor to processor) where you are a processor. For those clauses:
- Clause 7 (joining by further parties) is not used;
- in Clause 9, Option 2 (general written authorisation) applies, with the notice period in section 6.3 of this addendum;
- in Clause 11, the optional wording on an independent dispute body is not used;
- in Clause 17, Option 1 applies and the governing law is the law of Ireland;
- in Clause 18, disputes are resolved by the courts of Ireland;
- Annex I is completed by Annex 1 of this addendum, Annex II by Annex 2, and Annex III by the sub-processors page; and
- the competent supervisory authority is the one responsible for you under Clause 13 of the Standard Contractual Clauses.
7.3United Kingdom. Where the transfer is subject to the UK GDPR, the International Data Transfer Addendum to the EU Standard Contractual Clauses issued by the UK Information Commissioner (version B1.0) also forms part of this addendum. Its tables are completed by the details in clause 7.2 and the annexes, and neither party may end it under its Section 19.
7.4Switzerland. Where the transfer is subject to Swiss law, the Standard Contractual Clauses apply with references to the GDPR read as references to the Swiss Federal Act on Data Protection, and the Swiss Federal Data Protection and Information Commissioner as the supervisory authority.
7.5Where a sub-processor transfers customer personal data onward, we make sure a lawful transfer mechanism is in place. If these transfer terms conflict with the rest of this addendum or the Terms, the transfer terms prevail.
8. Security
8.1We apply the technical and organisational measures in Annex 2. We may change them as the service develops, but not in a way that lowers the overall level of protection.
8.2To be plain about the limits: the service must read each file in the clear to process it; we do not yet hold a SOC 2 report or similar certification; and no external penetration test has been carried out yet. The security page keeps this list up to date.
9. Personal data breaches
9.1We notify you without undue delay, and no later than 72 hours after we become aware of it, of a personal data breach that affects customer personal data. We send the notice to the email address on your account.
9.2The notice describes what we know at that point: what happened, the kinds and rough amount of data involved, the likely effects, and what we have done and will do about it. We add to it as we learn more.
9.3Because we keep files only briefly and do not index them, we often cannot tell which individuals a breach affects. Identifying and notifying them, and notifying a regulator, remains your decision as controller. We help you with it.
9.4A notice under this section is not an admission of fault.
10. Deletion and return
10.1Return. The result of a request is returned in the response, made available for download until it expires, or delivered to the storage address you give us. We keep no other copy to return.
10.2Deletion in normal use. Customer personal data is deleted automatically:
- a file in a direct request is not written to our file storage; the working copy the engine holds is deleted once the response has been sent;
- a job’s input is deleted when the job finishes, fails or is canceled;
- a job’s output is deleted when it expires (1 hour by default; you can set between 60 seconds and 24 hours), or at once when you delete the job;
- a job’s record, which holds the file name, the metadata and the addresses you supplied, is erased 30 days after the job ends.
10.3Two items are removed by a clean-up that runs every hour, rather than by a job’s own timer:
- a file that is uploaded but never attached to a job, and the parts of an upload that was never finished: deleted once they are 24 hours old;
- the stored copy of a job response kept when you send an idempotency key, which includes the file name and metadata: deleted once it is 24 hours old.
10.4At the end of the agreement. Nothing remains beyond the timers above, so there is no separate deletion step. On request we confirm in writing that no customer personal data is held.
10.5Proof. For each job you can fetch a receipt stating what was processed (as hashes and sizes) and when the input and output were deleted. Receipts are signed with an Ed25519 key.
10.6We may keep customer personal data longer only where a law that applies to us requires it, and then only for that purpose.
11. Information and audits
11.1On request we give you the information reasonably needed to show that we meet this addendum: this addendum and its annexes, the security page, and written answers to a reasonable questionnaire, once in any 12 months.
11.2We have no independent audit report to offer at present. When we have one, we will share a summary under a duty of confidentiality, and it will normally satisfy an audit request.
11.3If that information is not enough to meet your duties under data protection law, you may audit us yourself or through an independent auditor bound by confidentiality. An audit takes place no more than once in any 12 months (unless a regulator requires more, or there has been a breach affecting your data), on at least 30 days’ written notice, in working hours, to a scope we agree beforehand, and without access to other customers’ data. You bear your own costs and our reasonable costs of supporting it.
11.4The service runs on our hosting sub-processor’s infrastructure. We cannot give you physical access to its data centres; for those we rely on the audit reports it publishes.
12. United States privacy laws
12.1Where the California Consumer Privacy Act or a similar state law applies, we act as your service provider. We do not sell or share customer personal data, do not use it for anything other than providing the service to you, and do not combine it with data from other sources. We tell you if we can no longer meet these duties.
13. Liability and order of documents
13.1The limits on liability in the Terms apply to this addendum. They do not limit what either of us owes to an individual under the Standard Contractual Clauses or data protection law.
13.2On data protection matters this addendum prevails over the Terms, and the transfer terms in section 7 prevail over both.
14. Duration and changes
14.1This addendum lasts for as long as we process customer personal data for you, including after the Terms end until the data has been deleted.
14.2We may change it in the way the Terms allow, and never so as to give less protection than data protection law requires.
Annex 1: Details of the processing
| Item | Detail |
|---|---|
| Controller (data exporter) | The customer named on the account, reachable at the account’s email address. |
| Processor (data importer) | [TO BE COMPLETED: legal entity name], [TO BE COMPLETED: registered address], operating Smol from San Francisco, California. Contact: [email protected]. Data protection contact and EU or UK representative: [TO BE COMPLETED: name and contact, if one is appointed]. |
| Subject matter | Compressing files, converting them between formats and removing their metadata, through the Smol API. |
| Nature of the processing | Receiving a file, holding it temporarily, reading and transforming it with automated tools, returning or delivering the result, and deleting what was held. No person looks at the file, and its contents are not indexed, analysed or used for anything else. |
| Purpose | To provide the service the customer asks for in each API request. |
| Duration | For as long as the customer uses the service. Each file is held only for the periods in section 10. |
| Types of personal data | Whatever the customer’s files contain. Depending on the files, this can include images, video and audio of people, documents that name or describe people, and metadata embedded in files such as location, device and author. Also the file names the customer supplies and the metadata it attaches to a job. |
| Special categories of data | Not asked for and not known to us. A file may contain them if the customer chooses to send it. The customer decides whether the service is suitable for such data. |
| People concerned | Whoever appears in or is described by the customer’s files: typically the customer’s own users, customers, staff and the people they deal with. |
| How often | Continuously, each time the customer makes a request. |
| How long data is kept | As set out in section 10: until the response is sent (direct requests); until the job ends (job inputs); until expiry, at most 24 hours (job outputs); 30 days after the job ends (job records). |
| Sub-processors | See the sub-processors page. Only the hosting sub-processor handles the contents of files. |
Account data (outside this addendum)
Smol processes the following as a controller, to run accounts and billing: the account email address, name, country and tax ID; the card brand and last four digits; the payment provider’s customer reference; API key hashes; and usage records (for each request: its time, operation, file kind, sizes, processing time, outcome, error code, amount charged, and the key and account identifiers). Usage records contain no file names and no file contents. Each record is kept for 400 days; daily totals drawn from them are kept for as long as the account exists.
Annex 2: Security measures
These are the measures in place in the service as built. Each one can be checked against how it works.
Keeping as little as possible
- Files in direct requests (up to 25 MB) are streamed to the processing engine and the result streamed back. They are not written to file storage. The engine’s temporary working copy is deleted once the response has been sent.
- Files for jobs are stored only for the periods in section 10 and are deleted by a timer that belongs to the job. As a second line of defence, the job’s record and any output still present are erased 30 days after the job ends.
- The customer can delete a job’s files at once, and can have results delivered to its own storage.
- Usage records hold sizes, file kinds, timings, error codes, and key and account identifiers. They hold no file names and no file contents.
Isolating the processing engine
- The engine runs in containers that have no outbound internet access and hold no credentials.
- It runs as an unprivileged user, and each request works in its own private directory.
- A file’s type is worked out from its contents, not from its name, and the working copy is never named after what the caller called it.
- The tools that read files run with an emptied environment and are stopped when the time limit is reached.
- The image library is restricted by policy: only an allow-list of image formats can be read or written, and it cannot run other programs, follow indirect file references or open pipes.
- Limits apply to file size, pixels per image, frames, pages, media length and time per request.
Access and keys
- API keys are stored as SHA-256 hashes. A key is shown once when created and cannot be recovered afterwards.
- A job can be reached only with a key of the account that created it. Its result can also be fetched through a signed download link given to that account, which stops working when the result expires.
- Webhook deliveries are signed with HMAC-SHA256. Receipts are signed with Ed25519.
- Addresses supplied by customers (for inputs, outputs and webhooks) must be public https addresses; private, loopback and internal addresses are refused, and redirects are checked one step at a time.
- Rate limits, concurrency limits and a monthly spend cap apply to every account.
- Dashboard sign-in sessions are stored as hashes, and dashboard changes are accepted only from our own pages.
In transit and at rest
- The API is served over HTTPS.
- Stored files and records are held on the hosting sub-processor’s storage, which it encrypts at rest with AES-256, according to its published documentation. Smol does not hold the encryption keys.
- This is not end-to-end encryption: the service reads each file in the clear in order to process it.
Organisation
- Access to production systems is limited to the people who operate the service.
- Card details are entered with and held by the payment provider, never by us.
- Not yet in place: an independent audit report such as SOC 2, an external penetration test, and a published uptime history.
Annex 3: Sub-processors
The sub-processors authorised under section 6 are those on the sub-processors page on the date you accept the Terms, as changed from time to time under section 6.3. Questions: [email protected].