Legal
Privacy Policy
OTPRelay delivers one-time passcodes by SMS across the Gulf. This policy explains what data we handle, why, and the two roles we play: controller for our own website, and processor acting on your business's instructions when you call our API.
Last updated: 21 June 2026
The two roles: controller and processor
OTPRelay ("we", "us", "our") delivers one-time passcodes by SMS. Depending on the data, we act in one of two roles, and your rights and our duties differ in each.
Controller - our website
Processor - our API
If you received an OTP while using someone else's app or website, that business - not OTPRelay - is the controller of your data. To exercise controller-level rights over it, such as access or deletion, contact that business; we support them in responding. See Your rights.
Who we are and how to reach us
OTPRelay is a one-time passcode delivery service for the Gulf. Our website is https://otprelay.io and our API base is https://api.otprelay.io/v1. We are in early access: Saudi Arabia is live today, with the rest of the GCC and then worldwide following demand.
OTPRelay sends OTP codes by SMS in two co-equal modes. In Send mode you generate the code and we deliver it in one call - see Send a code. In Verify mode we generate the code, send it, and check it for you across two calls - see Verify a code. Which mode you use changes what data we handle.
For any privacy question, request, or complaint, email privacy@otprelay.io. If you need a formal or postal point of contact, ask by email and we will provide one.
What we collect as controller (the website)
When you visit otprelay.io or join our early-access waitlist, we collect the following, and no more than we need:
- Waitlist and early-access form. Your email address (required), your chosen locale (en or ar), an optional free-text answer to "what are you building?", and created and updated timestamps. We store this in AWS DynamoDB and use it only to contact you about early access and product updates. Lawful basis: your consent, and pre-contractual steps taken at your request.
- Analytics. We use Google Analytics (measurement ID G-5SG404DS73), which sets cookies and collects usage data such as the pages you view, an approximate location derived from your IP address, and your device and browser. Lawful basis: your consent, or our legitimate interest in improving the site.
- Language cookie. A NEXT_LOCALE cookie remembers your language choice for up to one year so the language switcher works on your next visit. It is strictly necessary for that switcher, so we disclose it here but do not gate it behind consent.
- Server and request logs. Standard logs such as IP address, user agent, and timestamps, kept so we can run the site securely and reliably.
We do not ask for, and you should not send us, sensitive personal data through the waitlist form.
What we process as processor (the API)
When your business calls the OTPRelay API, we process the data you send on your behalf and on your instructions. You stay the controller; we are the processor:
- End-user phone numbers in E.164 format (for example +966512345678) - the "to" of each request.
- One-time passcodes. In Verify mode we generate, send, and check the code, so it is processed and held for the lifetime of that verification. In Send mode we neither store nor check the code - you compare it yourself.
- Message content. The SMS body sent from the shared, pre-cleared OTPRelay sender, built from the fixed template configured on your account.
- Metadata. Up to 10 key/value pairs you attach on send (for example a user_id), echoed back on the object and on webhook events. We ask you not to put sensitive personal data in metadata.
- End-user IP address and risk signals. Optionally passed by you (a planned device_ip-style field) and used by Fraud Guard to score each send and block SMS pumping and abuse.
- Delivery data. Per-route delivery receipts and status (such as sent, delivered, undelivered, approved, closed), timestamps, and the attempts made across routes and operators during multi-route failover - see Delivery and failover.
- Your credentials and config. API keys (live and test, for example att_...), webhook signing secrets (for example whsec_...), and the webhook_url you nominate for Webhooks.
Send mode holds no code
Your SMS and mobile data
Phone numbers are personal data and the codes we carry are sensitive. We treat them accordingly:
- We do not sell or rent phone numbers or mobile data. We never sell, rent, or share phone numbers, mobile information, or message content with any third party for that third party's own marketing or promotional purposes.
- Numbers go only where delivery requires. The only outside parties that ever receive a phone number are the operators and routing partners needed to deliver that specific message, with multi-route failover across them. They handle it to carry the message, not to market to anyone.
- OTP delivery is transactional, not marketing. We send a code because a business asked us to verify one of its users. We do not use phone numbers or delivery data to build advertising or marketing profiles, and we do not run our own marketing over your end users.
- Standard carrier rates may apply. Message and data rates from the recipient's own mobile carrier may apply to the SMS they receive.
Consent to receive a message, and any choice to stop a business's messages, sits with the business (the controller) that asked us to send it, not with OTPRelay. If you no longer want messages tied to a particular app or service, contact that business. See Your rights for how requests are handled.
Why we are allowed to use your data (lawful bases)
We only process personal data where we have a lawful basis to do so.
As controller (the website):
- Waitlist and early access: your consent, together with pre-contractual steps taken at your request so we can contact you about access and product updates. You can withdraw consent at any time.
- Analytics: your consent, or our legitimate interest in understanding and improving the site, depending on your region and choices.
- Functional NEXT_LOCALE cookie: strictly necessary to make the language switcher work, so it is disclosed but not consent-gated.
- Server and request logs: our legitimate interest in keeping the site secure and operating reliably, and meeting our legal duties.
As processor (the API): we do not pick the lawful basis for this data - the customer (the controller) does. Our basis for acting is the customer's documented instructions under our data processing agreement. The customer is responsible for having a valid lawful basis, such as their own legitimate interest in securing accounts or performing a contract with the end user, for the OTP delivery they ask us to carry out.
How we use the data
We use data for the specific purposes it was collected for, and not for unrelated ones.
- To run the early-access program. We use your waitlist details to contact you about early access and product updates, and for nothing else.
- To deliver and verify OTPs. As processor, we use phone numbers, codes (in Verify mode), message content, and config to deliver each message and, in Verify mode, to check the code.
- To keep delivery reliable. We use delivery data and the attempts made across routes and operators to confirm delivery, debug failures, and route around problems with multi-route failover.
- To prevent fraud and abuse. Fraud Guard scores each send, using optional risk signals you pass, to block SMS pumping and abuse and protect both your budget and end users.
- To secure and operate the service. We use logs and access controls to keep the website and service safe and working, and to meet legal and audit duties.
Sub-processors and sharing
We do not sell personal data. We share it only with the categories of providers below, or where the law requires it.
- Cloud hosting and storage. Amazon Web Services (AWS), including DynamoDB and compute, hosts the website data and the service.
- Website analytics. Google (Google Analytics), for the website only and never for service or OTP data.
- Downstream delivery. Telecom operators and SMS routing partners that carry each message to the destination network, with multi-route failover across them so codes still land when one route struggles.
These providers act as our sub-processors for the data they handle, under appropriate contractual protections. We do not share waitlist data with the OTP delivery chain, and we do not feed service or OTP traffic into our website analytics. We may also disclose data where we are required to by applicable law, regulation, or a binding request from a competent authority. We keep these provider categories current and will update this policy if we make a material change to the providers we rely on.
Cross-border transfers
Because we run on AWS and work with the sub-processors above, your data may be processed or stored in regions and by providers that can be outside your own country.
Saudi Arabia (PDPL/SDAIA) and the UAE (PDPL) both place conditions on transferring personal data outside the country. Where a transfer happens, we rely on the safeguards those laws require, including appropriate safeguards and contractual protections with the providers who receive the data, so that your data keeps a comparable level of protection wherever it is handled. As processor, any transfer of customer data also follows the customer's instructions and our data processing agreement. You can read more about how we approach regional rules in GCC compliance.
How long we keep data
We keep personal data only as long as we need it. The periods below are principles and indications, not contractual commitments or a fixed SLA.
- Waitlist data. Kept until early access concludes or you ask us to delete it.
- Service and OTP records and delivery metadata (as processor). Kept for the limited period needed to deliver, verify, secure the service, and meet legal and audit duties, and ultimately in line with the customer agreement and the customer's instructions.
- Send-mode codes. Not retained, because they are never stored.
- Analytics. Kept according to our Google Analytics retention settings.
How we protect data
We describe only the controls we actually run:
- Encryption in transit. The API is HTTPS-only, traffic uses TLS, and any webhook_url you nominate must be HTTPS too.
- Authentication. Requests use bearer API-key authentication, with separate live and test keys.
- Signed webhooks. Webhook payloads are HMAC-signed with a per-account signing secret so you can confirm they came from us. The exact signature scheme is still being finalized, so we do not describe it in detail here; see Webhooks for current guidance.
- Encryption at rest. Data at rest is encrypted via AWS.
- Access controls. We apply access controls and least-privilege so people and systems only reach the data they need.
No certifications claimed
Security incidents
If a personal-data breach occurs that is likely to affect you:
- As controller (your website and waitlist data), we will notify the competent authority - in Saudi Arabia that is SDAIA - and the individuals affected, as required by the applicable law and without undue delay.
- As processor (the data we handle on a customer's behalf), we notify the affected customer (the controller) promptly so they can meet their own notification duties under our data processing agreement, and we support their response.
The exact steps and timing follow the law that applies and the facts of the incident, so we do not commit to a fixed deadline here.
Your rights
You have rights over your personal data. Which law applies depends on where you are, but the practical set is similar across the region:
- Saudi Arabia (PDPL). The right to be informed, to access your data, to request correction, and to request destruction of your data. Complaints can go to SDAIA, the Saudi Data and Artificial Intelligence Authority.
- UAE (PDPL, Federal Decree-Law No. 45 of 2021). Comparable rights of access, correction, erasure, restriction of processing, portability, and objection.
- A GDPR-style baseline for everyone. Access, rectification, erasure, restriction, objection, portability, and the right to withdraw consent at any time.
Rights over data we hold as processor route through the customer
For data we hold as controller (your waitlist sign-up and website data), contact us directly at privacy@otprelay.io and we will action your request. We respond to rights requests without undue delay and within the time the applicable law allows, and we do not charge for them in normal cases. Withdrawing consent does not affect processing we already carried out lawfully before you withdrew it.
Children
OTPRelay is a business-to-business tool and is not directed to children. When we deliver an OTP, it is because a business asked us to verify one of its end users, not because anyone signs up with us directly. We have no direct relationship with that end user, do not target children, and do not knowingly collect data from children through our website. Any age limits for a customer's app are the customer's responsibility as the controller.
Changes to this policy
As the product and the law evolve, this policy will change. When it does, we post the new version here and update the "last updated" date at the top. For material changes, we give you clearer notice rather than rely on the date alone - for example by email to waitlist members or a notice on the site.
Governing law
This policy is governed by the laws of the Kingdom of Saudi Arabia, our first live market, alongside the regional data-protection rights described above. This does not take away any protection you have under the data protection law of your own country.
Contact us
Questions, requests, or complaints about this policy and your data go to our privacy team at privacy@otprelay.io. If you think we have mishandled your data, please contact us first so we can put it right; you also have the right to complain to your data protection authority, which in Saudi Arabia is SDAIA. If you need a formal or postal point of contact, ask by email and we will provide one.
Questions, requests, or complaints about this policy? Email our privacy team at privacy@otprelay.io.