Reservly Security & Responsible Disclosure

Last updated: April 26, 2026

The short version

• Report vulnerabilities to security@reservly.io — PGP optional, plain email fine.
• Safe harbour for good-faith security research that follows this policy. We will not pursue legal action or encourage law enforcement for activity that stays in scope.
• Acknowledgement within 3 business days. Initial triage within 10 business days.
• No public bug bounty at launch — this is an email-based programme. We can send swag and public acknowledgement; cash rewards are planned but not available yet.
• Scope is reservly.io and its subdomains, the Reservly API, the MCP server, and Reservly-hosted booking pages. Out of scope: third-party integrations and business-customised content. Details in § 4.

We take security seriously. Reports from good-faith researchers are welcome.

1. Policy

Reservly commits to:

• Acknowledging every report within 3 business days.
• Initial triage within 10 business days — we will tell you whether we can reproduce the issue, whether we consider it valid, and roughly when we expect to resolve it.
• Coordinated disclosure — we work with you on timing and wording of any public discussion.
• Credit — we publicly recognise researchers who report valid vulnerabilities, unless you prefer to remain anonymous.
• No legal action against researchers whose activity in good faith follows this policy.

In return, we ask you to:

• Stay in scope as described in § 4.
• Avoid privacy harm — don't access, modify, or exfiltrate data that isn't clearly your own, beyond the minimum needed to demonstrate the vulnerability.
• Give us a reasonable window to fix the issue before disclosing it publicly, typically 90 days or as mutually agreed.
• Follow the reporting process in § 3.

2. Safe harbour

Reservly will not initiate civil action or report to law enforcement for security research that:

• Stays within the in-scope surface in § 4.
• Respects the restrictions in § 5 (no privacy harm, no degradation of service, no social engineering of our employees or customers).
• Uses reasonable efforts to contact us through the channels in § 3 before public disclosure.
• Avoids violating any other law (for example, exporting data to a sanctioned jurisdiction, or using the vulnerability to commit an unrelated offence).

If your research inadvertently crosses a line — for example, you accessed more data than necessary — tell us what happened as part of your report. We will work with you in good faith.

This safe harbour is a commitment from Reservly only; it does not purport to bind third parties (such as our sub-processors), and it does not override applicable law. Nothing here constitutes legal advice; if you are concerned about exposure, consult counsel before starting your research.

3. How to report

Email: security@reservly.io

What to include:

1. Description of the issue — what it is, what conditions trigger it.
2. Reproduction steps — the minimum sequence that demonstrates the issue. A screen recording or short video helps.
3. Affected surface — which URL, endpoint, parameter, or flow.
4. Impact — what an attacker could do if they exploited the issue.
5. Your assessment of severity — low / medium / high / critical, in your judgement.
6. Any additional context — was it found through manual testing, automated scanning, or something else? Have you reported this elsewhere?

How we treat your report:

• We acknowledge receipt within 3 business days.
• We triage within 10 business days and reply with our assessment.
• We keep you updated as we work on a fix.
• Once the fix is deployed, we let you know.
• If you agree, we credit you publicly (see § 7).

PGP. PGP encryption is optional. If you prefer to encrypt, email us at security@reservly.io with subject PGP key request and we will respond with the current public key fingerprint.

4. Scope

4.1 In scope

• reservly.io and all subdomains (app.reservly.io, api.reservly.io, images.reservly.io, docs.reservly.io, and any future subdomain Reservly operates directly).
• The Reservly REST API under reservly.io/api/.
• The Reservly MCP server exposed at reservly.io/api/mcp.
• Outbound webhooks emitted by Reservly.
• Reservly-hosted booking pages at reservly.io/<business-slug>/ — but not the uploaded content of individual Businesses (see § 4.2).
• Authentication flows — signup, login, password reset, OAuth connect/callback, session management.
• Payment integration surfaces — the connect flow for Stripe, PayPal, and Paddle handles; our own handling of transaction identifiers and last-four digits. The providers themselves (Stripe, PayPal, Paddle) are out of scope; report issues with their services to them.
• Infrastructure reachable via reservly.io — including error pages, third-party widgets we embed, and file downloads.

4.2 Out of scope

• Content uploaded by Businesses — if a Business has published an image or text on its booking page that concerns you (for example, adult content, scams, or misinformation), report it via the AUP Report channel instead.
• Third-party services integrated with Reservly — Stripe, PayPal, Paddle, Google, Microsoft, Zoom, Dropbox, Sentry, Supabase, Vercel, Cloudflare, Resend, Telnyx, Infobip, Twilio, Upstash. Each has its own security-disclosure programme. Report issues directly to them.
• Browser extensions, desktop apps, or third-party tools that interact with Reservly but are not published by Reservly.
• Denial-of-service findings that require sustained load to demonstrate. We already rate-limit our APIs; if you identify a vulnerability that allows bypass of rate limits, that IS in scope — but don't run actual DoS against us.
• Reports generated by automated scanners with no human triage and no proof-of-concept. We will still review, but please include context showing you've confirmed the finding.

4.3 Known not-vulnerabilities

To save you time, these are known not-vulnerabilities in our context:

• Missing security headers where our CDN / framework sets them elsewhere in the response chain (check the final response).
• Lack of Certificate Transparency observation on subdomains — we rely on major CAs and CT is operational via those.
• Cookies without HttpOnly or Secure flags that are intentionally client-readable (for example, functional cookies for language / currency state).
• Clickjacking on pages with no sensitive state change.
• SPF / DKIM / DMARC record questions on mail we do not send from (*.reservly.io subdomains that do not send email).
• Vulnerabilities in third-party services listed in § 4.2.
• Information disclosure of non-sensitive data (version numbers, software stack details).

If you think you've found a real issue in any of these categories despite the above, report it — we're describing defaults, not absolutes.

5. What's not OK

In addition to § 4.2 out-of-scope, please do not:

• Access, modify, or delete another user's data beyond a minimal demonstration that a vulnerability exists. If you can read a single record to demonstrate, stop there and report — don't dump a table.
• Degrade service for other users — no actual DoS, no sustained high-volume probing, no automated brute force.
• Social-engineer Reservly employees, Businesses, or end users. Phishing our staff or customers is out of scope and may cross a legal line.
• Attack physical infrastructure — our sub-processors host the stack; their physical security is their responsibility.
• Exfiltrate credentials, keys, or secrets beyond what's needed to prove the vulnerability.
• Violate privacy law. Good-faith research is protected by § 2; privacy-law violations are not.

6. Resolution timeline

These are targets, not commitments — complex issues may take longer. We will update you.

7. Acknowledgement and reward

7.1 Public acknowledgement

With your consent, we publicly acknowledge validated reports on a Hall of Thanks that will live at reservly.io/security/thanks once we have our first entries. Acknowledgements include your name or handle, the date of the report, and (where you consent) a one-line description of the class of finding.

If you prefer to remain anonymous, just say so in your report.

7.2 Reward

At launch, we do not operate a cash bug-bounty programme. We are a small, pre-revenue company and cannot responsibly commit to payouts. When we have revenue to support it, we will announce a formal bounty programme here.

In the meantime, we offer:

• Public acknowledgement (with your consent).
• Reservly swag, once we have any to send.
• A written letter of thanks that you can include in a professional portfolio.
• A lifetime free-tier Reservly account (for you or a non-profit you name) for Critical and High-severity findings at our discretion.

7.3 Duplicate reports

The first good-faith report of a particular issue gets credit. Subsequent reports of the same issue are not separately credited; we may still acknowledge the researcher informally.

8. Disclosure timing

We prefer coordinated disclosure. Hold public discussion of the vulnerability until either (a) we have shipped a fix and you have confirmed it resolves the issue, or (b) 90 days have passed since your report with no adequate response from us, or (c) we agree to a different timeline.

When we disclose publicly (security advisories, release notes, blog posts), we describe the issue at an appropriate level of detail — enough to help other operators and researchers learn, not enough to arm bad actors against users who have not yet updated.

9. What this programme is not

• Not a penetration test or audit. If you need a formal pen-test report for your own compliance (for example, a Business doing its own SOC 2), ask us for a security whitepaper and our most recent external-audit summary once available.
• Not a support channel. If your report is actually a support question ("I can't log in"), please use support@reservly.io instead. security@reservly.io is for security-relevant reports.
• Not legal advice. This page describes Reservly's commitments and expectations. It is not legal advice and does not create rights beyond what it explicitly states.

10. Other security questions

• Enterprise security inquiries (SOC 2 report, pen-test summaries, TOMs documentation): email support@reservly.io with subject "Security whitepaper".
• Data-breach notifications we've sent: if you've received a notification from us and want to verify it's genuine, reply to the email or contact security@reservly.io.
• Account compromise (you believe your Reservly account has been compromised): email security@reservly.io with subject "Account compromise" and we will treat it as priority.
• Phishing reports (you've received a suspicious email claiming to be from Reservly): forward the full email with headers to security@reservly.io.

11. Technical and Organisational Measures

This section summarises the technical and organisational measures Reservly maintains to protect the personal data it processes. It is the document referenced in Reservly's Data Processing Agreement (DPA Section 5.2 and Annex II). Customers requiring a more detailed description for their own compliance programme may request Reservly's security whitepaper by emailing support@reservly.io with subject line "Security whitepaper".

Last reviewed: April 26, 2026

11.1 Encryption

11.2 Access control

• Row-Level Security (RLS): PostgreSQL RLS enforced on every database table; all queries are automatically scoped to the authenticated business's tenant. RLS policies are part of the schema migrations and tested in the Playwright end-to-end suite.
• Authentication: Supabase Auth with scrypt-hashed passwords; per-user API keys with configurable expiry; TOTP-based MFA available for all accounts.
• Internal admin access: Limited to named Reservly personnel; internal administrative actions are logged in Supabase audit logs.
• Least privilege: Application code uses scoped database roles; no single service account has unrestricted database access.

11.3 Application security

• TypeScript strict mode: Zero type errors required; enforced in CI on every pull request.
• Continuous integration gates: Build, type check, ESLint, and Playwright end-to-end tests run on every code change before merge.
• Code review: All changes to the main branch require at least one reviewer approval.
• Dependency scanning: Automated dependency vulnerability scanning via npm audit in the CI pipeline.
• Server Actions only: All database mutations flow through src/lib/actions/ server actions; client components cannot call the database directly. Every server action begins with getBusinessAccess() to assert the caller's identity and scope.

11.4 Monitoring and incident response

• Error monitoring: Sentry (EU region, ingest.de.sentry.io; 90-day retention; PII scrubbing applied before ingest; 10% production transaction sampling).
• Access logs: Vercel edge logs and Supabase auth logs retained per each provider's standard retention period.
• Incident response: Documented incident response plan with 72-hour supervisory-authority notification SLA (GDPR Article 33 — this is the Controller's obligation) and without-undue-delay Controller-notification SLA (Reservly's obligation as Processor under Article 33(2)). Security reports received at security@reservly.io are triaged within the timelines in § 6 of this page.
• Penetration testing: External penetration test engagement planned within 12 months of general availability. Results will be made available to customers under DPA Section 11.2 when issued.
• Tabletop exercises: Annual incident-response tabletop exercise planned; first exercise to be conducted within 12 months of general availability.

11.5 Resilience

• Database backups: Daily encrypted backups, 30-day rolling retention; point-in-time recovery available for 7 days (Supabase Pro).
• Disaster recovery: Documented recovery plan; relies on Supabase's managed infrastructure for database restoration. Recovery time objective (RTO) and recovery point objective (RPO) are aligned with Supabase Pro SLAs.

11.6 Organisational measures

• Personnel: Personnel with access to Customer Personal Data are subject to confidentiality obligations and data-handling procedures aligned with GDPR Article 32.
• Vendor management: All sub-processors are under DPA or equivalent contracts. The sub-processor list is published at reservly.io/legal/subprocessors.
• SOC 2 Type II: Reservly is pursuing SOC 2 Type II attestation. No report has been issued yet; status will be updated on this page when the first report is available.

11.7 What this document is not

This section is a summary for DPA compliance purposes. It is not a penetration test report, a SOC 2 report, an ISMS certification, or a complete security architecture description. For questions about specific controls or to request additional documentation, contact support@reservly.io with subject line "Security whitepaper".

12. Changes

We will update this policy as our programme matures — particularly when we add a formal bug-bounty component or publish our first penetration-test results. The Last updated date at the top reflects the latest revision.

13. Contact

Reservly — Security c/o Northwestern Registered Agent Services 30 N Gould St Ste R Sheridan, WY 82801 United States

Email: security@reservly.io PGP request: security@reservly.io (subject PGP key request) Non-security support: support@reservly.io

This Security & Responsible Disclosure policy works together with the Reservly Terms of Service, Privacy Policy, Acceptable Use Policy, and API Terms of Service.