Developer & API Terms
Effective date: 1 August 2026 · Version 1.0
These terms govern programmatic access to APERTURESyndicate services operated by APERTURESyndicate OÜ — the public ASAI API, API keys, OAuth clients, and the developer portal. They apply to you if you hold a key, run an OAuth client, or call any of our APIs.
They are product-specific. Under Section 3 of the Terms of Service they sit below the platform-wide documents: where they appear to conflict with the Terms of Service, the Acceptable Use Policy or the Privacy Policy, the platform-level document controls.
We write these documents in good faith and keep them accurate to how the platform actually works. They have not yet been reviewed by qualified Estonian legal counsel.
1. What exists today
Be clear about the surface area before you build on it.
| What | Status |
|---|---|
| ASAI HTTP API — OpenAI-compatible chat completions and a model list | Live and supported |
| Resonance catalogue API — artists, tracks, albums, search and 30-second previews | Live, self-serve key, personal and non-commercial use only |
| OAuth 2.1 sign-in — let your app authenticate APERTURESyndicate users | Live, self-serve for approved developers |
| Developer portal — apply for developer status, manage keys | Live |
| Outbound webhooks | Do not exist |
| Metered or pay-as-you-go API billing | Does not exist |
| Public APIs for other products (chat, datasets, profiles) | Do not exist publicly |
The Resonance catalogue API has its own rules and they are stricter than this document. Full-length audio and lyrics are never exposed, attribution back to Resonance is mandatory, and commercial use, retransmission through another music service and download tools are prohibited outright. Read Resonance Terms of Service, Section 8 before you build on it — on Resonance matters that section controls.
Two kinds of key exist and they are not interchangeable. The key that
authenticates API calls today is the ASAI key, created in ASAI's settings and
beginning with asai_. The developer portal can also issue keys for services
that are not yet public; those do not authenticate the ASAI API and are of no
use until the service they belong to ships. If you are calling
/v1/chat/completions, you want the asai_ key.
2. Eligibility
You need a APERTURESyndicate account, and you must meet the platform minimum age of 16.
Developer status is requested through the developer portal. It is granted essentially on request today — there is no substantive review before you get it. That is a convenience, not a certification: it does not mean we have vetted your application, and it can be revoked (Section 8).
API access requires a paid plan. The Free tier has no API access at all — requests are refused, not throttled. Which plans include it, and what they include, is in the ASAI Product Terms.
3. API keys
- A key is shown to you once, at creation. We store only a hash of it and a short prefix, so we cannot recover it and neither can support. Lost key, new key.
- Keys do not expire. They stay valid until revoked.
- Revoke immediately if a key is exposed — in a commit, a log, a client bundle, a screenshot, a support ticket. Revocation takes effect at once.
- To rotate, create a new key, move your traffic, then revoke the old one. There is no single rotate operation.
- Keys are not scoped. A key can do everything your account's plan allows on the API, so treat one as equivalent to your account for those purposes.
Your key is your responsibility. Keep it server-side. Never embed one in a mobile app, a browser bundle, or anything a user can read. Everything done with your key is treated as done by you, and usage counts against your account's allowance whoever actually made the call.
If you believe a key has been compromised, revoke it and tell us at [email protected] with the subject prefix "SECURITY".
4. The ASAI API
Endpoints.
| Method | Path | What it does |
|---|---|---|
POST | /api/v1/chat/completions | Chat completions, OpenAI-compatible, streaming supported |
GET | /api/v1/models | Lists the models available to you |
Authenticate with Authorization: Bearer asai_.... Session tokens from the web
app are not accepted here. Most OpenAI client libraries work by changing the
base URL and the key.
Models are exposed under our own names, currently three tiers. The underlying third-party models behind those names change for cost, capacity and quality reasons — see Section 6.3 of the ASAI Product Terms. Write your integration against our model names, not against assumptions about what sits behind them.
Compatibility is best-effort. We implement the parts of the OpenAI schema we support — messages, streaming, temperature, token limits, function-style tools. Fields we do not support are ignored rather than rejected. The API is not a drop-in clone and we do not guarantee behavioural parity with anyone else's service.
5. Rate limits and quotas
Two independent limits apply.
Requests. Around 60 requests per minute per key. Over the limit you get
HTTP 429. Back off and retry rather than hammering; parallel keys to multiply
this limit is circumvention (Section 7).
Usage allowance. API calls draw on the same plan allowance as in-app use — they are not a separate pool and they are not billed separately. When the allowance for the period is exhausted, calls are refused until it resets. There is no overage, no top-up and no way to buy more; the plan price is the whole price, and you will never receive a surprise bill from the API. The current figures per plan are shown in the product, and how the allowances work is in Section 2 of the ASAI Product Terms.
If a payment problem puts your subscription into arrears, your allowance is reduced until it is resolved.
We may change limits to protect the service. Where a change materially reduces what a paid plan gives you, Section 14 of the Terms of Service applies — 30 days' notice and a pro-rata refund if you cancel.
6. OAuth — signing users into your app
You can register an OAuth 2.1 client and let APERTURESyndicate users sign in to your application.
- PKCE is mandatory (
S256). The authorisation-code flow is the only flow we support; there is no implicit flow and no password grant. - All clients are treated as public. The token endpoint validates the code challenge, the client identifier and the redirect URI. Do not build a security assumption on the client secret alone.
- Redirect URIs must be registered up front and are matched exactly, except for loopback addresses on native apps, where the port may vary.
- Scopes are limited to
openid,profile,emailandsubscription. There are no others, and a token is clamped to the scopes the client registered. - You never receive the user's handle. The user information endpoint returns a stable subject identifier, and — depending on scope — nickname, avatar, profile URL, email and verification status, and subscription state. The internal handle is deliberately excluded and must not be inferred, requested or stored.
- Signing keys are published at
/.well-known/jwks.json. There is no OpenID Connect discovery document, no token-introspection endpoint and no token revocation endpoint — tokens expire on their own schedule. - There is no self-serve way to edit or delete a client once registered. To change redirect URIs, rotate a secret or retire a client, write to [email protected].
Your obligations as a client. You are the controller of the user data you receive. Tell your users what you collect and why, request only the scopes you need, store tokens securely, honour deletion requests, and do not use our sign-in to build a profile of our users for a purpose they would not expect. Do not present your application as being operated or endorsed by APERTURESyndicate — see Section 8 of the Acceptable Use Policy on impersonation.
7. What you may not do
On top of the Acceptable Use Policy, which applies in full:
- No reselling. You may not resell, sublicense, rent, or provide our API or its output to third parties as a service of your own — including wrapping it in an "AI chat" product, proxying it, or offering access to your key. Building a product that uses the API for your own users is fine; becoming a reseller of our inference is not.
- No credential sharing. One account, one holder. Do not share keys across organisations or distribute them to users.
- No circumvention. Do not create multiple accounts or keys to get around rate limits or allowances, and do not attempt to bypass metering.
- No scraping or bulk extraction of platform content through the API or any other interface.
- No training a competing model on our API output at scale, and no using output to reconstruct or distil the underlying models.
- No unlawful or harmful use, and nothing prohibited by the model providers' own terms, which flow through to you — see AI Output & Limitations, Section 9.
- Do not misrepresent AI output as human-authored in your product, and disclose its artificial nature to your users where the context or the law requires it.
You are responsible for what your application does with our API, including what your own users do through it.
8. Suspension and revocation
We may revoke a key, disable a client, withdraw developer status, or block API access where:
- you breach these terms, the Acceptable Use Policy or the Terms of Service;
- a key is compromised or is being used abusively;
- your usage threatens the stability or security of the platform;
- payment for your plan fails or is reversed; or
- the law or a valid order requires it.
Withdrawing developer status revokes the developer-portal keys issued under it. Where we act against your account, you get a statement of reasons and can ask a person to look again — DSA Notice & Action, Sections 5 and 6.
For anything short of abuse or a legal requirement, we will try to contact you before cutting access off.
9. Availability, changes and deprecation
There is no SLA. We do not promise an uptime percentage on any plan. We are a two-person company; the infrastructure is solid but it is not redundant everywhere. Build retries and graceful degradation into your integration.
We may change the API. For a breaking change to an endpoint you are using, we will give at least 30 days' notice by email to the address on your account. Additive changes — new fields, new models — may ship without notice, so parse responses tolerantly and ignore fields you do not recognise. We do not currently operate a versioned deprecation policy beyond this; if we introduce one, it will be published here.
Beta and preview endpoints may change or disappear without notice.
10. Liability
The API is provided "as is" and "as available". We do not warrant that it will be uninterrupted or error-free, or that AI output obtained through it will be accurate — AI Output & Limitations applies in full to output you receive over the API, including your responsibility to review generated code before running it.
If you are building in the course of a business, you are responsible for claims brought against us arising from your application or your use of the API in breach of these terms. Our liability is limited as set out in Section 15 of the Terms of Service, and nothing here excludes liability that cannot lawfully be excluded.
Contact
| Purpose | Contact |
|---|---|
| API questions, OAuth client changes, developer status | [email protected] |
| Compromised keys and security issues | [email protected] — subject "SECURITY" |
| Billing and plans | [email protected] |
We accept correspondence in English or Estonian.
APERTURESyndicate OÜ Registry code 17384111 · VAT EE102972654 Priisle tee 8, Lasnamäe linnaosa, Tallinn, Harju maakond, 13914, Estonia Company registration details
These terms are governed by the law of Estonia, with the courts of Tallinn having jurisdiction. The English-language version is the controlling version.
Version history
- v1.0 — 2026-08-01 — Initial publication. Written against the API as built: the OpenAI-compatible ASAI endpoints, per-key request limits, plan-based allowances shared with in-app usage, PKCE-only OAuth with a fixed scope set, and an explicit note that there is no SLA, no webhooks and no metered billing.