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 host dashboard, invitation pages, and door check-in tools. It applies to hosts, invited helpers, guests, and visitors.

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, phone number, email, business name if given, sign-in credentials, plan and credit records, and support messages.

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.

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: plan and credit history, amounts, currency, status, and the gateway's transaction identifiers. We do not store full card numbers. Card details are handled by the payment gateway on its own surface.

Network addresses, the device key, and the free invitation link

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 three 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. The fingerprint that counts openings of an invitation link, the fingerprint that tells one device from another, and the fingerprint used for rate limiting are computed with three different keys, so nobody holding one table can line it up against another.

We use the address for two purposes and no others. The first is the free invitation link. A host on the free tier gets one link, it carries a set number of opens, currently fifty, and then it stops. That cap is what keeps the free tier from replacing a paid send. It is counted on our server, and never from anything a browser says about itself. The second is 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.

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

Until the seventh of September 2026 one connection was one open, whoever was behind it. A household of forty people on one connection counted as one, which was more generous than a cap is meant to be. An open is now 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.

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 we set a cookie named azayemna_open holding a random number we generated on our server. Nothing is read off your device to make it, nothing about you is in it, and no script on the page can read it. 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 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.

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 the free link cap, 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.

The same kind of fingerprint is what we use to stop a flood. When one connection makes far more requests in a moment than any person does, we suspend it for a time. What we hold to do that 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 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.

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 passcode or password, hosting invitation pages, collecting replies, issuing entry passes, running door check-in, sending transactional messages such as passcodes and receipts, taking payment, and applying the limits that define the tier a host chose, including the free link cap 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. 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, a transactional email provider, and an error-monitoring service. Each processes data on our instructions or as an independent controller under its own terms, as applicable.
• 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. 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 the free link cap, 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 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 on a schedule after the send, while the record of the send itself stays.

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. 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.