API access, rate limits, data handling, security.
At a glance
These API Terms of Service ("API Terms") govern your use of the Dyva API and developer tools. They are part of the Dyva Terms of Service. Where these API Terms conflict with the main Terms on API-specific matters, these API Terms take priority.
The Dyva API gives you programmatic access to our platform — conversations, characters, voice, knowledge bases, and more. With that access comes responsibility. Use it well, build something great, and we will keep the lights on.
1.1 License Grant. Dyva grants you a limited, non-exclusive, non-transferable, revocable license to access and use the API for developing, testing, and operating applications that integrate with Dyva ("Client Applications"). This license is conditioned on your compliance with these API Terms.
1.2 Account Requirements. API access is a Pro plan ($24.99/month) or above entitlement, and so are the Discord, Telegram, and Slack integrations. Your plan determines your limits and which capabilities you may use. Current prices are on the pricing page and current limits in the rate limits documentation; where a figure in either differs from a figure here, the pricing page and the documentation are the current one.
1.3 API Keys. You authenticate via API keys generated from your Dyva dashboard. Treat them like passwords:
You are responsible for all activity under your API keys. If someone else uses your key, that is on you.
1.4 SDKs and Libraries. There is no official Dyva SDK today — the API is plain HTTP, documented in Build. If we publish client libraries later they will carry their own open-source licenses and remain subject to these API Terms when used to reach the Dyva API.
2.1 What You Can Build. You can use the API to:
2.2 What's Banned. Do not:
3.1 Limits. Limits are applied per account and differ by endpoint class — authentication, messaging, media generation, and money-path endpoints each have their own window, and some are stricter than your plan's headline figure. The current numbers are documented at /build/rate-limits. Do not hardcode them; they change.
3.2 Response Headers. Some endpoints return rate-limit headers, and where they do the meanings are:
X-RateLimit-Limit — your maximum requests for the current windowX-RateLimit-Remaining — requests remaining in the current windowX-RateLimit-Reset — Unix timestamp when the window resetsThese headers are not present on every response, and Retry-After is only set on a few endpoints. Do not build a client that depends on either being there — treat their absence as normal and back off on the status code.
3.3 Handling 429s. When you hit a limit you get an HTTP 429 Too Many Requests. Implement exponential backoff, and honour Retry-After when it is present. Persistent or deliberate circumvention of a limit will get your access revoked.
3.4 Limit Changes. We may adjust rate limits at any time. For reductions to existing tier limits, we will give at least 14 days notice so you have time to adapt.
4.1 Your Data Through the API. Data you send through the API is handled per our Privacy Policy. API conversation data follows the same retention and handling rules as data from the web interface.
4.2 No Training on Your API Data. We do not use data submitted through the API to train or fine-tune AI models. Your prompts, conversations, and knowledge base content remain yours. The account-level setting that permits training on a user's own content is off unless that user turns it on, and it is never enabled on anyone's behalf. If we ever propose to change this, you will be notified and able to object before any change takes effect.
4.3 Model Providers. Serving a request means sending its content to a third-party model, speech, or media provider. Those providers are named — with their processing purpose and country — in Section 6 of the Data Processing Agreement. Not all of them process in the United States. If that matters to your end users, read that list before you integrate, not after.
4.4 Your Responsibilities. If your application processes personal data through the Dyva API, you must:
4.5 AI Disclosure Is Yours to Add. API responses and embedded characters do not carry an automatic AI-identity marker. If your users could reasonably take a character for a person, saying otherwise is your obligation, in your surface — we do not do it for you, and you should not assume the response text will. This is a limitation of the product today, not a licence to leave it unsaid.
4.6 Data Processing Agreement. If you process personal data of individuals in the EEA, UK, or Switzerland through the API, our Data Processing Agreement applies automatically. It names every model, speech, and media provider that can receive your end users' content.
Security is not optional. If you use our API, you agree to these baseline requirements:
We reserve the right to suspend API access immediately if we detect a security vulnerability in your integration that poses a risk to our platform or other users.
6.1 Uptime Target. We target 99.9% uptime for the API but do not guarantee it. The API is provided "as is" and "as available." We will communicate scheduled maintenance at least 48 hours in advance when possible.
6.2 Incident Communication. There is no public status page today. Incidents and planned maintenance are communicated by email to the address on your account and, where the impact is user-visible, in the product. Do not build a health check that scrapes a status URL — poll an API endpoint you actually depend on.
6.3 Support. API support is available through: (a) developer documentation in Build; (b) email at [email protected]; and (c) community channels. Higher plans are answered first. Any first-response time stated elsewhere on the site is a target we work to, not a contractual commitment — 6.4 governs.
6.4 No Default SLA. Unless you have a separate Enterprise Agreement with specific SLA commitments, no service level agreement applies. We are not liable for downtime, latency spikes, or temporary unavailability. Build your applications with appropriate error handling and fallbacks.
7.1 Versioning. The API is versioned (currently v1). We maintain backward compatibility within a major version wherever commercially reasonable. Non-breaking additions (new endpoints, new optional fields) can happen without a version bump.
7.2 Breaking Changes. When we need to introduce breaking changes, we will: (a) give at least 30 days notice via email and developer changelog; (b) release breaking changes under a new API version when possible; and (c) keep the previous version running for at least 90 days after the new version launches.
7.3 Deprecation Policy. We may deprecate specific endpoints, features, or parameters. Deprecation is announced in the documentation and by email; the API does not currently emit Deprecation or Sunset response headers, so do not build your migration trigger on them. Deprecated features keep working for at least 60 days from the announcement. Use that time to migrate.
7.4 Migration Support. For major version transitions, we provide migration guides, changelogs, and SDK updates. We want your integrations to keep working — breaking things is not the goal.
8.1 Sparks. API usage draws on the same allowance as the rest of the product: Sparks. Your plan sets a daily allowance that resets at UTC midnight, and a separate purchased balance from top-up packs sits alongside it. Different actions cost different amounts — voice costs more than text. Your live allowance, usage, and reset time are shown in the product; the plan figures are on the pricing page. Read your own balance from the product rather than assuming a published figure.
8.2 Running Out. When the allowance is spent, metered calls are refused until the daily reset or until you buy a top-up pack — a one-time purchase, not a recurring charge. There is no automatic overage billing: we do not charge you past your plan without you choosing to buy. There is also no spend-cap control and no usage-threshold warning today, so a client that must not stop should watch its own consumption.
8.3 Enterprise Pricing. For high-volume or custom requirements, contact us at [email protected]. Enterprise agreements can include custom rate limits, dedicated infrastructure, SLAs, and volume pricing.
8.4 Price Changes. We may change API pricing with at least 30 days notice. Price changes do not affect the current billing period.
9.1 Dyva's IP. The API, its documentation, SDKs, and all associated intellectual property belong to Dyva. These terms do not grant you rights to our trademarks, logos, or branding. Do not use Dyva marks in ways that imply endorsement or official affiliation without our written consent.
9.2 Your Applications. You own your Client Applications. We claim no ownership over what you build with the API. Your code, your designs, your users — all yours.
9.3 API Output Ownership. Content generated through the API (AI responses, generated images, synthesized voice) is owned by you to the extent permitted by applicable law, subject to our Terms of Service and the terms of the underlying model providers listed in the Data Processing Agreement. You are responsible for how you use and distribute generated content.
9.4 Attribution. You are not required to display Dyva attribution in your applications, but we appreciate it. If you do reference Dyva, follow our brand guidelines.
9.5 Feedback. If you share suggestions, feature requests, or bug reports about the API, you grant Dyva a perpetual, royalty-free license to use that feedback without obligation to you. We value developer input — it makes the platform better for everyone.
10.1 By You. You can stop using the API at any time. Revoke your API keys from the dashboard. No notice required, no hard feelings.
10.2 By Dyva. We may suspend or terminate your API access immediately if: (a) you breach these API Terms, the Terms of Service, or any Dyva policy; (b) your usage poses a security risk to our platform or other users; (c) we need to comply with a legal obligation; or (d) your account is terminated for any reason.
10.3 After Termination. When your API access ends: (a) your API license terminates immediately; (b) stop all API usage; (c) delete any cached Dyva data within 30 days, unless law requires you to keep it; (d) your end users lose access to Dyva-powered features in your application. Plan accordingly.
10.4 Survival. Sections 4 (Data and Privacy), 5 (Security), 8 (Fees — for outstanding balances), 9 (IP), and this Section 10 survive termination.
THE API IS PROVIDED "AS IS" AND "AS AVAILABLE" WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED. TO THE MAXIMUM EXTENT PERMITTED BY LAW, DYVA DISCLAIMS ALL WARRANTIES, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AND ANY WARRANTIES ARISING FROM COURSE OF DEALING OR USAGE OF TRADE.
DYVA'S TOTAL LIABILITY UNDER THESE API TERMS IS CAPPED AT THE FEES YOU PAID FOR API ACCESS IN THE 12 MONTHS PRECEDING THE CLAIM. DYVA IS NOT LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES, INCLUDING LOST PROFITS, LOST DATA, BUSINESS INTERRUPTION, OR COST OF SUBSTITUTE SERVICES.
You acknowledge that: (a) AI-generated outputs may be inaccurate, incomplete, or inappropriate; (b) the API may experience downtime or performance issues; (c) you are responsible for validating API outputs before presenting them to your users. Build defensively.
API and developer questions: [email protected]
Security issues: [email protected]
Legal matters: [email protected]
For API bugs and feature requests, use the developer portal or email [email protected] with your API key prefix (first 8 characters only — never send the full key).