Skip to content
How it worksTemplatesPricingHelpFor developers
Sign in BroadPaper Cloud →
How it worksTemplatesPricingHelpFor developers Sign in BroadPaper Cloud → Start free →

Legal

Terms & ConditionsPrivacy PolicyCookie PolicyRefund Policy

Who we are

Codingbadger Creative Limited, trading as BroadPaper.
Registered in England and Wales, company number 16896863.
72 Churchill Way, Broadbridge Heath, RH12 3TZ

hello@broadpaper.com

Privacy

Privacy Policy

Last updated 28 September 2026 · Applies to www.broadpaper.com, BroadPaper Cloud, the demo, the documentation and the BroadPaper software.

This policy explains what personal data we collect when you use this website, the demo, the documentation, your account, BroadPaper Cloud and the BroadPaper SDK software, why we collect it, how long we keep it, and what rights you have. Who we are and how to reach us is in the margin. We are subject to the UK GDPR and the Data Protection Act 2018.

We are the controller of the data about you as a visitor, an account holder or a customer. When a business puts data about its customers, clients or staff into BroadPaper Cloud, that business is the controller of it and we process it for them as their processor, under section 4.11 of the terms. If your details are in a document a business made with BroadPaper Cloud, that business is who to ask about them first; section 4.2 below explains what we hold.

The short version:

  • The SDK software collects nothing at all.
  • This website collects almost nothing, and analytics only if you turn them on.
  • BroadPaper Cloud keeps what you put in it, for you, and nothing else. Spreadsheets and documents you bring in are read in your browser, the service never receives the file itself, no AI model sees your content unless somebody in your workspace asks the design assistant for a design (section 4.7) — and then never the values in your data — nothing you put in is used to train any model, and nothing is sold or used for advertising.

1. The SDK software

The BroadPaper packages run inside your own application and infrastructure. They make no network calls to us, do not contain analytics or telemetry, and verify licence keys locally. We never receive your templates, your data, your themes or the documents you produce. If you use the render service, it is a server you run; we do not operate it for you.

2. This website, the demo and the documentation

What we collect

  • Server logs. The hosting platform records the IP address, user agent, requested address, referrer and time of each request, as web servers do. We use these to keep the site running and secure and to see how much it is used. Logs are kept for no more than ninety days.
  • Your consent choice. One cookie, bp_consent, records whether you accepted optional cookies. See the cookie policy.
  • Analytics, only if you opt in. We use Microsoft Clarity on this website, and it loads only after you turn on the Analytics category in the cookie banner — until then the script is never requested. It records the pages you view, clicks, scrolling and a replay of your session, with text and form fields masked, together with your approximate location, browser and device from your IP address. Microsoft process this for us and may combine it with their own identifiers; the cookies involved are listed in the cookie policy. Withdraw consent at any time through Cookie settings and the recording stops straight away, on the page you are reading. Clarity does not run in BroadPaper Cloud.
  • The demo’s drafts. The demo keeps the report you are editing in your browser’s local storage so you can come back to it. That data stays in your browser and is never sent to us.

What we do not collect

No advertising cookies, no social media pixels, and nothing at all in this section unless you opted in. Fonts are served from this site, not from a third party, so opening a page here tells nobody else you did.

If you do turn analytics on, be aware of what that honestly means: Clarity is Microsoft’s, and the identifiers it sets are ones Microsoft also use across their own properties. We set advertising storage to denied so that identifier is not used to target you, and we neither receive nor ask for anything that would let us do so — but “no cross-site tracking whatsoever” would be an overstatement, and we would rather say so than claim otherwise.

3. Your account

One account works for both products. Accounts, sign-in and organisations are operated for us by Clerk (Clerk.com). If you create an account, Clerk holds your name, email address, sign-in identifiers and authentication records, and we can see your name, email address and user id through Clerk’s API. We do not receive or store your password. If you sign in with Google or Microsoft, that provider tells Clerk who you are, under its own privacy policy.

We use this to identify you, to know which organisation or workspace you belong to, to issue an SDK licence, to give Creem an address to invoice, to show you who else a sign-in is shared with before you delete it, and to answer support requests. Because a service or a licence has to be provided to somebody, and an invoice has to name a customer, this processing is necessary to perform our contract with you. Sending renewal, billing and security notices is in our legitimate interest in running the service; we will not send marketing email unless you ask for it, and every marketing email will have an unsubscribe link.

SDK licence organisations

Against an SDK organisation — not against you personally — we store its billing and licensing state: its payment provider customer and subscription identifiers, which licence it holds, when that licence expires, every licence certificate we have issued it, and a record of the billing events we acted on. That is held in our own database, on Microsoft Azure in the UK, and is readable only by us and by members of the organisation through an authenticated request. A short summary of the same state is also written to Clerk’s private organisation metadata so that support can see it beside the account; it is a copy, and it never contains a certificate.

The record of certificates is kept even after one is superseded, because a licence is verified offline and a copy of an expired one can still be inside a document years later; being able to say which certificate produced a given file is the point of keeping it.

SDK account data is kept while you have an account and for six years afterwards, because tax law requires us to keep invoicing records for that long. You can close an SDK account by writing to us.

SDK evaluation licences

If you ask for a free evaluation licence, we store — against you, as well as against your organisation — your Clerk user identifier, the email address Clerk holds as your primary address at the time, your organisation’s name, your answer to “What are you building?” if you gave one, when the licence was issued and when it ends, each extension we make and who made it, and whether you have unsubscribed. We keep the address in our database and never put it in the licence certificate, because a certificate ends up in builds and repositories.

We use it to issue the licence and email it to you, to limit evaluations to one per person and one per organisation, and to send you a few emails about your evaluation: a note after a few days asking whether it installed cleanly, an offer of a short call, and a reminder the week before it ends. Every one of those emails has an unsubscribe link, and they stop when your organisation buys a licence. We also send ourselves one notification per evaluation with the same details, so that a person here can reply to you.

We rely on performance of a contract for issuing the licence and sending it to you, and on our legitimate interest in hearing from the people evaluating the SDK and helping them for the follow-up emails, which you can stop at any time. Emails are sent for us by Resend (section 7).

Evaluation records are kept for two years after the evaluation ends, then deleted, unless your organisation has since bought a licence, when they are kept with its account data as above. You can ask us to delete yours sooner by writing to us.

4. BroadPaper Cloud

4.1 Your workspace and its plan

When you first sign in to BroadPaper Cloud you give a business name, and a workspace is created for it, linked to a Clerk organisation. Against the workspace we store the business name, the Clerk organisation id, which plan it is on, its Creem customer and subscription identifiers and subscription status, when the paid period ends, and counts of what it has used (for example documents made this month). If you arrived at BroadPaper Cloud through a link we placed somewhere — a launch listing, a post, or the credit line on a free document — we also store a short label naming that placement, such as producthunt, once, when the workspace is created. It says which link, never anything about you, and we use it to learn which places are worth our time, which is our legitimate interest. We keep a record of the billing events Creem sent us for the workspace, so that the same payment is never acted on twice. We do not keep your name or email address in Cloud’s database; they stay with Clerk.

We use this to provide the plan you chose and enforce its limits, which is necessary to perform our contract with you.

People in a workspace. An admin can invite a colleague by entering their email address. Clerk sends the invitation and holds the address, whether the invitation is pending, accepted or revoked, and — once it is accepted — the colleague’s membership and role; we do not copy any of it into Cloud’s database. Everybody in a workspace can see the names, email addresses and roles of the others in it. This lets the business decide who uses its workspace, which is necessary to perform our contract with it. If you were invited, the business that invited you gave us your email address for that purpose; an invitation you do not accept is removed when the business revokes it or its account is deleted.

4.2 What you put in it

BroadPaper Cloud stores, privately for your workspace:

  • Data you bring in or type — the columns and rows of each set of data, the name it was given, and a preview of its first fifty rows and a few sample values per column, which is what lets the screens show your data without downloading all of it.
  • Designs, their earlier versions, and a picture of each design’s first page drawn with its own data.
  • Documents — every PDF Cloud produces for you, kept so you can download it again.
  • Letterheads — the business details you enter for your documents, such as company name, address, email, phone, website, company or VAT number, and your logo.
  • Share links — their labels, settings and activity (section 4.4).
  • The name of a file you turned into a design, and the file identifier of a spreadsheet linked from Google Drive or OneDrive (section 4.3).

That content may include personal data about other people — your customers, clients or staff. For that data you are the controller and we are your processor: we use it only to provide BroadPaper Cloud to you, as section 4.11 of the terms sets out.

Files you bring in are read in your browser. A spreadsheet, CSV or JSON file, and a Word document or PDF turned into a design, is opened by the page in your own browser; what is sent to us is the rows, columns and design taken from it, never the file.

No model reads your content unless you ask it to. Matching your columns to a design’s fields, working out types and totals, turning a document into a design and making your documents are done by ordinary, deterministic code. The one exception is the design assistant, which is used only when somebody in your workspace asks it for a design, and which section 4.7 describes. Nothing you put into BroadPaper Cloud is used to train or improve any machine-learning or artificial-intelligence model, ours or anybody else’s, and none of it is sold or used for advertising. Our staff do not look at it unless you ask us to in a support request, or it is necessary to investigate a security incident or abuse, or the law requires it.

4.3 Google Drive and OneDrive

If you choose a spreadsheet from Google Drive or OneDrive, you sign in to Google or Microsoft in their own window and pick the file in their own picker. The access token they issue is held in the memory of your browser tab only — never written to your browser’s storage, never sent to our service, and gone when you close the tab. Your browser uses it to download the one file you picked, and hands the file to the same in-browser reader as a dropped file.

  • What we ask for. From Google, access only to the files you choose with the picker (the drive.file permission) — not the rest of your Drive. From Microsoft, permission to read the files your account can open in OneDrive and SharePoint (Files.Read.All), which BroadPaper uses only to download the file you pick, and again when you press Refresh; and your basic profile, which tells the picker which OneDrive to show.
  • What we keep. Against the set of data: which service it came from, the file’s identifier, drive identifier and name, the sheet you used, and, for a file shared by link, Google’s resource key, so that Refresh can download the same file again. No sign-in, token, email address or folder listing is kept.
  • Removing access. Choose Stop refreshing from it on the data, and remove BroadPaper in your Google account’s third-party access or your Microsoft account’s app permissions (for a work account, ask your administrator).

BroadPaper Cloud’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. In particular, data from Google Drive is used only to bring in the spreadsheet you chose, is not used for advertising, is not transferred to anyone except as needed to provide that feature or as the law requires, and is not read by any person at BroadPaper unless you ask us to in a support request.

4.4 Share links, and the people who open them

A share link lets anyone who has it view and download one document, without an account. If you open somebody’s link, this is what happens to data about you:

  • Each time the link is opened, downloaded, or given a wrong password, we record which of those it was, the time, and a short description of the browser and device, such as “Chrome on Windows”.
  • To count distinct visitors, we combine your IP address, your browser’s user agent and the link’s own identifier into a keyed one-way hash, and store the hash. Your IP address itself is not stored with the link, the hash cannot be turned back into it, and because the link’s identifier is part of it, the same person on two different links produces two unrelated values — so it cannot be used to follow you from one link to another. A wrong-password attempt is recorded without a hash. Separately, our service logs record the IP address of each request with the address requested, including the link, for up to ninety days (section 4.5).
  • The business that sent the link sees the number of views, downloads, distinct visitors and wrong-password attempts, when it was last opened, and its most recent activity as time and device description. It never sees your address or the hash.
  • A link keeps about its newest thousand events; older ones are removed from time to time as the link is used. Everything is deleted when the business deletes the link, the document, or its account.
  • The share page sets no cookies and uses no browser storage, and does not load our sign-in provider’s script. Opening it sends your IP address to our hosting provider, as any web page does, and the document itself is downloaded from our file storage through a link that expires after a few minutes.

We do this in the legitimate interest of the business that sent you the document, in knowing whether it arrived, and in our own interest in protecting links from password guessing. The business that sent the link is the controller of that record; ask it, or us, if you have questions about it.

4.5 Keeping the service secure

BroadPaper Cloud’s service records each request in its logs: the IP address, the address requested (which, for a share link, includes the link), the response, and the time. We use them to run the service, investigate faults and protect it from abuse, which is our legitimate interest. Logs are kept for no more than ninety days.

To slow down abuse, the service counts recent requests in memory — by IP address, by workspace or by user, and wrong passwords by IP address and link. Those counts are never written to storage; each stops counting against anybody within an hour, is cleared from memory from time to time after that, and all of them are lost whenever the service restarts.

BroadPaper Cloud itself contains no analytics, advertising or tracking scripts, and no session recording.

4.6 How long Cloud keeps things

  • Your content is kept until you delete it or delete your account. We do not delete it because a plan changed or lapsed; limits apply to new actions, not to what you already have.
  • Earlier versions of a design are thinned once a design has a long history: every version from the last thirty days is kept, then one a day, then one a week after a year. The first version and every restore are always kept.
  • Share-link activity is kept as section 4.4 describes.
  • Replaced files — the rows of a set of data after an edit or refresh, an old thumbnail — are removed when they are replaced.

Deleting your account, from Plan and billing → Delete account, happens in this order: any paid subscription is cancelled with Creem; every file in the workspace is deleted and checked; the workspace and everything recorded against it — data, designs and their history, documents, share links and their activity, letterheads, folders and billing events — are deleted from the database; and then your workspace’s Clerk organisation and your sign-in are deleted. Because one sign-in serves both products, that also removes you from any SDK organisation, which you are shown and asked to acknowledge first.

After that, we keep only:

  • if the workspace ever had a subscription, a record that it was closed — its old identifier, its Creem customer and subscription identifiers, and the date, with no name, email or content — so that a billing message arriving afterwards is recognised and ignored rather than acted on. A billing message that arrives afterwards is itself recorded as ignored, with Creem’s identifier for the message and the old workspace identifier, and nothing else;
  • service logs, until they expire (section 4.5);
  • copies inside our database provider’s automatic backups, which are overwritten within thirty-five days and are not used to restore individual accounts;
  • invoices and payment records at Creem, who keep them as merchant of record.

A document that has already been downloaded or sent is outside our systems and is not affected.

4.7 The design assistant

The design assistant drafts a design from a description, or changes the design you are working on. It uses a large language model, and it is used only when somebody in your workspace types a request into it and asks for a draft. Nothing is sent to it in the background, and every other part of BroadPaper Cloud works the same without it.

What is sent with each request:

  • what the person typed, up to 2,000 characters;
  • the design as it stands — its layout, styles and wording, including any text somebody has typed into it — with your logo and every other embedded image taken out first;
  • the names, labels and types of the columns in the data the design uses (“Invoice number, text”, “Amount, money”), and which blocks were selected.

What is never sent: the values in your data — no rows, no figures, no names or sample values from a spreadsheet — your files, your letterhead details, or your name and email address.

Who processes it. The model is Claude, provided by Anthropic, which processes each request for us as a sub-processor, under its commercial terms and data processing addendum. We call Anthropic’s own API directly. Anthropic is based in the United States and stores what it keeps there, and the model may run in whichever geography Anthropic serves from at the time — so a request is processed outside the UK and the European Economic Area.

What Anthropic does with it. Anthropic does not use commercial customers’ content to train its models without their permission, and we have not given it. It deletes a request and the draft it produced within 30 days. Its automated trust and safety systems check requests; if they flag one, Anthropic may keep that request and draft for up to two years, and the safety scores it gave them for up to seven, to investigate and prevent misuse, and its staff may review it.

What we keep. We keep nothing of the request’s content ourselves. For each request we record who made it, when, whether it was a new design or a change, how much of the workspace’s allowance it used, and whether the draft was applied or discarded. We do not keep what was typed or the draft itself: a draft you accept becomes part of your design, and one you discard is gone. The records are deleted with the workspace.

A draft is a suggestion, and it is yours to check before you use it; see section 4.12 of the terms.

5. Purchases

Payments for SDK licences and for BroadPaper Cloud are processed by Creem, who act as merchant of record for BroadPaper. Creem take payment, handle sales tax and VAT, and issue the invoice; the contract of sale for the payment itself is with them, under their own terms and privacy policy.

We never see or store your card number. When you start a Cloud checkout we give Creem your email address, the identifier of your workspace and the identifier of its Clerk organisation, so the payment can be matched to it. From Creem we receive a customer identifier, a subscription identifier, the billing email address, the subscription’s status and period, and confirmation that a payment succeeded, failed or was refunded. We keep the identifiers, the status and the period with the record of your licence or workspace; the billing email address is not kept.

6. Support email

If you write to us we keep the correspondence for as long as needed to deal with it and for three years afterwards, so that we can see what was said if the question comes back. If you ask us to look at something in your Cloud workspace, we look only at what the question needs.

7. Who we share data with

We use these service providers, and they process data only on our instructions unless stated otherwise:

  • Microsoft Azure (hosting, in the United Kingdom) serves this site and the BroadPaper Cloud application, runs the account API and the Cloud service, holds both databases and Cloud’s file storage, and collects the server logs we use to keep them working. It is the only provider that stores your Cloud content, with one exception: Anthropic keeps a design assistant request for up to 30 days, or longer if its safety systems flag it, as section 4.7 describes.
  • Clerk operates accounts, sign-in and organisations for both products, as section 3 describes.
  • Creem processes payments as merchant of record, as section 5 describes.
  • Anthropic (Claude, through Anthropic’s API, in the United States) generates designs for the design assistant, and only when somebody asks it for one, as section 4.7 describes. It receives the request and the design without its images, never the values in your data. Anthropic processes requests under its commercial terms and data processing addendum, does not use commercial customers’ content to train its models, and deletes requests and drafts within 30 days, except that one its safety systems flag may be kept for up to two years.
  • Resend sends the emails about an SDK evaluation licence — the key, and the few follow-ups — on our instructions, as section 3 describes. It receives the recipient’s address and the email’s contents.
  • Microsoft Clarity processes website analytics, but only for visitors who turned the Analytics category on, and never in BroadPaper Cloud.
  • Google and Microsoft, for bringing in a file from Google Drive or OneDrive. Google’s sign-in and picker scripts are loaded when you open the screen for bringing in data, so Google receives your IP address and browser details even if you do not use Google Drive. Microsoft is contacted only when you press the OneDrive button. You sign in with them directly and they act under their own privacy policies; we send them nothing about you, but they see that your browser is using BroadPaper’s connection to them.
  • Professional advisers and authorities, where the law requires it.

We do not sell personal data and do not share it for advertising. If BroadPaper, or the part of it that runs a product, is sold or merged, the data would pass to the new owner under this policy.

8. International transfers

Our hosting, both databases and Cloud’s file storage are in the United Kingdom. Clerk, Creem, Resend, Microsoft Clarity, and Google and Microsoft for the file connectors, may process data in the United States or elsewhere; where they do, transfers are covered by the UK’s adequacy decisions (including the UK extension to the EU–US Data Privacy Framework) or by the International Data Transfer Agreement or standard contractual clauses.

The design assistant’s requests are processed by Anthropic, in the United States and wherever else Anthropic runs its models, so each request is transferred outside the UK and the EEA. Those transfers are safeguarded by the Standard Contractual Clauses in Anthropic’s data processing addendum, with the UK’s International Data Transfer Addendum to them. We do not rely on Anthropic being certified under the EU–US Data Privacy Framework.

Our hosting stays in the United Kingdom; the design assistant is the one part of BroadPaper Cloud that may process your content elsewhere, and only when somebody asks it for a draft.

9. Security

Everything is sent over encrypted connections. Cloud’s files are held in private storage that can only be reached through links we sign for your request, which expire after minutes for documents and after about two hours for the pictures of designs. Share-link passwords are stored only as salted hashes, share-link visitors as keyed hashes, and Google and Microsoft access tokens are never stored at all. Access to production systems is limited to the people who run them. No system is perfectly secure; if a breach affected your personal data in a way that put you at risk, we would tell you and, where required, the Information Commissioner’s Office.

10. Your rights

You can ask us to tell you what personal data we hold about you, to correct it, to delete it, to restrict or object to how we use it, and to give you a copy in a portable form. Where we rely on consent (the analytics cookie), you can withdraw it at any time through Cookie settings in the footer. In BroadPaper Cloud you can correct or delete most things yourself, download every document, and delete your account from Plan and billing. Write to the privacy address below; we will reply within one month.

If your data is in a business’s BroadPaper Cloud workspace — as one of its customers, say, or as someone who opened its share link — your request is best made to that business, which controls it. If you write to us instead, we will pass it on to the business, or help it respond.

If you are unhappy with how we have handled your data you can complain to the Information Commissioner’s Office at ico.org.uk, though we would rather you told us first.

11. Children

The website, BroadPaper Cloud and the software are for businesses and developers and are not directed at children under sixteen. We do not knowingly collect data from them.

12. Changes

We will update this policy when what we collect, or who processes it, changes, and the date at the top will move. Material changes to how we use account data will be notified by email or in the application.

13. Contact

Privacy questions go to the privacy address: privacy@broadpaper.com, or by post to the address in the margin.

Recurring client reports, without the recurring work.

BroadPaper Cloud

How it works Recurring client reports Templates Free document templates Pricing Help and support Sign in

For developers

The SDK Documentation Guides SDK pricing Licence account

Company

Contact LinkedIn Terms & Conditions Privacy Policy Cookie Policy Refund Policy
© 2026 Codingbadger Creative Limited, trading as BroadPaper. Set in Fraunces and IBM Plex. Every page of this site is a static file.
Cookies

This site uses one strictly necessary cookie to remember this choice. Optional analytics cookies are off unless you turn them on. Cookie policy