What Wedlark does with your information.

You didn't sign up for Wedlark and you shouldn't have to. A couple used Wedlark to organise their wedding, put your household on their guest list and sent you a link. Opening that link is how you reply — there's no account, no password and nothing to join.

That's the list, including the one item you didn't hand over on purpose. There is no email address, no phone number, no postal address and no password, because you were never asked for any of them. It also means we have no way to contact you directly — which matters below, when it comes to asking us for something.

A guest can be marked as a child by the couple. Nothing extra is stored about a child: it's the same short list — a name, whether they're coming, what they're eating — entered by the adults in their household.

One link per household is what saves everyone an account. It also means the link is the only credential: anyone who has it can see your household's answers, including the dietary notes, and can change them. In practice that's the people you live with, which is the intent.

If your link has ended up somewhere it shouldn't, tell the couple. There's no reissue button today — what they can do is remove the household and add it again, which produces a new link and clears the answers already given.

The couple decided to invite you, decided which questions to ask you, and decide what happens to your answers afterwards — including handing the food requirements to their caterer. Wedlark is the tool they're doing it with, and holds the information on their behalf.

We say so plainly because it decides who to ask when you want something changed, and because the honest answer isn't "us". It doesn't mean we'll send you back to them and wash our hands of it; the third route below exists precisely for when you'd rather not deal with the couple.

One thing we can't offer is to do it invisibly. A guest list with a household removed is a guest list the couple can see has changed, and their headcount changes with it. That's worth knowing before you ask, and it's better said here than discovered afterwards.

Signing in stores your email address, a display name (the part of your email before the @), the name of your account and when it was created. Sign-in is a link emailed to you — there is no password field anywhere in Wedlark, so there is no password for us to store or lose, and no sign-in through Google, Facebook or anyone else. That last point is deliberate: it's what keeps the list of companies below down to three.

Signing in also records your IP address and your browser's user agent — the short line of text your browser sends identifying itself and your operating system. Supabase, which runs sign-in, keeps them against the session and in its own sign-in log. Unlike the rate-limit rows further down, these aren't swept away by later traffic: they last as long as the session does, and the log entry lasts as long as the account. We'd rather say so here than let you read the rate-limit section and conclude that's the only place an IP address of yours exists.

What you then put in is yours: your names, the date, the RSVP deadline, your menu, and your guest list — the households you're inviting and the names of the people in them. None of it is visible to any other account. The database enforces that itself, on every read and write made on your behalf, rather than leaving it to the application to remember.

The guest list also comes with an obligation, and it's yours rather than ours. Those people gave you their food requirements because you asked. If one of them asks you to remove them, please do it — deleting a household takes its menu choices and dietary notes with it. If a guest comes to us instead, we'll act on it and let you know it happened.

You can delete individual households and menu items yourself. Deleting a whole wedding, or closing your account entirely, is done by asking — email hello@wedlark.com and it will be done. There's no button for it yet, and we'd rather say that than imply there is.

The form on the front page stores three things and the time you sent them: your email address, whether you're a couple, a planner or a venue, and — for a couple — your wedding date. The date is the field that earns its place: it tells us whether we can realistically be ready in time for you, and we'd rather know that before you're relying on us. Planners and venues leave it blank, because they don't have one date. And, as with the guest pages above, sending the form writes a row counting it against the IP address it came from — the same kind of rate-limit row, covered in full further down.

We use it to email you about early access to Wedlark, and for nothing else. It isn't a marketing list, it isn't sold, and it isn't shared. You get one confirmation email when you sign up so you know the form worked.

If the same address is submitted twice you get the same friendly answer both times and one record is kept. That's deliberate: it stops the form being used to find out whether a particular person has signed up.

Ask and we'll delete it — hello@wedlark.com. There is nothing to unsubscribe from beyond that.

Cookies. Only if you sign in, Wedlark sets cookies that keep you signed in — one or more, depending on how large the sign-in details are and whether you finished signing in or only started. They do nothing else. There is no analytics, no advertising and no tracking script on any page, including the page a guest replies on — the only thing any page loads from another company is the Cloudflare check described below. That is why you aren't asked to click through a cookie banner.

Fonts. The two typefaces are served from Wedlark's own domain rather than from Google's font servers, so opening a page doesn't tell Google you were here.

Spam checks. The sign-in page and the early-access form show a Cloudflare Turnstile check, so your browser exchanges enough with Cloudflare for it to tell a person from a script. That includes your IP address, along with signals about your browser and how it behaves — the check loads directly from Cloudflare, so it sees you the way any website you visit does. It is not on the guest reply page: a guest is never asked to prove they're human.

Rate limits. To stop someone guessing invitation codes or hammering the early-access form, requests are counted against the IP address they arrived from. Each row holds that IP address, which kind of request it was, a count and a time window — nothing about who you are, because at that point nothing about who you are is known.

Those rows are cleared as new requests come through rather than by a scheduled job: each fresh burst of traffic sweeps away anything more than about a day old. In practice that means they usually disappear within a day or so — but on a quiet stretch, with no traffic arriving to trigger the sweep, a row holding an IP address can sit there longer. There is no timer that would clear it in the meantime. We would rather write that down than describe a tidier system than the one we run.

Failure logs. When a request fails, the server writes a line recording which page or address was being asked for and what went wrong, so the fault can be found and fixed. It is a record of the failure, not a copy of what anyone submitted, and we strip the code out of a guest's invitation link before writing that line, because that code is the key to the household's answers. That covers the ordinary case. When the failure is a genuine crash or an outage somewhere upstream, though, the server writes a second line for the same request, and that one can still carry the full link, code included. That's a real gap, not a closed one — we know about it and are working on it, and we'd rather tell you that than claim a protection we haven't finished building.

No profiling. Nothing about you is scored, profiled or decided by an automated system. The only automatic judgement anywhere is the rate limit above, which counts requests and asks a very busy caller to wait a few minutes.

Wedlark is built and run from the UK, for UK weddings. The infrastructure underneath it belongs to the three companies above, and they don't all sit in one place.

Cloudflare's network is global by design: a page is served from whichever of their data centres is nearest to whoever asked for it, so the request passes through that one. Our Resend account runs in their eu-west-1 region.

For the database, we'd rather answer precisely than approximately: email hello@wedlark.com and we'll tell you exactly which region the Supabase project runs in. If you need that answer before you're willing to use Wedlark, that is an entirely reasonable thing to need, and asking costs you one email.

Under UK data protection law you can ask for a copy of the information held about you, ask for it to be corrected, ask for its erasure, ask for a copy in a form you can take elsewhere, and object to or ask us to restrict what's being done with it.

Everyone's route is hello@wedlark.com, and we'll answer within a month. If you're a guest, the guest section above is the practical version of the same thing: your link already gives you access and correction immediately, the couple can action erasure faster than we can, and we're there for when you don't want to involve them.

If you're unhappy with how it's handled, you can complain to the Information Commissioner's Office, the UK's data protection regulator, at ico.org.uk. We'd rather you told us first so we can put it right, but you are not obliged to.

Anything on this page — hello@wedlark.com. Wedlark is small enough that the person who wrote the code is the person who reads that inbox.

When this page changes, the date at the top changes with it. If the change is one that matters — a new company handling your data, a new kind of information collected, a retention period finally set — it will be said here plainly rather than edited in quietly.

Last updated 8 August 2026.