Reservly API Terms of Service

Last updated: July 13, 2026

The short version

• Every tier gets real API access — REST + MCP, identical capacity on Starter, Team, and Professional. Capacity does not scale with tier.
• Rate limits (fixed-window counters, per API key or per IP — not per account, not tiered):
  • 100 requests/minute per API key on POST /book, the only endpoint that authenticates with your rsvly_ key.
  • 10 requests/minute per IP on the public booking endpoint, enforced on every caller regardless of API key.
  • 60 requests/minute per IP on each other public read endpoint (events, info, rentals, services, slots, staff, rental availability) and on the MCP server.
  • 30 requests/minute per IP on the exchange-rates endpoint.
• AI receptionists are welcome. Use Reservly's API for voice AI, chat AI, automation, anything legitimate.
• Webhooks first. If you need event awareness, use our webhooks instead of polling.
• No data scraping, no circumvention of rate limits, no reselling capacity. Details in §§ 5-6.

These API Terms form part of the Reservly Terms of Service and are incorporated by reference. In the event of conflict between these API Terms and the general ToS for matters specific to API use, these API Terms control.

1. Who these API Terms apply to

These API Terms apply to any use of Reservly's REST API, Model Context Protocol (MCP) server, outbound webhooks, and any other machine-to-machine interface we expose, collectively the "API". You agree to these API Terms when:

• You generate an API key from the Reservly dashboard.
• You connect Reservly to a third-party tool (Zapier, Make, n8n, Voiceflow, Vapi, Retell AI, Synthflow, Bland AI, ChatGPT Custom GPT, Claude, ManyChat, WhatsApp Business, Telegram Bot, custom code, etc.).
• You subscribe to outbound webhooks.
• Your MCP client connects to Reservly's MCP endpoint.

1A. Licence Grant

Subject to your compliance with these API Terms and the Reservly Terms of Service, Reservly grants you a limited, non-exclusive, non-transferable, revocable licence to access and use the API solely for the purposes described in § 3 (Fair use) and solely in connection with your own Reservly-connected business or application.

1A.1 Restrictions

This licence does not include the right to:

• Sub-license, resell, or commercially redistribute API access or API responses to third parties who are not end users of your own product (for partner and reseller arrangements, see § 5.5 and contact support@reservly.io).
• Access or manage the account data of another business without that business's explicit authorisation. You may only use the API to manage the Reservly account(s) you operate or are expressly authorised to manage by the account owner.
• Build a competing reservation platform using Reservly's API infrastructure, data, or responses as the primary technical or data layer.
• Reverse-engineer, decompile, or disassemble the API or attempt to derive Reservly's proprietary algorithms, slot-calculation logic, or pricing models from API responses.
• Use the API in any way not reasonably contemplated by these API Terms.

1A.2 Ownership

Nothing in this licence transfers any ownership interest in the API, Reservly's software, or Reservly's intellectual property to you. All rights not expressly granted here are reserved by Reservly.

2. API access tiers

All Reservly subscription tiers include identical API access — Starter, Team, and Professional are rate-limited exactly the same way. Your subscription tier is never read by rate-limiting logic.

These limits apply per API key or per IP address as shown above — never per account, and never differentiated by subscription tier. If a single account uses multiple API keys, each key gets its own independent 100/min budget.

2.1 How the limit works

Each limit is a fixed-window counter: requests are counted within a rolling one-minute window per key or IP, and the counter resets when the window closes. This is not a token-bucket algorithm — there is no burst allowance beyond the stated per-minute number. When the limit is exceeded, public and MCP endpoints return HTTP 429 Too Many Requests with a Retry-After: 60 header. The POST /book per-API-key limit currently returns HTTP 401 with an explanatory error message rather than 429.

Reservly does not currently return X-RateLimit-Limit, X-RateLimit-Remaining, or X-RateLimit-Reset headers on any response. Pace your client using the fixed per-minute numbers above and the Retry-After header on 429 responses.

2.2 No daily cap

There is no daily request cap and no midnight-UTC reset. All limits above are per-minute only.

2.3 Webhooks are not rate-limited as requests

Outbound webhook deliveries that Reservly sends to you do not count against your inbound request budget. Each business has a separate webhook delivery log visible in the dashboard.

3. Fair use

Reservly's API is intended to support a wide variety of legitimate integrations, including:

• Voice AI receptionists (Vapi, Retell AI, Voiceflow, Synthflow, Bland AI, and similar platforms) that make and receive booking calls on behalf of a business.
• Text / chat AI assistants (ChatGPT Custom GPTs, Claude Projects, custom LLM agents) that handle booking conversations.
• Automation platforms (Zapier, Make, n8n) that wire Reservly into other business software.
• Custom internal dashboards, analytics tools, or back-office integrations built by the business or its contractors.
• Third-party booking systems that synchronise with Reservly.
• Messaging-platform integrations (ManyChat, WhatsApp Business, Telegram Bot) for booking via chat.
• Voice or messaging-based booking flows of any kind.

We welcome these use cases. Reservly was designed to be AI-native. If you have a legitimate integration that, in steady state, would stay within the per-tier rate above, you are within our fair-use policy. If you expect to need a higher ceiling, email support@reservly.io with subject line "API capacity" and describe what you're building; we elevate capacity case-by-case at no additional cost when the use case is reasonable.

4. API keys and MCP access

4.1 Generating keys

Create API keys from Settings → Integrations → API Keys in the dashboard. Each key has:

• A human-readable name (your choice).
• A scope (read, write, or all).
• A created-at timestamp and a last-used timestamp.

Keys do not currently expire automatically — there is no expiry date field. Revoke a key manually from the same page if you no longer need it (see § 6A.3).

Keys are shown in full exactly once, at creation time. After that, only the key's prefix (rsvly_ plus the first few characters) is visible in the dashboard — not the full key and not a trailing suffix. If you lose a key, generate a new one; we cannot recover it.

4.2 MCP access

The MCP server does not currently authenticate with your rsvly_ API key. Both the stdio and HTTP transports are gated only by knowing a business's public slug, and read traffic is rate-limited by caller IP (§ 2). The one MCP tool capable of writing data (creating a booking) authenticates to Reservly's own internal booking endpoint using Reservly's internal service credentials — not your API key — so no per-developer key check happens on that path either.

In practice, this means MCP access control today is equivalent to knowing a business's booking-page slug, not possession of a specific developer's key. Per-developer API-key authentication for MCP is on our roadmap; until it ships, do not rely on MCP access being restricted to holders of a particular key, and do not treat a business's slug as a secret.

4.3 Your obligations for keys

You must:

• Keep keys secret. Do not commit them to public repositories, paste them into public channels, or share them in support tickets we did not request.
• Revoke keys immediately if you believe one has been compromised.
• Scope keys to the minimum necessary. A key used by a read-only analytics job should be read, not all.
• Notify us at security@reservly.io if you detect unauthorised API use so we can help investigate.

4.4 Key leakage response

If we detect that your key has appeared in a public source (a leaked repository, a paste site, a log in a third-party service), we may revoke the key immediately without notice and require you to generate a new one. We will notify you of the revocation and the source of the detection.

4A. Attribution and Branding

4A.1 Attribution requirement

When your integration surfaces Reservly booking functionality to end users — for example, a voice AI receptionist that books appointments through Reservly's API, or a web interface that embeds Reservly availability data — you must include a reasonably prominent disclosure that the booking system is powered by Reservly. Acceptable forms include:

• "Booking powered by Reservly"
• "Scheduling by Reservly"
• Any equivalent disclosure that makes clear to end users that Reservly is the underlying booking platform.

This requirement exists so that end users can contact Reservly if they have questions about data handling, accessibility, or their booking record. It also helps Reservly provide better support for users who contact us directly.

Waiver: If your integration context makes attribution technically or contractually impractical (for example, a purely server-to-server integration with no end-user interface), contact support@reservly.io with subject line "Attribution waiver" to discuss alternatives.

4A.2 Use of Reservly marks

Use of the "Reservly" name, logo, or trademarks is governed by Reservly's trademark policy (see Terms of Service § 15.5). You may refer to Reservly by name in attribution as described in § 4A.1. You may not use the Reservly name or logo in a way that implies endorsement, partnership, or affiliation beyond what these API Terms grant.

5. Prohibited uses

The Acceptable Use Policy § 5 applies to API use in full. Specifically for the API:

5.1 No sustained attempts at maximum rate

The rate limits in § 2 are ceilings, not targets. Sustained use at the maximum rate without prior coordination (even if you stay within the limits) may be treated as abuse; normal production traffic has peaks and troughs.

5.2 No scraping

You may not use the API to extract data at scale for purposes unrelated to operating your own business's bookings. "At scale" is judged by reasonable standards and intent, not by a strict threshold. Legitimate uses — exporting your own business's data for backup, feeding a dashboard, or synchronising to your own system of record — are fine. Systematically reading every endpoint to build a copy of Reservly is not.

5.3 No competitive intelligence gathering

You may not use the API to scrape or enumerate public booking pages, service offerings, pricing rules, or availability windows of businesses that are not your own.

5.4 No circumventing rate limits

You may not use multiple accounts, multiple businesses, or multi-tenant patterns to effectively exceed the limits in § 2. If your legitimate use case requires higher rates, email us under § 3.

5.5 No reselling capacity

You may not resell, sublicense, or otherwise commercialise Reservly's API capacity as a service to third parties who are not your own end users or your own business's consultants. Building a product that sells Reservly bookings to other businesses requires a separate partner conversation; email support@reservly.io with subject line "Partner inquiry".

5.6 No polling instead of webhooks

If you need to know about booking events (created, confirmed, cancelled, rescheduled, paid, refunded), use webhooks, not polling. Polling booking endpoints faster than once per second per business is abusive regardless of whether you stay under the bucket limit — webhooks exist precisely so you don't need to poll.

5.7 No fake bookings or automated account creation

Using the API to create fake bookings (to test production without intent, to manipulate your own tier metrics, to spam a competitor, or for any other purpose that results in synthetic load) is a material breach of these Terms and of the AUP.

5.8 No denial-of-service patterns

You may not use the API in any manner that degrades service for other customers, including but not limited to sending high volumes of malformed requests, holding idle connections open, or triggering expensive operations in loops.

5.9 No misuse of payment metadata

Reservly's API may return or accept payment-related metadata such as Stripe charge IDs and booking payment-status fields. You must not:

• Misuse Stripe reference identifiers for any purpose other than reconciling bookings within your own system.
• Correlate payment identifiers across bookings for the purpose of building profiles of end users or profiling payment behaviour.
• Expose transaction identifiers, charge IDs, or payment-processor references in any client-facing interface or third-party analytics pipeline.
• Initiate, attempt, or trigger refund operations through the API without explicit authorisation from the Business whose booking is being refunded. Refund operations must only be triggered by the account holder or an operator expressly delegated by the account holder.

5A. Data Use Restrictions

5A.1 Personal data restrictions

When you access the API, you may receive personal data relating to Businesses, their staff, or their end customers (names, contact details, booking records). This personal data is subject to the Privacy Policy. You must:

• Process personal data received via the API only for the purpose of operating your authorised integration — not for profiling, advertising, model training, or any other secondary purpose.
• Not store personal data received via the API beyond the period necessary for your integration's stated purpose, and not longer than permitted by applicable data protection law.
• Not combine personal data from Reservly's API with personal data from other sources in a way that would create profiles of individuals without an appropriate legal basis.
• Where your integration operates in the EU or processes EU personal data, ensure that any transfer of that data outside the EEA is covered by an appropriate transfer mechanism.

5A.2 Aggregate data allowance

You may use aggregated, de-identified statistics derived from your own integration's API usage (for example, your own booking volume or conversion rates) for internal analytics, provided no individual person or individual Business is identifiable.

5A.3 Data residency obligation

If your integration is subject to data residency requirements under applicable law (for example, a data localisation requirement under GDPR, LGPD, or a national law), you are responsible for ensuring that your processing of API data complies with those requirements. Reservly does not guarantee that API responses are optimised for any specific data-residency requirement; contact support@reservly.io if you have data-residency constraints that require special handling.

6. Abuse enforcement ladder

We enforce API abuse on a ladder, matching the AUP enforcement ladder:

1. Notice. We contact you via the account's primary email describing the pattern we observed. You have a reasonable opportunity (typically 72 hours) to correct it.
2. Feature suspension. If the pattern persists, or for a more serious first infraction, we suspend the specific affected functionality — API keys, specific endpoints, or webhook delivery — while we investigate and you correct the issue.
3. Account suspension. For persistent or serious abuse, we suspend the account.
4. Termination. For wilful, repeated, or severe abuse — including automated account creation, fake-booking campaigns, DoS-pattern usage, or clear commercial reselling without authorisation — we terminate, with no refund.

At any step, we may revoke compromised or misused API keys immediately without waiting for the ladder.

6A. API Key Revocation

6A.1 Revocation by Reservly

Reservly may revoke an API key at any time. We distinguish two types of revocation:

• Security-triggered revocation (immediate, without prior notice): If Reservly detects or suspects that a key has been compromised, leaked, or is being used to conduct or facilitate a security incident, we will revoke the key immediately. We will notify the account's primary email address of the revocation and the reason.
• Policy-triggered revocation (with notice where practicable): If Reservly revokes a key because of a policy violation or after an enforcement-ladder action (§ 6), we will notify the account owner. In cases of wilful, severe, or repeated violations, revocation may be immediate.

6A.2 Notice of revocation

Upon revocation, affected API requests will receive HTTP 401 Unauthorized responses. We will send a notification to the account's primary email address explaining the revocation reason and, where applicable, the remediation steps available to restore access.

6A.3 Revocation by the developer

You may revoke any of your own API keys at any time from Settings → Integrations → API Keys in the dashboard. Revocation takes effect immediately. You are responsible for any API usage that occurs before you revoke a key you believe has been compromised. If you believe a key was used without your authorisation, contact security@reservly.io immediately.

7. Changes to the API and these Terms

7.1 API versioning

Reservly's REST API is not currently versioned — there is no /v1/-style path segment, version header, or version field in responses. We aim to make additive, backward-compatible changes (new endpoints, new optional fields) without breaking existing integrations.

7.2 Breaking changes

If a breaking change becomes necessary:

• We will publish the change on this page and in the /docs/api developer documentation, with a migration guide.
• We will send a notice to active API consumers at the account's primary email.
• We will provide at least 12 months' notice before the old behaviour stops working, except in security-critical cases where a shorter timeline may be required.

7.3 MCP server evolution

The MCP server follows the Model Context Protocol's published versioning. We support MCP clients built against the currently-stable MCP release and the immediately prior one.

7.4 Webhook payload changes

Webhook payloads do not currently include a version field. If we need to change payload shape in a breaking way, we will announce the change at least 30 days in advance via the notice described in § 7.5 and the developer documentation changelog, and where practical will maintain the old shape alongside the new one for a transition period.

7.5 Changes to these API Terms

We will update these API Terms as the API evolves. Notice is as described in Terms of Service § 12 — at least 30 days before material changes take effect.

8. Service availability

Reservly targets high availability for the API, but we do not guarantee specific uptime as a matter of contract under these API Terms. Pro-tier subscribers will receive separate uptime targets when the formal Service Level Agreement ships; until then, our published Security page describes our operational posture.

9. Developer documentation

Current developer documentation — endpoint reference, authentication, webhook payload schemas, MCP capability list, integration guides (Zapier, Make, n8n, Voiceflow, Vapi, ManyChat, WhatsApp, Telegram, ChatGPT Custom GPT, and others) — lives at reservly.io/docs.

10. No warranty beyond the Terms of Service

The API is part of the Service. The warranty disclaimers and limitation of liability in Terms of Service §§ 17-18 apply to the API in full. Nothing in these API Terms creates warranties or obligations beyond what the ToS provides.

10A. API Consumer Indemnification

You agree to defend, indemnify, and hold harmless Reservly LLC, its officers, directors, employees, and agents from and against any claims, damages, losses, liabilities, costs, and expenses (including reasonable legal fees) arising out of or in connection with:

1. Breach of these API Terms — any violation of the terms, restrictions, or obligations in this document, including unauthorised use of API keys or misuse of returned data.
2. Integration defects — bugs, errors, or security vulnerabilities in your integration that cause loss or damage to end users, Businesses, or Reservly.
3. Data misuse — your use of personal data received via the API in a manner that violates the Privacy Policy, applicable data protection laws (GDPR, CCPA, LGPD, POPIA, or equivalent), or the restrictions in § 5A.
4. IP infringement — your integration's infringement of any intellectual property rights of Reservly or third parties (for example, reproducing Reservly's proprietary slot-calculation output in a competing service).

This indemnification obligation applies regardless of whether you acted with intent. Reservly will promptly notify you of any claim subject to this section and will not settle any claim without giving you a reasonable opportunity to participate.

11. Contact

Email: support@reservly.io Subject line for capacity requests: API capacity Subject line for partner / reseller inquiries: Partner inquiry Subject line for security reports about the API: security@reservly.io (see Responsible Disclosure) Subject line for deprecation-notice mailing-list subscription: API deprecation list

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

These API Terms are part of and incorporated into the Reservly Terms of Service. The Acceptable Use Policy and Privacy Policy also apply.