Privacy Notice

Coreframe Labs Ltd (“Coreframe”, “we”, “us”) is a company registered in England & Wales. We build and operate Coreframe Relay, a webhook receipt, buffer, retry and dead-letter-queue service (“Relay”, the “Service”). This Notice explains what personal data we collect, why, on what legal basis, who we share it with, and what rights you have under UK GDPR and the Data Protection Act 2018.

Questions about this Notice or a data protection request: info@coreframe-labs.dev. This is also Coreframe’s security contact address.

1. Two roles: when we are the controller, and when we are not

Relay sits in front of a customer’s webhook endpoint. Because of that, this Notice has to describe two genuinely different kinds of processing, and it is important you understand which applies to you:

• We are the data controller for your Relay account data — the name, email address and team details you give us when you sign up and use the dashboard. This section of the Notice tells you what we do with that data and why, in the normal way a privacy notice does.
• We are a data processor for the content of the webhooks you route through Relay. If you configure a Route that receives, say, Stripe payment events, Shopify order events or WhatsApp Business API messages, those payloads may contain personal data belonging to your own customers or end-users — a cardholder’s name, a shipping address, a phone number, a message body. We do not decide what you send through Relay, we do not use it for our own purposes, and we act only on your instructions as set out in our Data Processing Addendum. If you are a business sending your own customers’ personal data through Relay, you are the controller of that data and you are responsible for having your own lawful basis and your own privacy notice covering it — this document does not discharge that obligation for you.

2. Account data we collect, and why (we are the controller)

We do not currently send marketing email based on your account data. Transactional email — sign-up verification and password reset — is sent because it is necessary to operate the account you asked us to create, not on a consent basis.

3. What we process on your behalf (we are the processor)

When you create a Route, you configure a destination URL and, optionally, authentication headers Relay should attach when forwarding to your own downstream system. Those header values are your credentials, not personal data about a third party in the ordinary case, and are encrypted at rest (AES-256-GCM, a random initialisation vector per value) the moment you save them; no API response, including ones we control, ever returns a header value once set — only its name.

Two genuinely different things happen to the webhook traffic itself, and they carry different amounts of data at rest:

• Successfully delivered webhooks: metadata only, not the payload body. Our delivery log records the request ID, the sender’s IP address, delivery status, attempt count, the destination’s response code, latency, and the payload’s size in bytes. It does not store the payload’s content. Once a webhook is delivered, Relay does not retain what was inside it.
• Permanently failed webhooks: the payload is retained, so you can review and replay it. If a webhook exhausts its retry attempts, it lands in the dead-letter queue, and — unlike a successful delivery — the actual payload content is stored (inline for payloads under 64KB; referenced via object storage above that), because the entire point of the dead-letter queue is to let you inspect and manually retry it. This is the one place a third party’s personal data (for example, a cardholder’s name and email inside a failed Stripe event) is genuinely held at rest inside Relay in more than metadata form.

Sender IP addresses (the address the webhook arrived from — typically the sending platform’s own infrastructure, e.g. Stripe’s or Shopify’s, not your end-user’s) are recorded against every delivery attempt for abuse detection and troubleshooting.

4. Retention — stated honestly

As of this Notice’s effective date, Relay has no automated process that deletes account data, delivery-log rows or dead-letter-queue payloads on a schedule. The dashboard’s dead-letter-queue page shows a “time remaining” indicator against each item; that indicator reflects an intended future retention policy and does not currently result in automatic deletion when it reaches zero. We are not going to publish a specific 7-day, 30-day or 90-day retention promise until an automated process actually enforces one — a stated retention period with no code behind it would be a false claim in this Notice, not a missing feature.

Until that changes:

• Delivery-log metadata and dead-letter-queue payloads are retained until you delete them yourself (the dashboard supports manual deletion and retry of dead-letter items), your account is deleted, or you ask us to delete them.
• Account and team data is retained for as long as your account is active, plus a limited period afterwards where we have a legal or accounting reason to keep it (for example, invoice records, once billing exists, are ordinarily kept around six years to meet UK tax record-keeping obligations).
• You can ask us to delete your account and associated data at any time — see Section 6.

5. Sub-processors

The following organisations process data on our behalf in order to run the Service. This list is factual as of this Notice’s effective date and will be updated if it changes — see the Data Processing Addendum for the change-notice mechanism that applies if you are a business customer.

Sentry (error monitoring) and Mixpanel (product analytics) are integrated in Relay’s codebase but require an explicit configuration value (a Sentry DSN, a Mixpanel project token) to activate, and neither is configured in Coreframe’s reference deployment settings as of this Notice’s effective date. Neither is currently receiving data. If either is switched on in the future, this Notice will be updated to name it here and describe what it receives before it goes live.

6. International transfers

Two sub-processors above sit outside the UK, so UK GDPR Chapter V requires us to name the safeguard for each:

• Resend — Tokyo, Japan. The UK maintains adequacy regulations recognising Japan’s data protection framework (the Act on the Protection of Personal Information, APPI) as adequate for restricted transfers to private-sector organisations regulated as APPI “personal information handling business operators”. Where that basis applies, no additional Article 46 safeguard is required, and it is our primary basis for this transfer. Because Resend is a US- headquartered company using Tokyo-region infrastructure rather than a Japan-incorporated entity in every respect, we also rely on the standard contractual safeguards in Resend’s own data processing terms (which incorporate the UK International Data Transfer Addendum to the EU Standard Contractual Clauses) as a fallback, so the transfer is covered either way.
• Vercel — United States. Our agreement with Vercel incorporates the UK International Data Transfer Addendum to the EU Standard Contractual Clauses (or, where Vercel is a certified participant, the UK extension to the EU-US Data Privacy Framework) as the transfer safeguard.

We have not independently verified every sub-processor’s exact transfer paperwork against the standard above beyond what is published by each provider — see the flag at the top of this Notice about solicitor review.

7. Your rights

Under UK GDPR, you have the right to:

• be informed about how your data is used (this Notice);
• access a copy of your personal data;
• have inaccurate data corrected;
• have your data erased (“right to be forgotten”), subject to legal exceptions;
• restrict or object to certain processing;
• receive your data in a portable format, where processing is based on consent or contract and carried out by automated means;
• not be subject to solely automated decisions with legal or similarly significant effects (Relay does not make any such decisions about you); and
• complain to the Information Commissioner’s Office (ICO) — ico.org.uk, 0303 123 1113 — although we would appreciate the chance to resolve your concern directly first.

To exercise a right, email info@coreframe-labs.dev. We will verify your identity before acting on a request and respond within one month (extendable to three months for complex requests, with an explanation).

If your request concerns data inside a webhook payload processed through someone else’s Route — i.e. you are the end-user of one of our business customers, not a Relay account holder yourself — we are a processor for that data, not the controller, and UK GDPR expects the request to go to the controller (our customer) in the first instance. Tell us who the relevant business is and we will either forward your request to them or assist them in responding to you directly, per our Data Processing Addendum.

8. Security

A summary of the technical measures protecting the data described above — the full commitments to business customers are in the Data Processing Addendum:

• Destination authentication headers you configure are encrypted at rest with AES-256-GCM, keyed per value, and are never returned by any API once set.
• Tenant isolation, stated honestly. Every query that reads or writes Route, delivery-log or dead-letter-queue data is written to filter by your team ID, and that scoping is what actually separates one customer’s data from another’s in production today. PostgreSQL Row-Level Security policies have also been created and enabled on all six of those tables in the production database, as a second, database-layer barrier — but as of this Notice’s effective date, the production application has not yet been switched to the restricted database role those policies are designed to enforce against, so that second barrier is built and tested but not yet the thing actively stopping a cross-tenant query in production. Completing that switch is a named, outstanding operational action, tracked the same way ICO registration is at the top of this Notice. The application-level scoping, and the Row-Level Security policies’ correctness once the restricted role is in use, are both verified by an automated cross-tenant isolation test suite run as part of our release process.
• All traffic to and from the Service is encrypted in transit (TLS).
• Access to production infrastructure is limited to the company’s director.

9. Changes to this Notice

We will update this Notice as Relay’s architecture and sub-processor list change — most importantly, when an automated retention process ships (Section 4), when Sentry or Mixpanel is activated (Section 5), or when a new sub-processor is added (Section 5, Section 6). We will change the effective date at the top of this page when we do.

10. Who we are

Coreframe Labs Ltd, a company registered in England & Wales. Contact for all privacy matters, including data protection requests: info@coreframe-labs.dev.