Reservly API Terms of Service

Last updated: April 26, 2026

The short version

• Every tier gets real API access — REST + MCP, not a watered-down entry tier. Solo has it; Team and Pro have more of it.
• Rate limits (token bucket, enforced via HTTP 429):
  • Solo: 5 req/sec sustained, 25-token burst, 50,000 req/day
  • Team: 25 req/sec sustained, 125-token burst, 250,000 req/day
  • Pro: 100 req/sec sustained, 500-token burst, 2,000,000 req/day
• 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 API access. What differs is capacity, not availability.

These limits are per Reservly account, not per API key. Multiple keys on the same account share the same bucket.

2.1 How the token bucket works

Your bucket is initialized to its maximum capacity (25 / 125 / 500 tokens per tier). Every API request spends one token. Tokens refill at your sustained rate (5 / 25 / 100 per second). If you send a burst of requests, you can empty the bucket faster than it refills — that's fine, that's what the burst capacity is for. When the bucket hits zero, subsequent requests return HTTP 429 Too Many Requests until a token becomes available.

Every API response includes these headers so you can pace your client:

• X-RateLimit-Limit — sustained rate for your tier.
• X-RateLimit-Remaining — tokens currently available.
• X-RateLimit-Reset — unix timestamp when the bucket will next have at least one token.
• Retry-After — on 429 responses, the number of seconds to wait.

2.2 Daily cap

The daily cap is a belt-and-braces check that prevents a single account from overwhelming the platform even while staying within its per-second rate. Reaching the daily cap returns HTTP 429 until midnight UTC.

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 tokens

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).
• An optional expiry (none, or a specific date).
• A created-at timestamp.

Keys are shown in full exactly once, at creation time. After that, only the last four characters are visible in the dashboard. If you lose a key, generate a new one; we cannot recover it.

4.2 MCP tokens

The MCP server authenticates with the same API keys. Use the Authorization: Bearer <key> header when configuring your MCP client.

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 token-bucket 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 your tier's rate limit. 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, PayPal order IDs, and booking payment-status fields. You must not:

• Misuse Stripe or PayPal 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 versioned. Breaking changes are made only in a new major version. Minor, additive changes (new endpoints, new optional fields, new optional parameters) may ship without version bump.

7.2 Deprecation

When a major API version is deprecated:

• We will publish the deprecation on this page and in the /docs/api developer documentation.
• We will send a deprecation notice to active API consumers at the account's primary email.
• We will support the deprecated version for at least 12 months from the deprecation announcement, 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 versioning

Webhook payloads include a version field. If we need to change payload shape, we will add a new version and continue emitting the old one for at least 6 months.

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.