Files
mintlify__docs/enterprise-contracting.mdx
Ethan Palm 017d7c7377 Fix Vale warnings (#6378)
* fix: reduce Vale false positives via vocab and config updates

- Make English-word vocab entries case-insensitive so sentence-start
  capitalization and normal prose usage stop flagging (agents, rest,
  cursor, setup, endpoints, etc.)
- Add vocab entries for filenames and code identifiers that appear in
  frontmatter and JSX contexts (docs.json, llms.txt, CLAUDE.md, etc.)
- Ignore openapi frontmatter lines, filenames, JSX attributes, email
  addresses, and internal link targets via TokenIgnores
- Skip inline code scope and indented code fences
- Add Headings exceptions for proper nouns (Claude Code, GitHub
  Actions, Route 53, GA4, etc.)
- Disable linting for the all-code vercel-json-generator snippet

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: resolve all Vale warnings and errors across docs

Content fixes:
- Reword sentences using 'will', first person, spaced em dashes,
  'e.g.', Latin abbreviations, and hyphenated adverbs
- Sentence-case headings that started with dotted filenames
- Backtick literal API values instead of bolding them
- Move periods inside quotation marks
- Fix Oxford comma rule misfires by restructuring sentences

False-positive suppression:
- Vale toggles around example user questions, keyboard shortcut keys
  (Cmd+I), UI labels, and code samples in JSX contexts that Vale
  misparses
- Exclude vale toggle comments from the brace Token/BlockIgnores so
  in-document commands actually reach Vale (the greedy brace pattern
  was also silently swallowing large regions; now lazy)
- Vocab entries for code identifiers (internal_id, handleSubmit, etc.)
- Per-file rule disables for component docs with dotted JSX names and
  files where link-target linting ignores in-document toggles

Result: vale --minAlertLevel warning is clean repo-wide; only
suggestion-level items (Passive, Semicolons, Acronyms) remain.
mint broken-links passes.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: correct WordList rule instead of degrading prose

- Restore sentence-start "Email" in advanced-support; the rule now
  only flags hyphenated e-mail/E-mail forms
- Restore the idiom "above all else"; the above->preceding swap now
  exempts "above all"

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: restore deliberate prose flagged by blunt rules

- Restore spatial 'above the navbar' / 'above a page title' in
  custom-scripts; the above->preceding swap now exempts 'above
  the/a/an'
- Restore the '= ...' in the react-components named-export example
  (the ellipsis is inside inline code) with an Ellipses toggle
- Restore SLA phrasing 'will use commercially reasonable efforts'
  with a Will toggle
- Restore the quoted developer question in the GEO guide intro with a
  FirstPerson toggle, matching the file's other example questions

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: remove WordList swaps that flag legitimate English

- Drop tablet->device and firewalls->firewall rules; both words are
  correct in ordinary prose
- Narrow touch->tap to UI-instruction phrasing (touch the/a) so
  'keep in touch' and 'touch devices' stop flagging

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: reposition vale toggles to wrap whole blocks

Toggle comments placed between list items split the lists (restarting
ol numbering in deployments) and comments flush against tables risked
breaking GFM table parsing. Wrap entire lists/tables with blank-line
separation instead. Verified rendering with mint dev: single ol with
two items, tables intact, no comments in visible DOM.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* refactor: prune accept.txt to load-bearing entries

Empirically removed 166 vocab entries (575 -> 409) whose removal
causes no Vale flags across all 908 English pages: dictionary words
that never needed listing (agents, setup, endpoints, webhooks, yaml),
lowercase entries the speller already accepts, and filename entries
made redundant by inline vale toggles.

Kept every case-enforcing entry (API, JSON, GitHub, ...) so casing
policy is unchanged, plus entries that double as capitalization
exceptions for headings (mcp, md, auth, cursor, txt).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Update ai/mintlify-mcp.mdx

* Update api/agent/v2/create-agent-job.mdx

* chore: alphabetize Headings exceptions and accept.txt

Case-insensitive sort, ignoring the (?i) prefix; also drops a
duplicate Scala entry.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix: re-apply OxfordComma rewrite lost in branch merge

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs: resolve Vale suggestions batch 1 (acronyms, semicolons, passive voice)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs: resolve remaining Vale suggestions (passive voice batch 2)

Rewrite ~90 passive constructions to active voice across deploy,
guides, migration-services, and organize docs. Toggle the deliberate
passive examples in the style-and-tone guide ('by zombies' test).
Add axios/lodash vocab entries for a repositioned code example.

vale . is now fully clean: 0 errors, 0 warnings, 0 suggestions.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 17:17:56 -07:00

103 lines
5.5 KiB
Plaintext

---
title: "Enterprise contracting"
description: "How Mintlify approaches enterprise legal review, Master Service Agreement (MSA) negotiations, security questionnaires, and procurement so you know what to expect when buying."
hidden: true
---
A legal issue is almost always first a satisfaction issue. We believe the best legal department is a satisfied customer.
That means we say yes whenever we can, move quickly, and only hold firm on the small number of things that keep the platform working for everyone.
This page explains what those things are—and what's genuinely open for discussion.
## What to expect
All Mintlify Enterprise agreements go through legal review. Our goal is execution in under three business days.
<Steps>
<Step title="Day 1 — Review">
We review your redlines and assess each against our standard positions.
</Step>
<Step title="Day 2 — Align">
We come back with responses on every open item. We bring solutions, not walls.
</Step>
<Step title="Day 3 — Execute">
Final document signed and deal closed.
</Step>
</Steps>
## What we're flexible on
Most of what procurement teams ask for, we try to accommodate.
- Custom service-level agreements
- Security certifications (Service Organization Control (SOC) 2 Type II, ISO 27001, Digital Operational Resilience Act (DORA))
- Data Processing Agreements
- Liability caps
- Indemnification scope
- Governing law and jurisdiction
- Insurance requirements
- Auto-renewal opt-outs
- Audit rights
## Six fixed positions
These are structural to how the platform operates. We'll explain each one—not to justify ourselves, but because understanding the reason usually resolves the concern.
<AccordionGroup>
<Accordion title="1. Platform IP ownership">
**Our position:** Mintlify owns all platform code, features, and methods.
Customers own all of their content and data.
**Why:** Mintlify is a multi-tenant platform serving thousands of customers. If any customer could claim ownership over platform features, we couldn't offer those features to anyone else and the platform would stop improving. We want Mintlify to get better over time, not worse.
**What this means for you:** Your content, your data, and your documentation output are entirely yours. We make no claim on any of it.
</Accordion>
<Accordion title="2. Aggregate data for product analytics">
**Our position:** Mintlify may use de-identified, aggregated usage data (feature usage, performance metrics, search patterns) for product analytics and improvement.
**Why:** Understanding how features perform across the platform is how we know what to build and how to optimize. Without usage patterns, we're flying blind—and so are you when you rely on us to keep improving.
**What this means for you:** We analyze aggregate signals, not your content. Your specific documentation, your users' data, and any identifiable information are never surfaced or shared.
</Accordion>
<Accordion title="3. Capped liability">
**Our position:** Standard cap is 12 months of fees. For large deals, we go higher. We do not accept unlimited liability.
**Why:** Uncapped exposure makes us uninsurable, which means we'd have to price for worst-case scenarios or decline customer relationships entirely. Neither outcome serves you.
**What this means for you:** We accept a 2x annual fees super-cap for the categories that matter most: confidentiality breaches, data security incidents, and IP indemnification. We feel this is fair for elevated risk categories, and it's backed by insurance.
</Accordion>
<Accordion title="4. No sublicensing">
**Our position:** Customers may not resell or redistribute platform access.
**Why:** Our security model, pricing, and support commitments are built around direct relationships with known customers. Sublicensing creates distribution we can't monitor, secure, or support.
**What this means for you:** Affiliate use within your corporate family—subsidiaries, related entities, M&A scenarios—is fully accommodated under standard enterprise terms.
</Accordion>
<Accordion title="5. Warranty limitations">
**Our position:** We warrant platform uptime per our SLA. We provide everything else on standard "as-is" SaaS terms.
**Why:** We use third-party LLM providers whose output we can't warrant. No software company can guarantee outcomes that depend on customer data, use cases, or third-party integrations.
**What this means for you:** We will warrant in writing that our LLM providers are contractually prohibited from using your data for model training or improvement—which is the protection that actually matters.
</Accordion>
<Accordion title="6. No termination for convenience">
**Our position:** Either party may end the agreement for material breach with a 30-day cure period.
**Why:** A unilateral walk right eliminates the economic basis for our pricing.
**What this means for you:** Our SLA structure provides credits back to you in the unlikely event of service issues. Where there is an actual breach without cure, termination is available. We won't lock customers into bad situations—we just need a mutual commitment to justify the investment on both sides.
</Accordion>
</AccordionGroup>
## Questions
Reach out to your account executive or contact us at [legal@mintlify.com](mailto:legal@mintlify.com).
Our standard terms and compliance documentation are available at [mintlify.com/legal/terms](https://www.mintlify.com/legal/terms) and [security.mintlify.com](https://security.mintlify.com).