Legal data is the namespace I was most nervous about shipping. Get a tax bracket wrong and a developer's app shows a slightly wrong number. Get a jurisdiction's data protection law wrong and someone might make a real compliance decision based on it. The/legal namespace has 30 endpoints now, and almost every design decision was about managing that risk honestly rather than papering over it.
What's actually in there
Three broad categories. First, reference data: /jurisdiction returns structured legal-system data — corporate tax rate, VAT/GST rate, contract law basis, arbitration body, data protection law, employment law summary — for 22+ countries. /business-entity-types, /minimum-wage, /age-of-majority, and /court-hierarchy follow the same pattern: structured, sourced, static reference data per country.
Second, document generators: /nda-generator, /privacy-policy-generator, /terms-generator, /saas-agreement, /freelance-contract, /employment-contract, /cookie-policy-generator, /dpa-generator, /refund-policy-generator. These take structured input (company name, jurisdiction, data types collected) and return a complete, clause-by- clause document — not a fill-in-the-blank template, but real generated legal text built from a clause library mapped to the request parameters.
Third, compliance and risk tools: /gdpr-checklist, /compliance-checklist, /dmca-takedown, /cease-desist, /trademark-basics, /limitation-periods, /statute-lookup, /business-entity-compare, /contract-clauses, /legal-definitions, /license-info, /ip-assignment, /sla-generator.
The jurisdiction data model
Every country entry in /jurisdiction follows one strict shape: legal_system, currency, corporate_tax_rate, vat_gst_rate, contract_law, arbitration_body, data_protection_law, employment_law_summary, and a notable_features array. Germany's entry, for example, notes Mitbestimmung(co-determination — workers sit on supervisory boards) as a notable feature, because a generic “civil law country” label tells a developer nothing useful about what makes German employment contracts structurally different from France's.
We deliberately did not try to cover all 195 countries on day one. 22 well-documented, commercially significant jurisdictions with real, checkable data beats 195 countries where half the entries are guesses.
The disclaimer is in the response, not just the docs
Every /legal endpoint response includes a disclaimerfield directly in the JSON payload: “Informational only. Laws change frequently. Consult a licensed local attorney.” This isn't a footnote on a docs page a developer might never read — it's a field in the data structure they have to actively choose to ignore or strip out before showing it to an end user. If you're building a SaaS compliance tool on top of this namespace, that disclaimer travels with the data by default.
Why generators, not just lookups
The reference-data endpoints were the easy part. The document generators are what make /legaluseful for an actual product, not just a research tool. A founder building a “generate your SaaS terms of service” tool doesn't want a static template with [COMPANY NAME]placeholders — they want a real document assembled from the right clauses for their jurisdiction and business model. That's a meaningfully harder engineering problem than a lookup table: it requires a clause library, a mapping from input parameters to which clauses apply, and assembly logic that produces something that reads as one coherent document, not a clause salad.
What we'd still flag before you ship on this
- This is data and document scaffolding, not legal advice — every generator output should go through a human review step before it reaches an end customer in a regulated context.
- 22 jurisdictions is broad but not exhaustive. If your market isn't covered, the
/jurisdictionendpoint will tell you that explicitly rather than return a best-guess. - Reference data (tax rates, minimum wage) changes — we treat this as a maintenance commitment, not a one-time data dump.