Privacy policy

This Privacy Policy explains how Azayemna collects, uses, stores, shares, and protects personal data when you use our website at azayemna.com, the invitation pages we serve on invite.azayemna.com, the host dashboard, and the door check-in tools. It applies to hosts, door helpers, guests, and visitors.

Every page a guest opens is served on invite.azayemna.com: the invitation, its reply, pass and calendar pages, a shared link, and a premium invitation site. An older link that still names azayemna.com opens the same page there. Apart from invitations, that address serves only this policy and the cookie policy, and nothing on it links back to the main site.

Azayemna is a product of Delivvo Computer System Development, a sole establishment licensed in Abu Dhabi under Abu Dhabi Economic Licence (Freelance) number CN-6512437, and is owned and operated by Delivvo. For the data we control, that entity is the controller. This policy applies the UAE Personal Data Protection Law, Federal Decree-Law No. 45 of 2021 (PDPL), and article numbers below refer to it. The PDPL Executive Regulations required by Article 28 had still not been issued as of September 2026, so we apply the law as written and will follow the regulations, and any guidance from the UAE Data Office, once they are issued. Where we serve people in other regions, we aim to honor comparable rights.

This policy is published in Arabic and English. Arabic is the language the UAE courts work in, and Federal Law No. 15 of 2020 on Consumer Protection requires consumer documents to be in Arabic with other languages permitted alongside it, so if the two versions ever differ, the Arabic version prevails.

Our two roles

• When we collect and use data to create accounts, sign people in, run the product, bill hosts, and keep the service secure, we act as the controller of that data.
• When a host uploads guest details, sends invitations, and collects replies, we act as a processor on the host's behalf, and the host is the controller of that guest data. The host decides what guest data to collect and why. If you are a guest with a question about a specific event, contact the host who invited you first.

Personal data we collect

From a host account: name, email, the phone number given at sign up, business name if given, sign-in credentials, the orders you placed, how many of the account's free link opens have been used, the opens you bought for shared links and how many are left, and support messages. We use the phone number to reach you about your account and your orders, never to sign you in.

From guests, as uploaded or entered by a host or a guest: name, phone number or email, the side and group a host assigns, companion allowance, and the reply a guest gives, including any dietary note or answer to a host's question. A guest who receives a private link to a premium invitation site replies on that site, and the reply is held in exactly the same way as a reply to a card.

If our team starts an order for you at your request, we make your account from the email and name you gave us, confirmed and with no password, and send you a private link to finish the order; you can sign in later with the emailed code. We also save on that account the WhatsApp number you gave us, if it holds none yet, so we can reach you about the order. If you ask for an invoice in a company's name, we keep that name and its tax number on the order and on the invoice, as part of the tax record. We note when you first open the link and what you change on it, and tell our team, so we can follow the order with you; that note stays with the order.

If you ask us to make a design for you: the occasion, the date, the language and the kind of design you chose, what you wrote about it, and up to five reference files you attach (pictures, short clips or PDF documents). Files can be attached only from an account with a confirmed email, a full name and a phone number, and each account has fifteen megabytes of room for them across all its requests. The files sit in private storage that only our team can open, each time through a link that stops working after ten minutes, and we use them to make your design and for nothing else. Your request also opens a support conversation, held like any other.

If you add music of your own: the track itself, which is trimmed on your device before it reaches us, the name you give it, its length and its size. We also keep a record that you stated you may use it, and, if you offer it to our library, a record of that offer, each with its date and the wording you agreed to. Your tracks sit in private storage and are played only under your own invitations. A track you offered and we accepted is copied into the library without your name.

From a guest who claims an entry pass on a list link a host posted: the WhatsApp number they type, and their name and email if they give them. We send their pass to that number and hold it on the host's list exactly as we hold a number the host brought herself, and the host sees that number and name on her list. For each attempt we keep, for thirty days, a keyed hash of the connection and of the number and what came of it, to stop a machine emptying a list; we never keep the number or the network address itself in that record.

If a host links her own WhatsApp to bring her contacts in: the names of her groups and one-to-one chats, and the names and phone numbers of the people in the groups she opens, as her own WhatsApp shows them. We read no message, no chat history and no media. So that the link keeps working between visits, we also hold the linked device's keys and the names her phone has saved for those same people, encrypted, and her own number while she is asking WhatsApp for a code to type. The people in her groups are her contacts, and she carries the same responsibility for a lawful basis as for any guest list she brings. Ending the link is in her hands: unlinking removes the device from her WhatsApp and deletes all of it at once.

On a private link we sent you to finish an order, connecting WhatsApp always starts a new link from the phone that scans the code, even when your account already has one. That link belongs to the order link alone and is never shown in your account. It ends when you go to pay or close the page, and the groups and people it read are deleted then. Left open, it lapses two hours after you last used it, and what it read is deleted once the order link stops working.

Technical data about a request: the language you read the site in, timestamps for sign-ins and activity, and server and error logs. Every request that reaches us also arrives carrying the network address it was sent from, which is the internet's way of knowing where to send the answer. That address is an electronic identifier and a coarse indication of where a connection is, so Article 1 of the PDPL makes it personal data and we treat it as such. The next section says what we do with it.

Billing data: your orders, their amounts, currency and status, the invoices issued for them, and the gateway's transaction identifiers. We do not store full card numbers. Card details are handled by the payment gateway on its own page.

Network addresses, the device key, and shared invitation links

This is the one place where we take something from a request that you did not type in, so it gets a section of its own.

We never write a network address down. No table in Azayemna holds one in a form anybody could read, and the columns that were once built to hold one are now refused by the database itself.

What we hold instead is a keyed fingerprint. Before the address is used for anything, it goes through a one-way function together with a secret key that lives only in our server configuration. What comes out is a fixed string of characters. The same connection always produces the same string, which is all our counting needs, and the string cannot be turned back into the address it came from. Article 1 of the PDPL calls this pseudonymisation rather than anonymisation, because we still hold the key, so we treat the fingerprint as personal data and this policy covers it.

The key is scoped to its purpose. Each purpose below computes its fingerprints with a key of its own, and the fingerprint of a connection, the fingerprint of a device, and the fingerprint of a host's own device are each made in a separate scope. So nobody holding one table can line it up against another.

We use the address for these purposes and no others:

• Counting the opens of a shared invitation link, the purpose the rest of this section explains.
• Rate limiting: sign-in codes, password attempts, guest replies, door scanning and every other public endpoint are counted per connection so that one machine cannot flood them. When one connection makes far more requests in a moment than any person does, we suspend it for a time.
• Recording the answer a visitor who is not signed in gives to the cookie notice, against a fingerprint rather than against anything that identifies the visitor.
• Tying a password reset to the browser that asked for it, for the fifteen minutes the reset lasts.

The free opens belong to the account

A host on the free tier shares an invitation by link. Her account has fifty free opens for its whole life, spent by every link it shares, card links and premium site links together. After them she may buy opens in hundreds, which stay on the account in two balances, one for card links and one for site links. What we keep about that is the account's own running totals: how many free opens it has used, how many opens of each kind it bought and spent, and when a kind last ran out. They are plain numbers held against the account, and they are how the product shows a host what she has left.

When an account gives a phone number, we compare a keyed fingerprint of that number with the fingerprints of accounts made earlier. If an earlier account gave the same number, the newer account starts from the free opens the earlier one had used, so the free opens cannot be restarted by opening another account. The comparison uses the fingerprint only. The number itself is stored sealed, as every phone number we hold is. It works one way only: nothing the newer account does changes the earlier account's figures, and the newer account is never told which account it was. The comparison serves a term of the free tier, which is Article 4(9) of the PDPL.

How an open is counted, and the device key it needs

An open is worked out from the devices at a connection. The first five devices at one connection count as one open between them, and every two devices after that count as one more. So five devices is one open, seven is two, nine is three, and eleven is four. No single connection ever contributes more than forty devices, because past that it is not a household. For an IPv6 connection we use the network part of the address, the /64 that one home or one phone is given, so every phone in a home on IPv6 is still counted as one location.

Telling two devices at one connection apart is something a network address cannot do, since every phone in a house shares one. So when you open an invitation link, or a host opens her own workspace, we set a cookie named azayemna_open holding a random number we generated on our server, with our signature beside it so that a number we did not write is not accepted. Nothing is read off your device to make it, nothing about you is in it, and no script on the page can read it. In production the cookie is set for azayemna.com and its subdomains, so a device a host has used on azayemna.com is the same device when she opens her own link on invite.azayemna.com. What reaches our database is a keyed fingerprint of that random number rather than the number itself, so a stored value cannot be matched back to a browser and cannot be lined up against any other record we hold. The cookie lasts twelve months, which is exactly how long the counter row lasts, and the two go at the same time.

A host's own opens are never counted. An open is left out when the request carries the signed-in session of the account that owns the link, when it comes from the connection the link was made from, or when it comes from a device the host has used while signed in. For the first, we compare the session with the link's owner. For the second, we keep a keyed fingerprint of the connection the host made the link from, on the invitation itself. For the third, we keep a list of the host's own devices, each as a keyed fingerprint of the random number in her device cookie, made in a scope of its own. That list is used for this one purpose, and because of its separate scope it cannot be joined to the record of anybody else's opens. The sign-in cookies belong to azayemna.com alone and are never sent to invite.azayemna.com, so when a host opens her own link there, the second and third are what recognise her.

A browser that keeps the cookie is one device however often it comes back. A browser that clears its cookies, or a second browser on the same phone, reads to us as a new device, and spends the host's allowance faster. We would rather say that plainly than pretend otherwise: the only way to do better would be to read properties off your device and build a fingerprint, and we will not do that. What we do instead is put a ceiling on it. One connection is never counted for more than forty devices, so no connection can spend a whole allowance, and there are limits on how often one connection and one link can be opened in a minute.

When an account has no free opens and no opens left of a link's kind, its links of that kind stop opening for new devices. A device that has already been counted on a link can still open it. That decision is made on our server, from the same fingerprints.

The count is a cap on how far a link travels rather than a headcount, and we never present it as one. One device can have several people looking at it. One phone moving from home wifi to a mobile network is counted in two places. So the figure a host sees is how far the link has gone, and nothing in Azayemna calls it a number of guests or a number of people.

We do not look up where you are. We do not resolve the address to a country, a city, a map position, or an internet provider, and we do not buy or hold any service that would. The address tells us that one connection is different from another, and that is the whole of what we take from it.

Both fingerprints behind a counted open, the one standing for the connection and the one standing for the device, are deleted twelve months after that device last opened the link. A fingerprint held for rate limiting is deleted after thirty days. Scheduled jobs do the deleting, so the periods are real rather than intended.

When we suspend a flooding connection, what we hold is the keyed fingerprint, a reason, the time it began, and the time it lifts, and never a network address or anything read off your device. The suspension lifts itself after a set time, and an operator can lift it sooner.

Neither fingerprint behind a counted open is ever attached to the person it came from. Nothing links either one to a name, an account, a guest, a reply, or a message. The table holding them carries the two fingerprints, which invitation was being opened, how many times that device came back, and two timestamps, and nothing else. The invitation it names belongs to the host who made the link, not to the person who opened it, so knowing which link was opened tells nobody who opened it. The account's running totals are worked out from those rows through the link's owner, and no row names a guest.

We also count how many times each page was opened, as a bare total. What we keep is the date, the page, the language and a number, and nothing about the person: no network address, no fingerprint, no device key, no cookie value and no account, so the count can say a page was opened and can never say by whom. A page opened on a private invitation link is counted as that kind of link and never as the link itself, so no token is ever written down. To decide whether an open is counted at all, the server looks at the name your browser gives itself, so that search engines and link previews are left out, and it keeps nothing of it. Our own staff's browsers are left out as well.

How we use personal data, and our legal bases

Article 4 of the PDPL prohibits processing personal data without consent and then lists the cases that are excluded from that prohibition. There is no general legitimate interest basis in UAE law, so we do not claim one. We process personal data on these bases:

• Performance of a contract, Article 4(9). Creating and securing accounts, signing people in by one-time code or password, hosting invitation pages and premium invitation sites, collecting replies, issuing entry passes, running door check-in, sending transactional messages such as sign-in codes, receipts, invoices, and the emails about a host's link opens, taking payment, and applying the limits that define what a host chose. That includes the free opens on a shared link, the credit a host buys for it, the comparison of phone fingerprints between accounts, and leaving a host's own opens out of the count, all described above.
• A legal obligation on us, Article 4(10). Keeping the accounting and tax records the law requires, and answering a lawful request from an authority.
• Claiming or defending rights, Article 4(3). Keeping what we need if a specific misuse of the service turns into a claim.
• Your consent, Articles 4 and 6. Anything we ask you for and you agree to, including marketing where you have opted in and the optional settings in the cookie notice. Consent can be withdrawn at any time, easily, and withdrawing it does not undo processing that was lawful before.

We also use personal data to keep the service secure and to improve its quality and reliability, and where that is not part of running the service you asked for, we do it on the basis above that applies rather than as a purpose of its own.

We do not sell personal data, and we do not use the guest data a host stores to build advertising profiles. Marketing messages, where we send them, carry a way to stop them and are only sent with consent, whichever channel they arrive on. Transactional messages needed to run an account are not marketing and are not subject to that.

Consent, and messaging your guests

Where we rely on consent, we ask for it in a clear and simple way, as Article 6 requires, and you can withdraw it at any time through an easy method, without affecting processing already carried out. For guest data a host uploads, the host is responsible for the lawful basis to contact those guests. The UAE rules on unsolicited electronic communications, set by the TDRA, require documented prior consent for marketing messages and a working opt-out, and honoring opt-out requests promptly. A host who runs a managed send confirms they hold that consent.

Sensitive guest lists

Some events, especially women-only gatherings, carry guest lists that are sensitive by nature. We treat them accordingly. A door scanner assigned to that side sees only a guest's name and companion count on a successful scan, and never the full list or another event. This is enforced in our systems, not left to trust.

How we share personal data

We share personal data only where needed to run the service, comply with the law, or protect rights and safety, with these kinds of recipients:

• Service providers that host the platform, deliver messages, and process payments. Our current set includes Supabase for database, authentication, and storage, Vercel for hosting and delivery, a WhatsApp Business Platform provider and Meta together for managed WhatsApp sends (a guest's number and invitation pass through both to reach WhatsApp), one or more payment gateways, and a transactional email provider. Each processes data on our instructions or as an independent controller under its own terms, as applicable.
• Two providers that a browser reaches by itself when it opens a premium invitation site. The site's typefaces are served by Google Fonts, and the venue may be shown on a map from OpenStreetMap or Google Maps. To fetch either one the browser contacts that provider directly, so the provider sees the network address the request came from, as any website does. We send them nothing about you: no name, no number and no reply. Each handles what it receives under its own policy.
• Professional advisers and authorities where the law requires it.
• A successor entity in a sale or reorganization, under confidentiality.

We do not sell personal data and do not share it for cross-context behavioral advertising.

International transfers

Our providers operate in several countries, so personal data may be processed outside the UAE, including in the regions where those providers run. Articles 22 and 23 of the PDPL govern that. Article 22 allows a transfer to a country the UAE Data Office has recognised as having adequate protection. No such list has been published, so we do not rely on one. We rely instead on Article 23(1)(a), a written contract with each provider that binds it to the measures and requirements the PDPL sets out, and on Article 23(1)(d), where the transfer is necessary to perform the contract we have with you. We will move to Article 22 for any destination once the Data Office recognises it.

Data retention

We keep personal data for as long as its purpose needs and no longer, which is what Article 5(7) requires. As a rule, account and event data is kept while the account is active, and nothing a host is still waiting to use is removed on a timer, however far away her event is. When a host deletes an event or an account, we remove the associated personal data from active systems on a defined schedule, unless the law requires keeping a record longer. Accounting and tax records are the main thing the law requires us to keep. An invoice keeps every fact it was issued with, including the name and the email address it was issued to, because a commercial record that has been emptied is not a record.

Specific periods worth naming:

• The two keyed fingerprints behind a counted open, one for the connection and one for the device: twelve months after that device last opened the link. The azayemna_open cookie expires on the same twelve months.
• The account's running totals of free opens used and opens bought and spent, the fingerprints of the host's own devices, and the fingerprint of the connection she made a link from: kept while the account and the invitation exist, and deleted with them.
• The keyed fingerprint behind rate limiting, and a fingerprint held to suspend a flooding connection: thirty days for the rate limit fingerprint, and a suspension for its own set time.
• A support conversation: about thirty days after it has ended or been closed with no further activity, we remove the messages and keep only a small record that the request existed. The link that opened the conversation stops working at the same moment.
• The phone numbers we hold for a completed send: stripped from the send record thirty days after the send, while the record of the send itself stays.
• The reference files attached to a custom design request: deleted ninety days after the request is marked done or declined, and at once when the account is deleted. A file uploaded but never sent with a request is deleted a day later. The request itself stays in the account until the account is deleted.
• Your own tracks, pictures and clips: kept while your account exists, and deleted when you delete them or delete your account, files included. A track you gave to our library, once accepted, is a separate copy that stays there without your name. When you take it back it leaves the shelf, so nobody new can choose it, and it goes on playing only in invitations already made with it, until we remove it. The record that you stated your right to a track, or offered one, is kept as proof that it was asked.
• A linked WhatsApp: the device's encrypted keys and the saved names are deleted seven days after the host last used the link, or at once when she unlinks, and the keys of an attempt that never linked are deleted within an hour. The groups and people already read stay in her account until she unlinks.
• A WhatsApp linked on a private order link: ended, and what it read deleted, when you pay or close the page; otherwise it lapses two hours after its last use, what it read is deleted once the order link stops working, and its keys within an hour of it ending.

Retention is enforced by scheduled jobs rather than by intention.

Security

We use administrative, technical, and organizational measures to protect personal data. Article 20(1)(a) of the PDPL names encryption and pseudonymisation as measures a controller has to take, and both are central to how Azayemna is built. Phone numbers are encrypted before they are written and are never stored as readable text. Network addresses are never stored at all, and neither is the random number in the device cookie: both are held only as the keyed fingerprints described above. On top of that we use encryption in transit and at rest, row-level access controls in the database, rate limiting, a firewall, audit logging, and a strict allowlist for uploaded file types. The full policy is in our security document. No system is perfectly secure, so please protect your own sign-in method as well.

Personal data breach

If a personal data breach occurs, we act to contain it, and, under Article 9 of the PDPL, we notify the UAE Data Office and the affected data subjects where the law requires. The PDPL leaves the deadline to the Executive Regulations, which have not been issued, so no fixed period is in force. We notify without undue delay after becoming aware of a breach.

Your rights

Under the PDPL you may ask us to:

• tell you what we hold and why, and how long we keep it, under Article 13;
• give you a copy in a portable form, or pass it to another controller, under Article 14;
• correct what is wrong, or delete what we no longer need, under Article 15;
• restrict processing while a question about it is open, under Article 16;
• stop processing for direct marketing, for statistical surveys, or where the processing breaks Article 5, under Article 17;
• have a person look again at a decision made by automated processing, under Article 18.

Article 19 requires us to give you a clear way to ask, and this is it: use the Support area on azayemna.com. A host can also export their own account data from settings. We may ask for information to verify your identity, and where we act only as a processor for a host, we may direct your request to that host.

One thing deletion does not reach, and you should know it before you ask. Deleting your account removes the account and everything personal inside it, including any opens left on it. It does not remove an invoice. An invoice is the commercial and tax record of a sale that really happened, the law requires us to keep it, and it keeps every fact it was issued with, including the name and email address it was issued to. That is Article 4(10) of the PDPL, a legal obligation, and it is the one place where asking to be deleted does not delete a record about you.

Two honest limits. Article 15(3) and Article 13(3) let us refuse a request in defined cases, such as one that would expose another person's data or damage the security of the service, and we will tell you if we rely on that. And a keyed fingerprint cannot be looked up by name, because it is not attached to a name, so a request to see or delete yours is one we cannot answer without you telling us the connection you used, which we would rather not ask for.

Complaints

If you think we have handled your personal data wrongly, tell us first in the Support area on azayemna.com and we will look into it. Article 24 of the PDPL also gives you the right to complain to the UAE Data Office, the federal data protection authority established under Federal Decree-Law No. 44 of 2021. Its details are published at u.ae.

Cookies

We use a small set of cookies, mostly to sign you in. Details are in the Cookie Policy.

Children

Azayemna is for adults planning and attending events. The age of legal majority in the UAE is 18, and we do not knowingly collect data from anyone under 18. If you believe a minor has given us data, contact us and we will look into it.

Changes

We may update this policy. If a change is material, we will revise the date above and may notify you in the product or by email.

Contact

Privacy questions and requests go to the Support area on azayemna.com. The controller is Delivvo Computer System Development, Abu Dhabi Economic Licence (Freelance) CN-6512437.