ovbq Privacy Policy

1. Who is responsible for your information

Othex Corp, a Florida corporation, runs ovbq.com and decides how information is used there. In privacy law terms, Othex is the "controller" or "business".

Mailing address: 5645 Coral Ridge Drive STE 137, Coral Springs, FL 33076, United States.
Privacy email: privacy@ovbq.com

For answers to forms on pages we host, the account holder is the controller or business and Othex is its processor or service provider (section 19).

Back to contents

2. Who this policy covers

Four kinds of people interact with ovbq, and we collect different things from each:

• Account holders and invitees: people who sign in, make codes, receive a Team invitation or use separately authorized shared access (section 3).
• People who scan a code: anyone who scans an ovbq QR code or opens an ovbq short link (section 4).
• Visitors and reporters: people who read our pages, use the free generator, or send an abuse report (section 5).
• People who answer a form: anyone who sends answers to a form on a page we host for an account holder (section 19).

If you only scan a code, section 4 and section 17 are the parts written for you. If you answered a form, section 19 describes how we handle your answers. Opening the code can also involve the scan processing described in section 4.

Back to contents

3. What we collect from account holders

Your email address. It is your sign-in and the only thing we need to create an account. We also record when the account was created and when you last signed in.

Sign-in links. When you ask to sign in, we make a one-time link and email it to you. We store only a one-way hash of the link's secret, never the secret itself. The link expires after 15 minutes and is used once. If you were starting a new code when you were asked to sign in, the link also carries that code's web address and error-correction level, so the form can be filled in again once you are signed in; we do not store it with the link, and no code is made from it until you choose to make it. If, once you are signed in, more than one code is still waiting to be made (for example because your plan has no room for them), we list them on a page whose own web address carries their web addresses and error-correction levels. That address is signed so it works only for your account, and only for 24 hours; we do not store the list anywhere else, and nothing on it is made until you choose. Like any web address you open, it can appear in your browser's history and in our hosting provider's standard server access logs (section 4).

Your codes. For each code: the name you give it (kept in your account rather than shown as the public page name), the destination link, the colors and error-correction setting you chose, the logo if you add one (one of our icons, or your image redrawn from its pixels, so none of the file's other data, such as camera or location details, is kept), when it was created and last changed, whether it is paused, and running totals of scans. When you delete a code we keep only the retired short code and its dates (created and deleted), so it can never be reused by someone else; its logo is deleted at once, and its name, destination and settings are blanked within 30 days, and at once when you delete your account.

For the management features you use, we keep your label names and which codes use them, and any start and end dates, their resolved times and the time zone you choose. If you opt into a custom outside-date notice, we keep its public message and any contact or back link you supply. That message and link can be seen by anyone opening the code outside its dates; your private code name and labels are not displayed there. Removing a label removes its memberships, not its codes.

If you set a password on a code, we keep a salted, slow-to-guess hash of it, not the password. We cannot read it back.

If you set rules on a website-link code, we keep the rules you write: the conditions, the destinations and the time zone.

The code list puts your search and filter choices in its address so Back and bookmarks work. Those choices can remain in browser history or a bookmark, and the request address may appear in our hosting provider's standard access logs. The address does not give another person permission to read your account. Do not put a password in search or filters.

What a code opens. A code opens a web page, or on Pro and Business it can start a phone call, a text message or an email instead, or open a page we host for you: a text page, a Wi-Fi info page, a contact card page, an app download page, a menu page, a link-in-bio page, a coupon page, a form page, or a file you upload (a PDF, JPEG or PNG). For those we keep what you type for it: the phone number, or the email address, and any subject or message you fill in for the people who scan it; the text of a text page; the name of your place, the network name and password, and any note on a Wi-Fi info page; the names, phone numbers, email, website, address and social links on a contact card; the app's name, description and store links; the text of a menu page (section names, item names, descriptions, prices and dietary tags, hours, time zone and language); the name, short line, and the labels and addresses of the buttons and social links on a link-in-bio page; the business name, offer, code text, dates and conditions on a coupon page; and any file you upload. They see it when they scan, since that is what the code is for, and a contact card's "Add to contacts" gives them a copy as a contact file. A picture you upload is redrawn from its pixels, so none of the file's other data, such as camera or location details, is kept. A PDF is shown as you uploaded it, so details inside it, such as the author's name, are shown too. A Wi-Fi password is kept so the page can show it; it never goes into a link, the printed code or our logs. Changes are made through your account or the separate edit access you authorize as described below. When you delete the code, what you typed and any file you uploaded are deleted at once, and so is the call, text or email address made from it (its destination). If your plan no longer includes these codes, they are paused and what you typed is kept, so they come back as they were if you subscribe again.

Forms. We keep a form's business name, title, intro, questions and settings, and its privacy-policy link if you add one. The form page shows the business name, title, intro, questions and any privacy-policy link; email and answer-keep-time settings stay in your account. Answers are handled as section 19 describes. Deleting a form's code also deletes its questions, settings and stored answers from our database at once. A paid plan ending does not delete stored answers or reset their keep time.

Event pages. For an editable event code, we keep its title, description, dates and times, all-day choice, chosen time zone where applicable, resolved times, place, address, online and details links, and link label. The event page and calendar file show the details you choose to publish. We do not send invitations or provide an attendee-list tool. People who open or download the calendar entry can keep their own copy; deleting or changing it here does not recall their copies. Fixed event invitations follow the generator rule in section 5.

Contact-card photos. We keep a resized PNG copy of a photo you add to a contact card, redrawn from its pixels. We discard the original image bytes and do not carry camera or location metadata into the stored copy. The stored file has a generic name and file details such as size and dimensions. It is used to show the photo on the hosted card, not for face recognition or identity verification. A password-protected card shows initials instead, and the downloadable contact file does not contain the photo. The photo's removal, retention and any legal hold follow the hosted-file rules in section 8.

Saved looks. We keep the private name you give a look, its colors, error-correction and appearance settings, logo choice, an independent copy of an uploaded logo if used, its size, and creation/change references and dates. The logo copy is the image already redrawn for the code, not the original upload with its metadata. A look can outlive the code it was saved from. Applying a look copies its appearance settings and any logo to the code you choose. Deleting the look does not remove those copies.

Code shape. If you choose a round appearance, we keep that choice with the code's other appearance settings.

Payment-link codes. We keep the recipient label, the HTTPS payment link, the choice of scan behavior and any optional purpose text for a confirmation page. Saving a direct-link choice removes purpose text. For each code, its owner chooses a confirmation page or a direct link. A direct link is available only for supported PayPal, Venmo, Cash App and Stripe links; links to other sites always show the confirmation page. On the confirmation page, the recipient label and any purpose text appear before the visitor opens the external payment link. With a direct link, the external page opens without that confirmation page; the recipient label stays saved with the code. A payment link can itself contain a recipient identifier, amount or note supplied by its owner; these remain part of the saved link. We do not collect the payer's card or bank details, process the payment, or receive its outcome. These code details are separate from the Stripe references for your ovbq subscription.

Weekly scan email. We keep your on/off choice, when it last changed, and references that validate changes and the unsubscribe link. We send the summary only if you turn it on. For an attempted summary we keep a minimal receipt: your account reference, the week's start date, recorded scan total, preference reference, attempt state and dates. The receipt does not keep the email body or recipient address; the mail service still handles the address and message as described in section 9. Retention is in section 8.

Picture galleries. For a saved gallery we keep its title, intro, back link, photo order, descriptions, captions and decorative-image choices, plus the references and file details needed to serve its display images and thumbnails. The page shows the content you choose to publish. Images are redrawn from their pixels; the uploaded file's camera or location metadata is not carried into the stored copies, and we do not retain the original upload or its filename as part of the gallery. A display image and thumbnail are separate stored copies and both use file storage. For an unsaved draft, we can temporarily keep those normalized copies with account, draft, code and row references and an expiry so only the signed-in owner can preview or use them. Those pending copies also use file storage until removed or saved. An unsuccessful save does not make the draft public. Retention is in section 8.

Video and audio pages. We keep the page title, optional description, any return link, supported outside-recording links, the transcript and the language chosen for it. For uploaded content, we keep the recording and its type, any captions and their language, any poster image, and the file references and details needed to store and serve them. We also keep any saved declaration that a video has no speech or important sounds, and any saved review and version references that associate the transcript, captions and poster with this page's recordings. The page shows the content you choose to publish to people allowed to open the code.

Video and audio recordings are not redrawn like the pictures described above. We do not strip their embedded details, which can include names, artwork or location information. People receiving a recording may be able to read those details. Remove unwanted private information before upload. A separately supplied poster is processed as an image, not extracted automatically from the recording. Captions, transcripts and descriptions are supplied by the owner, not generated by us. They can contain personal information too.

A link to an outside recording is saved as a link; we do not automatically retrieve or keep that service's recording, thumbnail or other preview. If the page also has an uploaded file, that file is a separate hosted copy. All stored recordings and their captions, transcripts and poster images use the account's existing file storage. Retention and deletion are in section 8.

Business pages. We keep the public business name, about text, chosen physical-address or online-service mode and its details, contact information, action choices and links you save. If you supply hours, we keep the weekly day and time settings and time zone; the displayed status is calculated from them, not from a check that the business is open. Missing hours are treated as unknown. This page information is public to people allowed to open the code; your private code name is not displayed. A booking action opens the chosen outside service, which handles any booking rather than sending a booking result to ovbq.

Page language. We keep the page language you choose and a version reference for changes. We use that setting to select reviewed system labels and messages, and keep the saved setting if the system must fall back to English. We do not select it by profiling a visitor's browser or location, and this feature does not translate your content or change the account interface. Existing menu-language settings are retained.

Fixed product barcode links. The product-link maker does not add a product catalog or GTIN registration to your account. It processes the URI and identifiers under the free generator's request-only rule, with the product-preview detail in section 5. The printed or downloaded code itself contains those values.

Team invitations and membership. We keep the owning-account reference, invited email, role, selected-code grants, separate scan/answer/export permissions, invitation verifier, version and creation/expiry times. An accepted membership keeps owner/member references, role, grants, version and creation time; the member's email comes from their own account. The owner sees its invitations, members' email addresses and permissions. An intended invitee who checks a valid invitation while signed in with the invited email address sees the owner's account email, the names and types of only the codes selected for that invitation, the proposed role and the separate scan, answer-viewing and answer-export permissions before choosing whether to accept. Accepted members see the owner's account email with their selected code context, not the owner's roster. Invitation review does not disclose destinations, hosted content, scan statistics or form answers. There is no separate membership-history table. Invitations are sent manually by the owner. We store a hash of the private invitation token, not the token itself; its URL fragment is not sent in the opening GET. Pasting it into the acceptance form sends it for checking. We do not keep the raw value in a session. Your own account stays separate from the owner's.

Bulk CSV records. The check processes the submitted UTF-8 columns: mode, type, name, destination and the editor-fields JSON. We keep normalized valid rows and fixed payloads, validation errors with source-record references, a file-content hash and an owner-bound receipt for the preview. Invalid rows' raw input and the original filename are not saved. On successful confirmation, normalized preview fields are discarded; the result keeps totals, source-record identities, names, fixed payloads or created-code references. Those values may contain personal information or, for a supported Wi-Fi code, network credentials. Created codes follow the ordinary code rules; the temporary batch has the separate retention in section 8.

API access. We keep a key's private label, owner and key references, allowed scopes, verifier, version, issue/last-use/revocation times, minute request counters and limited creation-request receipts. The full bearer value is shown once and is not stored as a recoverable API key. A creation receipt keeps the request key, a hash of the exact body, a limited result reference and expiry, not a copy of that request body or the raw bearer key. The API can disclose private code names, destinations and owner-authored content to a client holding the appropriate scope, including saved Wi-Fi information. Its scan endpoint returns the last 30 UTC days' daily counts and lifetime recorded total. It does not return answer bodies, individual scan records, visitor addresses or hashes, gate verifiers or billing/member records. A code-delete scope can delete a form's code and its answers under the existing deletion rules even though it cannot read answer bodies.

Webhook settings and delivery records. We keep the owner's label, HTTPS endpoint, selected events, enabled state, change reference, dates, failure count, in-account notice and encrypted recoverable signing material. For each queued notification we keep event/delivery and source references, the type and UTC time, code/scan/answer references where applicable, expiry, attempt/lease state, next-attempt time and a sanitized result/HTTP code. The outgoing JSON contains only an event ID, type, time, code and response references and whether it is a synthetic test. No answer text, question text, destination, code name, visitor address/hash or scan device/referrer/country detail is included. We discard remote response bodies instead of keeping them in delivery history. These records and reference-only signals can still relate to people; they are not claimed anonymous.

Private scan-count feeds. We keep the owner's feed label/reference, token verifier, version, creation and revocation times. The separate feed token is shown once in its private CSV address and is not stored recoverably in the feed table. The feed gives all current nondeleted, nonlapsed codes' keys, private names and recorded counts for the last 30 UTC days, including zero counts. It provides no answers, individual scan records or visitor identifiers. Anyone holding that address can read it while the token, account, feature and plan allow access. A request is checked without account sign-in; it does not create a connection to a Google account or select a spreadsheet. Rate counters follow section 5.

Artwork downloads for design tools. The additional artwork route uses the owner's existing code, appearance and logo to draw the requested PNG or SVG. We do not create a saved design, Canva account/asset reference, connection credential or separate retained artwork file through it. You decide whether to upload the downloaded image elsewhere; the image contains its QR payload.

Scan statistics for your codes. See section 4 for what each scan record holds. You see them as totals, daily counts and breakdowns.

Plan and billing references. Your plan name, whether it is billed monthly or yearly, the price, any plan change scheduled for the end of the period, its status (active, payment overdue, ended), the current period's end date, whether you have chosen to cancel at period end, and Stripe's identifiers for your customer record, your subscription and your checkout session. We never receive or store your card number. Stripe collects and keeps payment details under its own privacy policy. If you dispute a payment with your bank, we also keep that dispute's Stripe identifiers and the date we closed the account.

Usage counters. A count of scans logged for your account in the current month, used to apply the Free plan's monthly logging cap.

Service emails. We keep a record of the billing and grace-period emails we have queued or sent to you, with the time, whether each was delivered, and the amount each billing email stated.

Admin actions. If an administrator disables or re-enables one of your codes, we record when and why. That note is deleted with the code (section 8).

When you make an account, we do not ask for your name, company name, phone number or address. If you include them in an email to us, we keep that email.

Back to contents

4. What we collect when someone scans a code

When you scan an ovbq code or open its link, our server checks the code and what it is allowed to open. It may send your browser to a destination, show a page or file we host, or show a paused or outside-date notice. Continuing through a notice still follows the code's restrictions. A scan entry is recorded only after an eligible request has passed the code-level checks and the page or redirect has been sent. Eligible requests are GET requests and successful password submissions that open the code's main page or redirect.

If a code has a password, the visitor types it into a form on our page. We check it against the stored hash and do not put it in an address, a scan entry, our application logs or analytics.

If a website-link code has rules, we read the visitor's device type, browser language and the time of the request to pick the destination. We do not store the language or which rule matched.

A request that is refused by a password, date, pause or block does not become a scan entry.

For a code that starts a phone call, a text message or an email, it sends instead a small page that asks your device to start it, with a button in case your browser waits for a tap; nothing you then do in your phone, messages or email app reaches us. For a page we host, it sends the page, and for a file, it sends the file; an app download code sends an iPhone or Android phone straight to the app's store page (we read only the browser's user agent text to tell which), and other devices get a page with both stores. The hosted pages load nothing from other sites. When a scan is recorded, its entry contains:

• the time of the scan, in UTC;
• the type of device (phone, tablet or desktop), the operating system family (for example iOS or Android) and the browser family (for example Safari or Chrome). These are read from the browser's "user agent" text. We keep only these three short labels, not the full user agent text;
• the referring site's host name (such as news.example.com), if your browser sent one. A network address, or anything that isn't a valid host name, is not kept. A scan from a camera app normally sends none;
• a one-way hash of your IP address. We mix your IP address with a random value that changes every day, run the result through SHA-256, and store that. Each day's random value is deleted once that day is more than two days old, so about three days after it was made, and it is never copied into our backups. After that, we no longer hold that day's random value. A different random value is used each day, so the hashes do not provide a matching identifier across days. We use it only to count how many different network addresses scanned a code on a given day (people who share a network, such as an office or a cafe's Wi-Fi, count as one).

The hash stored in a scan entry remains with that entry for the scan-record period in section 8. Temporary visitor hashes for public-page counts are separate records and are deleted with their daily random values.

Your country, and nothing finer. While we handle the scan, our server looks up which country your IP address belongs to. It uses a database file kept on our own server, so no outside service is asked and your address is not sent anywhere. We keep only the two-letter country code (such as US or FR), or "unknown" if no country is found, and add 1 to that code's count of scans from that country for the day. The country is not added to the scan entry above. Your IP address is not stored, in the count or anywhere else in our database. We never record a region, city, postal code, network provider or GPS position. We do this only for codes on paid plans. The lookup can be wrong, for example for people using a VPN, a company network or some cellular networks, so code owners are told it is approximate. Country data: IP Geolocation by DB-IP, used under the Creative Commons Attribution 4.0 International license.

We do not store your IP address. We do not set any cookie, local storage or other identifier on your device when you scan. We tell browsers and caches not to store the redirect. We do not see or record what you do on the destination page.

We do not add a scan entry when a code is blocked or deleted, its account is closed, or the code is outside its start and end dates. A code paused by its owner or because of its plan is not logged, even if someone continues through its notice. We also do not record scans for HEAD requests, form-answer submissions, separate file or contact-card downloads, known bots or link-preview tools, or when the Free plan's monthly logging cap has been reached. Other non-GET requests are not recorded unless they are successful password submissions that open the code's main page or redirect. Skipping a scan record does not itself stop an otherwise available code from opening; any pause, date restriction or safety block still applies.

Opening a gallery page follows the scan rules above. Requests for its separate display images or thumbnails, including a separate protected image view, do not add scan entries. They still check the code's access restrictions. A password is checked for the requested response only; no visitor cookie or remembered unlock is added.

Opening a video or audio page follows the scan rules above. Requests for recording bytes, including seeking or range requests, and requests for posters, captions or a separate protected download do not add scan entries. A recorded page scan is not a play, completed listen or unique person. Those file requests still check the code's access restrictions. A password authorizes only the requested response, without a visitor cookie or remembered unlock. With JavaScript, the protected full-file response can be held temporarily in browser memory for playback; without JavaScript, it is downloaded for local playback. Removing access here cannot recall a response or copy already received.

As with every website, your IP address passes through the web server as the request is handled. Our web hosting provider in the United States keeps standard server access logs for a short period under its own policies; we do not copy them into our database.

Opening an event page follows the scan rules above. Downloading its separate calendar file does not add another scan entry. The download still checks the code's account, pause, dates and any password; it does not set a cookie or remember an unlock.

Loading a contact-card photo is a separate guarded file request, not another scan entry. We do not analyze the faces of people pictured or infer their identity from the photo.

Opening a payment-link code follows the normal scan rules. A recorded scan is not a payment or evidence that someone paid. We do not receive payment status from the external service.

A recorded scan can also cause a reference-only event to be queued for a destination the owner selected and enabled (sections 3 and 9). This does not add visitor fields to the scan record, expose its address hash or promise that every visit produces a delivered event.

Back to contents

5. What we collect from visitors, the free generator and abuse reports

Reading our pages. Our public pages (landing, pricing, help, terms, privacy and the like) set no cookie. The sign-in page, the page the emailed sign-in link opens and the abuse report page are the only pages here that set the cookie (section 6), and of those three only the sign-in page is counted. We count page views per day and roughly how many different visitors came, the same way we count scans, without cookies and without storing your IP address. The counts are daily totals per page, per referring site and per kind of device, system and browser, and they hold nothing about any one person. To tell a new visitor from a returning one on the same day, we keep a short one-way hash of the visitor's address, made with the same daily random value as in section 4; it is deleted together with that value, about three days later. Apart from our hosting provider's standard server access logs (section 4), nothing else is recorded about your visit. We run no analytics scripts, no advertising pixels and no third-party fonts or embeds.

Free generator (fixed codes). What you type or add in the generator on our home page (a web address, a Wi-Fi name and password, contact details, a message, or a logo image) is used only to draw your code. It is not stored, logged or sent to anyone else. With JavaScript on, the preview is drawn in your browser, and a download sends the content to our server once to make the file. With JavaScript off, each preview and each download sends it to our server to be drawn. Either way it is discarded as soon as the answer is sent, and we do not keep it. If you choose "Make it editable", the web address and the error-correction level you chose (and nothing else you typed) are kept so we can make the editable code once you have signed in. Until you ask for the sign-in link, it is kept in your session on our server (section 6). When you ask for the link, it moves to that sign-in request and is removed from the session, and it is deleted with the sign-in link. If you never ask for a link, it is deleted from the session within 24 hours (section 8). Any sign-in request, with or without this, also holds the email address you typed and the page to return to after signing in, whether or not that address has an account; it is deleted with the link.

Fixed product barcode links. We use the product URI, GTIN and supported qualifiers to validate and draw the fixed code. A product-link preview may send the URI to our server for validation even with JavaScript on; it need not be a browser-only preview. Each such request follows the request-only handling above: the input is discarded when the response is sent and is not kept in a product registry or account record. We do not fetch the URI's destination or send these inputs to GS1. Anyone who can read a printed or shared copy can read its URI and identifiers.

Fixed event invitations. Event details entered in the free fixed-code generator are used only to draw the code, under the same transient processing rule above. They are embedded in the fixed code; we do not keep an event page or a list of recipients for it.

Turning off weekly scan email. The unsubscribe link contains a signed reference for this one email preference. Opening it shows a confirmation without changing the setting or starting a session. Confirming it, or using a mail app's supported unsubscribe action, turns off the summary without signing in. Anyone with the link can turn off that summary; it cannot sign them in to your account. The unsubscribe link's full web address may remain in browser history and our host's standard access logs. We use no email-open tracker or tracking pixel.

Abuse reports. If you report a code, we keep the code or link you named, the reason you chose, your optional details, and your email address if you gave one so we can reply. We also store a one-way hash of your IP address (made the same way as in section 4) to limit how many reports one address can send in an hour.

Rate limits. To stop abuse of the sign-in form, the report form, the free generator, logo uploads, file uploads and password prompts on codes, we count requests for one hour at a time: per network address, per email address for sign-in, and per account for logo and file uploads and per code and network address for password prompts (30 tries an hour; people who share a network share the count). The counters store a one-way hash of the address or account number made with the same daily random value as in section 4, not the address or number itself, and are deleted after two days.

Email to us. If you email us, we keep the message and our reply.

CSV processing is separate from the homepage generator. Checking a bulk file sends it to our server and keeps the limited preview/result records described in sections 3 and 8; the homepage's request-only drawing rule does not describe those stored batch records. PHP uses a temporary upload for the request and normally removes it when the request ends; we make no separate project copy of the source upload. CSV/ZIP downloads are generated for the request rather than kept as saved export files. System temporary-file cleanup after a failed request is handled by the host.

API request handling. The owner key is sent in the authorization header, not a URL. Requests use no sign-in cookie. Per-key counters store the key reference, UTC-minute window and hit count, not a client address or request body. A generic internal-error entry does not include the body or key; ordinary server access-log handling in section 4 still applies. The limited creation receipts described in section 3 last 24 hours.

Private feed addresses and request limits. A feed token is part of the private URL you give the consumer. The full address can appear in formulas, collaborators' copies, browser history and our hosting provider's standard access logs under the handling in section 4. We do not claim it is never logged. Application rate counters use a one-way hash of the feed reference with the daily random value described in section 4; counters are deleted after two days and daily values are excluded from backups as already described. Feed output is generated for the request, not kept as a separate saved CSV. Revocation stops new authorized reads, but a response already authorized may finish and recipient copies remain.

Recording checks. Uploaded recordings are checked on our server for supported format and length before acceptance. These checks do not remove embedded details or establish that the owner has permission to share the content. The recording is not sent to a separate conversion, transcription or preview service through this feature. Saved recordings and their supporting content follow sections 3 and 8.

Back to contents

6. Cookies

We use exactly one cookie, named __Host-ovbq. It keeps you signed in. It holds a random identifier and nothing else. It is marked Secure, HttpOnly and SameSite, and it stays for 14 days, even after you close the browser, unless you sign out or delete your account first.

We set it when you sign in, and also when you open the sign-in page, the page the emailed sign-in link opens or the abuse report page (choosing "Make it editable" takes you to the sign-in page), because their forms need a session to protect against forged submissions. If you only read our other pages, use the free generator, or scan a code, you get no cookie.

The session the cookie points to is kept on our server. It holds only what the site needs from one page to the next: whether you are signed in, a security token for the forms, short messages to show you on the next page, a note of the codes you just made (so a form sent twice makes one code), and, after "Make it editable", the web address and error-correction level until you ask for the sign-in link (section 5), at most 24 hours, and then only a one-way hash of that link, so the editable code is made at once only in the browser that asked for it. Signing in starts a new session, so nothing from before it is carried over.

Some editor actions, such as choosing a template, adding, removing or moving items, or updating date fields, send your unsaved draft to our server. We keep a temporary copy so you can reload or reopen it. This can include the text, links and settings you entered. Your session holds a random reference to these copies. The draft address also contains a random reference, and works only in the same signed-in browser and account. These copies are deleted within 24 hours after the last action that stored or updated that draft, or sooner when you save that draft, sign out, delete your account or newer drafts replace them. Uploaded gallery photos follow the separate temporary-upload rule below.

If you reach your plan's code limit while making a code and choose to upgrade, your browser keeps the name, web address and error-correction level you were making (for a code of another kind, such as a text message or a Wi-Fi page, its kind and what you filled in for it, a Wi-Fi password included) in its session storage for that tab, so the form is filled in again when you come back from the payment page. The copy in session storage stays in your browser. Server copies from editor actions follow the rule above. The copy in session storage is removed once the form is filled in again, when you make a code, when you sign out, or when you close the tab.

There are no advertising cookies, no analytics cookies and no third-party cookies. Because of this, we show no cookie banner. If you block cookies, you cannot sign in, but scanning codes still works.

Back to contents

7. How we use information

We use the information above to:

• run the service: create accounts, sign you in, store your codes and redirect scans;
• show code owners how their codes perform;
• bill paid plans and send billing notices;
• enforce plan limits, including the 30-day grace period after a subscription ends, and send the grace-period reminders;
• prevent, detect and respond to abuse, fraud, phishing and security problems, including handling abuse reports;
• send you service emails: sign-in links, billing notices, grace-period reminders, warnings about your codes, emails about new answers to your forms, as you set for each form, and notices of changes to our terms or this policy;
• send the weekly scan-count summary you choose, honor its unsubscribe setting and avoid duplicate submissions; the summary has no promotions, individual visitor records, code names, destinations or form answers;
• run the separate Team invitations and selected-code/scan/answer permissions the owner chooses, without transferring personal accounts;
• check and create the batch you confirm, provide its result and recognize a repeated unexpired receipt;
• authorize scoped owner API requests, enforce request limits and recognize limited creation retries;
• sign and send the reference-only signals the owner chooses, record delivery attempts and manage bounded retries;
• serve the private aggregate scan-count feed to holders of the token the owner chooses to share;
• draw the additional artwork download the owner requests for later manual use in a design tool;
• keep records the law requires, such as tax and accounting records;
• improve the service by looking at totals and patterns, never by profiling individuals.

We send no marketing email. We make no decisions about people by automated means that have legal or similarly serious effects. The automated steps include the bot filter, the rate limits, form spam and wording checks, and any destination safety check we may operate; these checks and the optional-tool controls described above affect whether a request or an answer is counted or stored, whether a form's wording is accepted, whether a code is flagged for review, or whether the requested tool access, code creation or delivery can proceed.

Back to contents

8. How long we keep information

You can delete your account yourself from your Account page (section 12).

Database copies of invitation and membership records follow the existing backup overwrite ceiling of 30 days after deletion. A safe reference to an invitation-creation operation can remain for 24 hours before hourly cleanup; it contains no raw invitation token.

Database copies of retained batch records follow the existing backup overwrite ceiling of 30 days after deletion. Source upload temporary files and generated export downloads are not separate retained files in our normal project backup.

Database copies of API verifiers, metadata, counters and receipts follow the existing backup overwrite ceiling of 30 days after deletion. A safe browser key-creation reference lasts 24 hours before hourly cleanup and contains no raw key.

Database copies of webhook settings, encrypted signing material and reference-only delivery records follow the existing backup overwrite ceiling of 30 days after deletion. A safe browser configuration-creation reference lasts 24 hours before hourly cleanup and contains no raw signing secret. Expiry is checked before sends even if cleanup is delayed; turning off availability does not itself erase unexpired queued records.

Database copies of feed verifier/metadata and safe creation-operation references follow the existing backup overwrite ceiling of 30 days after deletion. The safe creation reference lasts 24 hours before hourly cleanup and contains no raw feed token. The existing two-day rate-counter and daily-value rules still apply.

Back to contents

9. Who we share information with

The following providers and other recipients help us run the service and receive only what their role needs. Separately authorized people and customer-chosen services can receive the limited information described below when you choose that access.

• Stripe (payments): your email address, our internal account number, your plan, and the payments you make. Stripe runs the checkout and billing pages under its own privacy policy and sends us the subscription details listed in section 3.
• Our web hosting provider in the United States: runs the servers and the database where all the data above, including form answers, is stored, and the mail server that delivers our sign-in links and service emails. That mail server sees the recipient address and the message. If a business chooses emails with answers, that includes the answer text in the message. Standard server access logs stay with the provider.
• Google Safe Browsing or similar safety services (if and when we use them): we may send the destination links that code owners set to a service that checks them for phishing and malware. We send the destination link, not any information about the people who scan.
• Professional advisers and authorities: lawyers, accountants and auditors under confidentiality, and courts, regulators or law enforcement when the law requires it or to protect people from harm, including the National Center for Missing & Exploited Children when the law requires a report. We tell account holders about legal demands for their data unless we are forbidden to.
• A buyer or successor: if ovbq is sold or merged, the information moves with it, and we tell you first. Our Terms promise at least 90 days' notice and a working export if the service ever shuts down, and that your codes are never sold or transferred to a third party without notice and a chance to export.

We do not use Cloudflare or any other network proxy at launch. If we add one later, every request would pass through it and it would see the requester's IP address under its own privacy policy; we would update this policy before doing so.

The same mail service described above delivers the optional weekly summary and handles its recipient address and message. The summary contains account-level recorded counts, not individual visitor data or form answers.

Following a payment link takes the visitor to the recipient's chosen external service. That service handles the visit and any payment under its own privacy policy. It does not send us the payment result through this feature.

The web hosting provider described above stores and serves gallery content and files, including temporary draft copies and file details. Gallery images do not need an outside image-hosting service through this feature.

Our existing web hosting provider stores and serves uploaded recordings and their captions, transcripts and posters. This feature adds no outside conversion, transcription, media-hosting or embedded-player service. A YouTube, Vimeo or SoundCloud button opens the service named by its actual host. That service receives the visitor's request when they choose to open it and handles the visit, playback and any account requirement under its own terms and privacy policy. We do not automatically contact it to fetch a recording or preview. Our page's password or other restrictions do not control access to its separate copy, and deleting content here does not delete that copy.

Following a business page's booking, directions, website, menu or other outside link takes you to the service chosen by the page owner. That service handles your visit and any booking under its own terms and privacy policy. ovbq does not take or confirm the booking or receive its result through this feature.

Page-language labels and messages come from catalogs supplied with our service. This feature does not send your page content to a translation company or create a new outside translation recipient.

Generating a product barcode link does not contact GS1 or the URI's destination with your input. Following the printed URI sends the visitor's request to the host named in it, under that service's handling; it does not pass through an ovbq short-link resolver supplied by this feature.

People the owner authorizes. Team members use separate sign-ins. An intended invitee can receive the limited invitation-review details described in section 3 before accepting. The owner authorizes this disclosure by creating the invitation and choosing the codes to share. Accepted members can see the owner's account email with their shared-code context. The owner controls which existing codes they may read and whether an Editor may change supported content. This private access can include code names, hosted files/images and Wi-Fi details independently of a public visitor password or date restriction. Separate grants control scan counts, answer viewing and answer CSV. No member deletion right is added. The owner sees member addresses and permissions; members do not receive the owner roster. Removal blocks new authorized reads, but cannot recall a response or stream already authorized or a copy already obtained.

Clients given an owner API key. A client the owner authorizes can use only the key's scopes and that owner's resources. This can disclose private code content and the limited aggregate scan statistics in section 3. No answer bodies or individual scan records are supplied through this API. Giving a client a key is not giving it the owner's email-link sign-in or a Team membership. The owner is responsible for the chosen client's authority and handling; we remain responsible for enforcing our access boundaries.

Destinations chosen for notifications. The owner chooses and enables the HTTPS recipient, which may be a workflow such as Webhooks by Zapier. We send only the reference-event fields in section 3 and no answer body. The owner is responsible for the recipient, its notices and onward use; we remain responsible for the limited authorized sending and our retained records. The recipe does not create an OAuth connection, partner app or guarantee that a workflow ran. Delivered event copies can remain in the recipient's history or downstream tools under the customer's separate arrangement. No additional provider is appointed by us through this feature.

Consumers given a private feed address. Google Sheets or another service receives the token URL and its CSV when the owner gives it that address. The feed contains code keys, private code names and recorded 30-day counts for all current nondeleted, nonlapsed owner codes, not answers or individual scan details. People with the address or access to the resulting spreadsheet/copies may see those values under its sharing settings. Revoking it does not erase already received data, formulas or cached copies. This is a customer-chosen recipient, not an OAuth app or new provider appointed by us.

Manual design-tool upload. The artwork feature sends the generated image to the owner. If you then upload it to Canva or another tool, that is your separate use of that tool under its terms. The image can disclose its encoded payload and any artwork/logo. ovbq does not make that provider upload or appoint Canva as a provider through this feature.

We use no advertising networks, no analytics companies and no data brokers.

Form answers are made available to the business that runs the form. Our staff and providers handle them only for the purposes described in section 19 and section 26 of our Terms.

Back to contents

10. We do not sell your information

We do not sell personal information, and we do not share it for cross-context behavioral advertising or targeted advertising, as those terms are defined in US state privacy laws. We have not done so in the past 12 months. Code owners see statistics about scans of their own codes (section 17), which is part of the service they asked for, not a sale.

This includes form answers.

Back to contents

11. Legal bases, for people in the EU, UK and similar places

ovbq is a US service aimed at US businesses and we do not market it in the EU or UK. If the GDPR or the UK GDPR nonetheless applies to you, we rely on these legal bases:

• Contract: to provide the service to account holders (account, codes, sign-in, billing, support).
• Legitimate interests: to redirect scans and record the scan statistics described in section 4, to prevent abuse and keep the service secure, and to keep business records. We have weighed these interests against your rights. The scan data includes the daily hashed network address described in section 4, which can count as personal information. You can object as described in section 12.
• Legal obligation: tax, accounting and responding to lawful requests.
• Consent: only where we ask for it.

We do not need consent for our single cookie because it is strictly necessary to provide the service you ask for.

For form answers we act for the business that runs the form, which relies on its own legal basis.

Back to contents

12. Your rights, wherever you live

We give everyone the same choices, whether or not a law requires it where you are:

• Access: ask what information we hold about you.
• Correction: fix anything wrong. Account holders can change their codes themselves in the dashboard.
• Deletion: delete your account from your Account page any time, unless a checkout is still open or the account was closed after a chargeback (see below). If a paid plan is running, you choose: we cancel it at the end of the billing period you paid for and delete the account then (the plan keeps working until that day), or we delete it at once and you give up the rest of the billing period. We do not refund unused time in a billing period. We ask you to confirm, then remove your codes, scan statistics, form answers and account data, keeping only the billing records the law requires. Deleting an account retires all its codes permanently. You can also email us and we will do it for you within 30 days, the same way: with a paid plan running, when the paid billing period ends, unless you ask for it at once.
• Export: download a CSV of your codes and their destinations from the dashboard at any time while your account is open, on every plan. If a payment dispute closed your account, email hello@ovbq.com from your account address for the file (Terms, section 16). You can also download QR images any time (even while a code is paused because a plan ended), and paid plans can download scan records, and monthly scan counts by country, as CSV. Your email address, plan history and the emails we sent you are not in these files; ask us at privacy@ovbq.com and we will send you a copy (section 12, Access).
• Form-answer export: you can download the answers to each of your forms as a CSV file on any plan while you can sign in, including after a paid plan ends, while the form's code is paused and while new form answers are switched off. If your account is closed, write to privacy@ovbq.com and we will send or delete the remaining answers.
• Objection and restriction: object to a use of your data that relies on legitimate interests, or ask us to pause processing while we check a request.
• Withdraw consent: where we rely on consent, at any time.
• Appeal: if we refuse a request, we tell you why, and you may ask us to review the decision by replying to our answer. We respond to the appeal within 45 days. You may also complain to your local data protection authority or state attorney general.
• No discrimination: we will not charge you more or serve you worse for exercising a right.

If you dispute a payment with your bank (a chargeback), we close the account at once, when the dispute is opened: sign-in stops and your codes stop opening their pages. To sort out a billing problem, write to hello@ovbq.com first; we answer within 2 business days. We keep a closed account as it is until you ask us to delete it. We then delete everything except the billing and dispute records, which we keep for 7 years (section 8). The account holder can still ask us for the code-list CSV by email (Terms, section 16).

To exercise a right by email, write to privacy@ovbq.com from the address on your account, or from any address if you have no account. We may ask you to confirm the request from the account email before acting, because that is the only way we can verify an account holder. We answer within 45 days (one month under the GDPR) and tell you if we need longer. You may use an authorized agent; we will ask the agent for proof of authority and still confirm with you directly.

If you scanned a code: each recorded scan holds a daily one-way hash of the network address, not your IP address or name. A hash can still count as personal information. To ask about scan records or exercise a privacy right, contact privacy@ovbq.com. If we cannot identify records relating to you from the information we hold, we will explain that in our response. If you believe a code was used to track you unlawfully, report it at ovbq.com/report or abuse@ovbq.com.

If you answered a form: the business that runs the form decides what happens to your answers, so ask it first; its name is on the form page. We store no separate name, email address or network address with your answers that lets us find them for you, unless you typed identifying details into the form. If you cannot reach the business, write to privacy@ovbq.com with the form's address and what you sent, and we will tell you which business runs it or pass your request on.

Your login and shared records. Removing your membership or deleting your own account ends your shared access; it does not delete another owner's codes or answers. You can use the rights above for your own personal information, but a privacy request does not authorize access to another person's workspace records. The owner controls its selected member permissions and remains responsible for requests about its form answers. Closing/deleting the owning account removes shared grants; reopening does not restore old grants. The owner's existing account and answer-export rights remain separate from member availability.

Batch removal. The owner can remove a retained preview/result before expiry. That removes the temporary batch, not codes already created. Closing/deleting the owning account clears retained batches under section 8.

API revocation. The owner can revoke a key even after new API access is unavailable. New authorized requests then stop after already accepted work finishes. Closure revokes old keys; reopening cannot restore them. Revoking a key does not disable separate feeds or webhook configurations, and loss of API access does not remove the existing owner dashboard/email export rights.

Stopping notifications. The owner can disable or delete a configuration even after new webhook access is unavailable. Choosing Disable cancels waiting, paused or claimed work but retains the configuration and completed history until their stated deletion; choosing Delete or owner closure/deletion clears the configuration and history. Repeated failures or a full queue can automatically turn the webhook off. Waiting notifications are paused and kept until their existing expiry under section 8; choose Enable to resume those still available. A send already authorized may still arrive, and already delivered copies remain with the recipient. Removing a member or revoking an API key is not webhook disablement.

Feed revocation. The owner can revoke a token even after new feed access is unavailable. Revocation and closure stop new authorized reads; reopening does not restore the old token. They do not clear the receiving spreadsheet or other copies.

Back to contents

13. Notes for US states

California. California residents have rights under the California Consumer Privacy Act as amended by the CPRA, including the rights to know, delete, correct, and opt out of sale or sharing. We do not sell or share personal information, so there is nothing to opt out of, and we do not use or disclose sensitive personal information except to provide the service. Othex Corp is a small company and does not meet the revenue or data-volume thresholds that make the CCPA apply, but we honor the rights in section 12 for Californians regardless. The categories of personal information we collect, with sources, purposes and recipients, are described in sections 3 to 9: identifiers (email address, hashed network addresses), commercial information (plan and payments), internet activity (scan records and the codes you create), and the country a scan came from, kept only in daily counts per code. Account holders must be at least 18 (section 15). Forms may not be aimed at children under 13 or knowingly collect their answers (section 15). Under California Civil Code section 1798.83, you may ask what personal information we disclosed to third parties for their direct marketing; the answer is none.

Florida. The Florida Digital Bill of Rights applies to very large companies and does not apply to Othex Corp. We still give Floridians the rights in section 12.

Colorado, Connecticut, Virginia, Utah, Texas, Oregon, Montana, Delaware, Iowa, New Hampshire, New Jersey, Tennessee, Minnesota, Maryland, Indiana, Kentucky, Nebraska, Rhode Island and other states with privacy laws. Most of these laws apply only above a threshold number of residents or revenue that we do not meet. Whether or not they apply, residents may use the rights in section 12, including the right to appeal, and we do not sell personal data, process it for targeted advertising, or build profiles.

Nevada. We do not sell covered information as defined in Nevada law.

Where a business that uses our forms is covered by a US state privacy law, we act as its service provider or processor under section 26 of our Terms: we use form answers only for the purposes and specific access/notification instructions set there, do not sell them or use them for advertising, and do not combine them with other information.

Back to contents

14. Where your information is stored, and international transfers

Our servers are in the United States, and we are a US company. If you use ovbq from outside the United States, including the EU, UK, Switzerland or Canada, your information is transferred to and stored in the United States, where privacy laws may differ from yours.

We are not certified under the EU-US Data Privacy Framework. For transfers from the EU, UK and Switzerland, we rely on the European Commission's Standard Contractual Clauses (and the UK Addendum) in our contracts with providers where needed. Stripe maintains its own transfer mechanisms. You may ask us for more detail at privacy@ovbq.com.

Form answers are kept in the United States, and we do not offer a transfer contract for them by default (section 26 of our Terms). If you answer a form from another country, your answers go to the United States. A business that needs a transfer contract for form answers must contact us before it starts collecting them.

Authorized members may read or download their permitted shared records from another country. Our hosted copy remains subject to the existing US storage and backup rules; a member-held copy is not thereby kept only in the United States.

A client holding an owner API key can receive its authorized data outside the United States. The owner chooses the client and is responsible for its lawful handling; that does not change our responsibility for our own copies or create a new transfer-contract promise.

A customer-selected notification destination and its downstream tools can be outside the United States. Reference IDs and times can still relate to people. Our US storage statement does not promise the location or deletion of a recipient-held copy; our own queue and source-deletion duties remain as stated above.

A private feed consumer, spreadsheet collaborators and their copies can be outside the United States. The owner chooses that disclosure; no US-only location or new transfer mechanism for those separate copies is promised.

A design-tool upload you make after downloading the artwork follows that tool's location and handling. We make no provider upload or US-only promise for your separately held copies.

Back to contents

15. Children

ovbq is for adults and businesses. To make an account, sign in or use the dashboard, you must be at least 18 and old enough to make a binding contract where you live if that age is higher. No one under 13 may make an account or use the dashboard. Anyone may scan an ovbq code without an account. If we confirm that an account holder is below the age our Terms require, we close the account (Terms, section 2). For someone under 13, we act promptly and delete the account's personal data, except records we must keep by law; other retained records and backups follow section 8. We do not ask for your age or birth date to check this. We do not knowingly collect information from children under 13. If you believe a child has given us information, email privacy@ovbq.com and we will delete it.

A child may scan a code that a business printed; that scan follows the same recording rules described in section 4.

Forms may not be aimed at children under 13 or knowingly collect their answers. If you believe a child's answers reached a form, tell us at privacy@ovbq.com or tell the business. We will delete those answers or pass your note to the business so it can identify and delete them.

Back to contents

16. Security

We take sensible steps to protect information:

• all pages and redirects use HTTPS, and we instruct browsers to use HTTPS only;
• account sign-in uses no password; sign-in links expire in 15 minutes and we store only a hash of them;
• the cookie is Secure, HttpOnly and SameSite, and forms that change account data are protected against forged submissions;
• we store no card numbers and no raw IP addresses in our database;
• our pages run a strict content security policy and send no data to third-party scripts;
• access to the admin area is limited to named staff and administrator actions are logged;
• configuration secrets are kept outside the web root with restricted file permissions.

No system is perfectly secure. If we learn of a breach that affects your information, we will tell you and any regulator as the law requires, including Florida's data breach law, which sets a 30-day notice period.

For a breach affecting form answers, we tell the business without undue delay and within 72 hours after we confirm it; the business tells the people who answered and any regulator as the law requires (section 19 and section 26 of our Terms).

Back to contents

17. If you scanned a code: what the code's owner sees

The person or business that printed the code can see statistics about scans of that code:

• how many scans there were in total, per day and by hour of the day, and how many different network addresses scanned on each day (people who share a network count as one);
• breakdowns by device type (phone, tablet, desktop), operating system family, browser family and referring site;
• on paid plans, a country breakdown for the last 30 days. It shows up to 10 countries with the most scans. A country is named only if it has at least 10 scans. All remaining countries and scans whose country is unknown are grouped as "All other countries". If that combined count is fewer than 10, it is shown as "fewer than 10". The monthly country CSV names every country with at least 10 scans in that month and applies the same grouping and small-count rule to the rest;
• on paid plans, a downloadable list of scans with the time, device type, operating system, browser and referring site of each scan.

The owner never sees your IP address, the hash of it, your name, any location finer than a country, your device model, or what you did on their page. The owner cannot tell that two scans came from the same person on different days. If the owner's page then collects information from you, that is governed by the owner's own privacy policy, except that for a form we host we store your answers for the owner as section 19 describes.

If a code sent you somewhere harmful or you believe it is being used to track people unlawfully, report it at ovbq.com/report or abuse@ovbq.com. We review every report.

Shared scan counts. A member needs a separate scans grant for a selected code. The member route provides daily recorded counts for the last 30 UTC days and the lifetime recorded total; it adds no individual-scan or country CSV. This grant is independent of permission to read form answers or export them.

API scan counts. A scoped owner key can return the last 30 UTC days of recorded daily counts and the lifetime total for a permitted code. It adds no individual scan list, country breakdown, address/hash or visitor identifier.

Scan notification recipients. An owner-enabled webhook can receive the reference-only signal in section 3 when a recorded scan is inserted. It has no visitor address/hash, device, referrer or country field. Its timing and code/event references are still disclosures, and delivery is best effort rather than a complete visitor history.

Feed readers. Anyone holding an available private feed address can receive the code key, private code name and last-30-UTC-day recorded count for all current nondeleted, nonlapsed owner codes. No individual scan record or visitor identifier is supplied; section 9 explains the recipient boundary.

Back to contents

18. Changes to this policy

If we change this policy in a way that matters, we email account holders at least 30 days before the change takes effect and update the date at the top. Smaller changes, such as naming a new provider that does the same job, take effect when posted, except a new or replacement provider that handles form answers, which we tell businesses about by email at least 30 days ahead (section 26 of our Terms). Past versions are available on request.

Back to contents

19. Forms on pages we host

Who is responsible. An account holder on Pro or Business can put a form on a page we host for them. The account holder (the business) decides what the form asks and what is done with the answers. We store the answers and show them to that business, on its behalf and only to provide the service. In privacy law terms, the business is the controller or business for the answers and we are its processor or service provider (section 26 of our Terms). If you answered a form, the business's own privacy policy applies to your answers, and the business is the one to ask to see, fix or delete them.

What the form page tells you. The page names the business that runs it and warns you never to enter passwords or card numbers. It links to the business's privacy policy if the business gave one, and to this section through "How ovbq handles answers". After you send it, the page says any reply comes from the business. Every page we host has a "Report this page" link. If a form looks like phishing or asks for something it should not, use that link, ovbq.com/report or abuse@ovbq.com. We do not email or text you because you answered a form. If form answers are affected by a breach, we tell the business without undue delay and within 72 hours after we confirm it, and the business tells the people who answered as the law requires.

What we store when you send a form. Your answers, the questions as they read when you answered, the date and time you sent them, and whether an email about them is still due. We do not store your IP address, your device, your browser or your location with your answers, and the form sets no cookie. As with every page, your IP address passes through the web server as the request is handled, and our hosting provider keeps standard server access logs for a short period (section 4). Answers are sent in the form submission, not in its web address.

How we keep forms from being misused:

• Spam checks. The page carries a hidden field that people never see, and a signed value with the time the page was made. A form sent with the hidden field filled in, or within a few seconds of the page loading, is not stored.
• Rate limits. For each form, we count attempts to send it from one network address within an hour. Attempts still count if an answer needs correcting. Attempts rejected by the hidden-field or signed-time checks do not count. The counter holds only a one-way hash made with the daily random value (section 4), and is deleted after two days (section 8).
• Daily limit. Each form takes a limited number of answers a day, counted in UTC. Answers sent after that are not stored, and the page says so.
• Wording checks. Forms may not ask for passwords, PINs or sign-in codes, card numbers or security codes, bank account or routing numbers, government ID numbers, or wallet recovery phrases or keys, or use wording common in phishing. We check a form's wording when it is saved and again when answers are taken, and refuse it if it fails. Other content rules, including health information and children under 13, are in section 25 of our Terms.

Who sees the answers. The business that runs the form, through its own account and the separate member access it explicitly permits below. It can read them, delete them and download them as a CSV file, on any plan, including after a paid plan ends, while the form's code is paused and while new form answers are switched off. If its account is closed, the business can write to privacy@ovbq.com to request its remaining answers or their deletion. For each form the business chooses how we tell it about new answers by email:

• A daily summary. Unless the business chooses otherwise, a daily summary of the previous day (UTC), with counts only, is sent when answers came that day. It contains how many came, the average of each rating and how many people picked each choice. It never quotes typed responses or includes a name, email address or phone number from a typed response.
• Emails with answers. Emails to the account address include the answers themselves, such as a name, email address or phone number typed into the form. Several submissions close together may come in one email, at most one every 5 minutes. Each email includes up to 5 submissions, with each response to a question cut at 500 characters; any further submissions are counted and can be read on the answers page. Web addresses containing a scheme followed by ://, or beginning with www., are broken in the email. The mail app may still turn other text, such as bare domains or email addresses, into links.
• No email. The business reads the answers on our site only.

Emails go through the mail server of our hosting provider (section 9) and are kept in the business's own mailbox under its email provider's terms. Deleting an answer on our site does not delete an email already sent. Our staff look at answers only when needed to run or secure the service, to handle an abuse report, or when the law requires it. We may delete answers or stop a form when the law requires it or the form breaks our Terms, including the rule against collecting answers from children under 13. We use answers for nothing else, and we do not sell them.

How long we keep answers. The business chooses, for each form, how long answers are kept: 1 to 365 days, and 365 days unless it chooses otherwise. 365 days is the most on every plan. Each answer is deleted automatically within an hour after that time is up, counted from when it was sent. If the business changes the time, the new time counts from when each answer was sent, so shortening it can delete older answers immediately after the business confirms the change. Deleting an answer, the form's code or the account deletes the affected answers from our database at once (section 12). Answers are not deleted just because a paid plan ends. Deleted answers are gone from our backups within 30 days (section 8). Copies in emails already sent remain in the business's mailbox, which the business must clear itself.

Where answers are kept. Form answers are kept in the United States. We do not offer a transfer contract for them by default; businesses that need one must contact us before collecting answers (section 26 of our Terms).

Members allowed to see answers. The business can separately permit a member to view a selected form's answers and, only with a further grant, download its answer CSV. Members cannot delete answers or change the form's questions, answer keep time or notifications. No general Editor or scans grant permits answer access. A member can manually copy an answer they are allowed to read. The business controls these grants and its members' authority; our access checks, answer-deletion and backup duties still apply. Removal blocks new authorized access but cannot recall an already authorized response or downloaded copy. The business keeps its own existing answer access, export and deletion rights even when new Team access is unavailable.

Reference-only answer notifications. If the business enables a form notification, we send its chosen endpoint the event ID, type and UTC time, code and response references and test indicator described in section 3. We send no question text or answer body and provide no API route to read answer bodies. The business is responsible for authorizing that recipient, its notices and lawful onward use. These identifiers/times may still relate to a respondent. Our queue keeps references, not a second answer copy; deleting the source answer/form/account removes its matching references, and expiry is checked before sends. A request already authorized can still arrive; copies already delivered remain with the chosen recipient. Our own answer, queue and backup deletion duties do not become the recipient's responsibility.

Back to contents

20. Contact

Othex Corp
5645 Coral Ridge Drive STE 137
Coral Springs, FL 33076
United States
privacy@ovbq.com (general questions: hello@ovbq.com)

We have not appointed a representative in the EU or UK, because we do not target or monitor people there. If you are in the EU or UK and we have not resolved your concern, you may complain to the data protection authority where you live.

Back to contents