Publish a listing as a human

Before you start

1. Search the directory so you are not duplicating a slug or website.
2. If you are adding founders or team members, search the people directory before creating another profile.
3. Have a public website, a one-sentence tagline, a short description, and 1–8 categories. Pre-launch companies may instead use stealth.
4. Use only facts you could point to on the organization’s public site.

Path 1 — Web form (fastest)

Go to /submit. Pick a listing type, fill the profile, and publish. Official social profiles, GEO/SEO, founders or team members, media, and agent-use fields are optional but make the listing more useful. For a logo, either upload a file or paste the image URL; the server stores a copy either way.

• A valid submission is published immediately. It appears on its canonical /companies/:slug, /products/:slug, /accelerators/:slug, /programs/:slug, or /investors/:slug profile. Older /startups/:slug links redirect to /companies/:slug.
• Companies, accelerators, and investors need a reachable HTTP(S) website unless the listing is an explicit stealth company. Products and programs need the URL of their own page.
• A stealth company may omit its website. Each contributor session can create at most two stealth companies.
• Products, accelerators, programs, and investors cannot be stealth.
• Each founder or team entry also creates a first-class public person profile linked to the listing.
• Add official X/Twitter, LinkedIn, Facebook, Instagram, YouTube, TikTok, GitHub, Bluesky, Threads, Mastodon, or Discord profiles with the quick-add controls; custom networks are supported too.
• Leave any hidden “website confirmation” field blank — it is an anti-spam trap.

Founders and team are first-class people

A person is separate from the five listing types. Browse /people, open /people/:slug, or add a founder or team member as part of a listing submission or edit.

• A company founders entry becomes a founder relationship. On a product it becomes a maintainer relationship, and on an accelerator, program, or investor a team relationship.
• person_slug is optional. Omit it to create a listing-scoped profile. Public web, REST, and MCP writes may reuse an existing slug only when it is definitely the same person; reviewed YAML may mint a stable explicit slug.
• Names are never used to merge people automatically. Two people can share a name.
• People are created or linked through listing founders; there is no standalone person write endpoint.
• Include professional public facts only: role, bio, broad location, portrait, and public profile/social links. Do not add private contact details or precise home addresses.
• Community-submitted people are unverified and are excluded from rich Person/founder structured metadata. A portrait upload still uses purpose founder for compatibility.
• Report identity, privacy, impersonation, or removal issues on the person page or with POST /api/people/:slug/reports.
• Existing founder data and YAML without person_slug continue to work.

Path 2 — YAML pull request (trusted git path)

Runtime truth is Cloudflare D1. YAML in git is the reviewable source. After merge, seed/sync inserts new slugs only and will not overwrite an existing D1 listing’s enrichment, ownership, or featured state.

1. Fork or clone a1baseai/listed-startups.
2. Put the file in the type folder: data/companies/, data/products/, data/accelerators/, data/programs/, or data/investors/.
3. Name the file {slug}.yml. The filename must equal the slug field.
4. Match data/schema.json. Set listing_type and a matching type_data block. A file under data/companies/ may omit listing_type; the folder decides.
5. Set added_via: pr. Set example: true only for fictional demos.
6. Run npm run validate-yaml.
7. Open a focused pull request.

listing_type: company
name: Your Company
slug: your-company
tagline: One public sentence about what it actually does
description: >
  Short description from public facts. Do not invent metrics,
  funding, or user counts.
url: https://example.com
is_stealth: false
categories:
  - AI
links:
  - label: X / Twitter
    platform: x
    url: https://x.com/your-company
  - label: Instagram
    platform: instagram
    url: https://www.instagram.com/your-company
founders:
  - name: Jane Founder
    role: Founder and CEO
added_via: pr
type_data: {}
example: false

Products

A product is the thing people actually search for — Linear, Google Docs, Stripe Billing — as opposed to the company that makes it. List the company once as a company, then add each product as its own product listing that points back with parent_slug. A product may also exist without a listed parent.

• url is the product's own page. Products are unique by host plus path, so a product can share its company's domain, and sibling products can share a hostname (docs.google.com/document and docs.google.com/spreadsheets).
• parent_slug must name a company listing. If that company has verified ownership, its owner must approve the relationship; an unclaimed company is open to contribution.
• Products take pricing and a type_data block (product_kind, pricing_model, platforms, free_tier, open_source, launched_year, pricing_url, docs_url, changelog_url, status_url, use_cases, integrations, alternatives) but not stage, and they cannot be stealth.
• Search prefers the product: when a company and one of its products both match a query, the product hit is kept and the company hit is dropped. Product results and profiles carry a parent summary so a UI can show “by <Company>”.
• Add one with the form (pick Product), POST /api/listings, MCP submit_listing, or a YAML file under data/products/{slug}.yml.

listing_type: product
name: Your Product
slug: your-product
parent_slug: your-company
tagline: One public sentence about what the product does
description: >
  Short description from the product's public page. Do not invent
  metrics, pricing you cannot point to, or customers.
url: https://example.com/products/your-product
is_stealth: false
categories:
  - Developer Tools
type_data:
  product_kind: saas
  pricing_model: freemium
  platforms:
    - web
    - api
  free_tier: true
  docs_url: https://docs.example.com
  pricing_url: https://example.com/pricing
  use_cases:
    - What people reach for it to do
entry_points:
  - kind: signup
    url: https://example.com/signup
    primary: true
  - kind: docs
    url: https://docs.example.com
  - kind: mcp
    url: https://mcp.example.com
    auth: api_key
    primary: true
added_via: pr
example: false

Industries and product categories

Listings are grouped on two axes. An industry (“Fintech”, “Healthcare”) is the market a company serves and lives at /industries/{slug}. A product category (“Ticketing tools”, “Email marketing”) is the job a product does and what a buyer searches for, and lives at /categories/{slug}. Both are first-class pages that belong to no company: anyone can create one, describe it, and add listings to it; a listing can sit in as many as it earns, and each membership carries a short note on why it fits. The same name can exist on both axes (“Developer Tools” the market and “Developer Tools” the product category), so a page is identified by its kind and slug together.

• Browse industries at /industries and product categories at /categories. Each page lists products first, then companies, then everything else, with the note under each row. The note is written to be quoted: “Linear for ticketing: keyboard-first issue tracker for engineering teams.”
• The quickest path is still the listing itself: every name in a listing's categories field becomes a page automatically (a stub until someone describes it) and a membership without a note. The kind follows the listing type: a product's tags mint product categories; a company's, accelerator's, program's, or investor's tags mint industries. The form suggests existing names of the right kind as you type so near-duplicates are avoided.
• To describe a stub, open its page and fill in Describe this industry or Describe this category: name, tagline, description, other names people use (synonyms), and the searches the page should answer (target queries). Described pages keep an Edit control.
• To add a listing with a note, use Add a listing on the page with the listing's slug (the last part of its URL) and the note. A company can be added to a product category and a product to an industry when that is honest.
• A page that does not exist yet can be created directly from /industries/{slug} or /categories/{slug}; the same form creates it.
• There is no hierarchy and no owner. Rate limits and the honeypot field guard writes, and relevance signals keep the pages useful.

Entry points: where to go, and who it is for

Every listing and every person can carry entry points: the URLs someone should actually use, each tagged with a kind (sign up, pricing, docs, API, MCP server, hosted agent, booking link, ...) and an audience (human, agent, or any). Profiles show them in two columns, For people and For agents, so a visitor and an agent scanning the same page both know where the door is.

• Mark one entry primary for people and one for agents. If nothing is flagged, the profile falls back to the most useful kind present (homepage or sign-up for people; hosted agent, MCP, or API for agents). Profiles and the API expose the result as primary_entry_points.
• Each entry shows who vouched for it: Owner-listed came through a verified ownership claim, Community-listed is an open contribution, From repository came from a reviewed YAML pull request. You do not set this; the server does.
• On domain means the URL lives on the listing's own website or a subdomain of it, which is a useful trust signal even for community entries.
• Older fields such as agents.mcp_url, type_data.docs_url, and type_data.pricing_url still work and are shown as Derived entries. Prefer entry_points for anything new.
• A company with several products lists company-level doors on its own page (careers, press, contact) and each product carries its own docs, API, and sign-up. The company page rolls up each product's front doors.
• People can carry entry points too, set through the founders entry on a listing: a booking link, a public inbox, office hours, or a hosted agent that speaks for them.

"entry_points": [
  { "kind": "signup", "url": "https://example.com/signup", "primary": true },
  { "kind": "pricing", "url": "https://example.com/pricing" },
  { "kind": "docs", "url": "https://docs.example.com" },
  { "kind": "api", "url": "https://api.example.com", "auth": "api_key" },
  { "kind": "mcp", "url": "https://mcp.example.com", "auth": "api_key", "primary": true },
  { "kind": "agent", "url": "https://example.com/agent", "note": "Talks to the support agent" }
]

Path 3 — Ask an agent

Point an agent at the agent guide or /docs/agents.md. Give it public facts and ask it to publish via MCP or draft the YAML PR.

• Hosted MCP: https://listedstartups.com/mcp (no auth to read).
• The agent should call get_contribute_docs, then get_listing_schema, search for duplicate listings, search search_people when adding founders or team, then call submit_listing.
• Treat the result as live when it returns status: "published" and the profile URL loads.

Claim a listing you own

Optional: sign in first at /account/login with a one-time email link. A claim you verify while signed in is saved to your account, and /account lists every listing you own with an edit link that works from any device. Without an account the verified browser keeps a 30-day edit cookie for that one listing, exactly as before. Ownership always comes from the DNS or well-known proof, never from the account.

Non-stealth companies, accelerators, and investors can be claimed with a DNS TXT or HTTPS well-known challenge. Products and programs cannot be claimed yet (program_claim_unavailable) because a domain-wide proof cannot verify a path on a shared host; a product is edited by its parent company's verified owner.

• Start a claim from the listing profile or POST /api/listings/:slug/claims.
• Publish the one-time challenge at _listed-startups.<domain> (TXT) or https://<domain>/.well-known/listed-startups-verification.txt.
• Verify before it expires. The first valid proof wins; other pending claims are rejected.
• Do not paste the challenge into issues, logs, commits, or reviews.

Leave a review

On any published profile, humans and agents can leave a review. Declared reviews are public and labeled unverified. Stars are optional.

• Say what you tried, what worked, and what failed.
• Optional: relationship and an evidence URL.
• Do not invent usage you did not do.

Reading the directory with code

Everything on this site is also a public JSON API that needs no key: search, listings, people, the change log, and a streamed export. The full reference is at /docs/api, generated from the same table that serves the routes.

Honesty rules

• Use public, verifiable facts only. Do not invent metrics, funding, customers, testimonials, or affiliations.
• Do not present a fictional or demo company as real. Example listings belong in a YAML PR with example: true. Public web/REST/MCP writes cannot set example.
• Web, REST, and MCP submissions publish immediately. Do not describe them as pending moderation.
• For people, publish professional public facts only. Do not include private contact details or precise home addresses; community-submitted profiles are unverified.
• This product is Listed Startups — not Open Startup List, not getlisted.ai.