API & Machine Access Terms (Product-Specific Terms)

Operator: Ysaere, Inc. (Delaware; foreign-qualified in Florida), operator of Ysaere. Version: 0.2. Product-Specific Terms under the Terms of Service and (where executed) the Master Subscription Agreement. They govern all programmatic access to the Services: the REST API, webhooks, the MCP server and MCP starter keys, SDKs/CLIs, and any agent, LLM, or automated system that invokes the Services ("Machine Callers").

1. Acceptance — including acceptance by machine use

1.1 These Terms are accepted by (a) a human accepting the Terms of Service or MSA that incorporates them, (b) creating, provisioning, or using an API key or MCP key, or (c) any programmatic invocation of the Services using a key — whichever occurs first.

1.2 Acceptance-by-use for Machine Callers. A Machine Caller cannot click a checkbox, so: each use of a key constitutes acceptance of the then-current version of these Terms by the Principal (defined below). At key issuance, the version and content-hash of these Terms are recorded against the key (the same byte-exact hash mechanism used for the Terms of Service).

1.3 The Principal. Every key belongs to a subscriber account (human or entity). That subscriber is the "Principal" of every Machine Caller using its keys and is fully responsible for the Machine Caller's compliance with these Terms, the Terms of Service (and MSA if applicable), the Acceptable Use Policy, and the AI Acceptable Use & Output Restrictions — which flow through to Machine Callers and to any downstream recipient of an Output.

2. Keys and credentials

2.1 Keys (prod/test prefixes, MCP starter keys) are credentials, not property. Principal must keep keys confidential, must not embed production keys in client-side or public code, and must rotate a key promptly upon suspected compromise. Ysaere stores only key hashes and cannot recover a lost raw key.

2.2 Ysaere may throttle, suspend, or revoke any key immediately for abuse, compromise, non-payment, or violation of these Terms, with notice where practicable.

2.3 Sandbox/test keys consume no credits and carry no SLA and no warranty; test outputs may be synthetic.

3. Usage limits and fair use

3.1 Rate limits per plan tier apply and are enforced technically; circumvention (key cycling, distributed evasion, header spoofing) is a material breach.

3.2 Credits are debited per run as documented. Machine invocations debit the Principal's balance identically to human-initiated runs. All credit purchases occur exclusively through Ysaere's payment flow.

4. Machine Caller conduct

A Machine Caller (and its Principal) must not:

misrepresent the identity of the calling agent, its operator, or its Principal;
present Outputs as human-generated, or strip AI-generated disclosures or Trust Receipt provenance (AI Acceptable Use §8A applies in full to machine consumption);
use Outputs to train, fine-tune, or distill any model (AI Acceptable Use §8A);
use Outputs for any FCRA/eligibility purpose (AI Acceptable Use §2 — the prohibition binds the Principal even when an intermediary agent, orchestrator, or downstream tool consumed the API);
probe, scan, or test the vulnerability of the Services except under the Responsible Disclosure Policy;
exceed the scope of tools/endpoints granted to the key (least-privilege grants are part of these Terms).

5. Webhooks and callbacks

Principal-supplied webhook and callback URLs must be publicly routable HTTPS endpoints under the Principal's control. Ysaere validates URLs (rejecting internal/private-network targets) and signs webhook payloads (HMAC); the Principal must verify signatures and treat unverified payloads as untrusted.

6. MCP-specific terms

6.1 The MCP server exposes documented tools only; tool grants are least-privilege and default-deny.

6.2 The MCP starter key auto-provisioned at signup is bound to the account that received it; connecting it to an IDE, LLM client, or agent framework makes that account the Principal for everything the connected agent does with it.

6.3 Directory listings (MCP registries, IDE directories) describe capability; they are offers to interact only under these Terms. Where published, machine-readable surfaces may advertise the current version and content hash of these Terms so agent frameworks can discover them programmatically.

6.4 No agent-to-agent payment rail is currently offered. If offered in future, it will carry its own product terms; nothing in these Terms creates an obligation on Ysaere to accept machine-originated payment.

7. Availability; changes

The API surface may evolve; Ysaere will use reasonable efforts to version breaking changes and provide notice via the developer portal/changelog. Any SLA applies only if (and as) stated in an Order Form.

8. Data

API/MCP usage telemetry (endpoint, latency, tokens, key id, tenant) is processed for operations, billing, abuse prevention, and audit under the Privacy Policy and (where executed) the DPA. Machine events are keyed by API key → tenant. DSAR/deletion cascades include API usage data for a deleted tenant.

9. Order of precedence; enforcement; survival

These Terms are Product-Specific Terms under the Terms of Service (and MSA §13.11 order of precedence where an Order Form applies). Violation is a material breach. Sections 1.3, 4, 6.2, 8, and 9 survive termination.

Ysaere, Inc. · compliance@ysaere.com · developers@ysaere.com