# GitPaid Full Reference > Last updated: 2026-08-03 > Canonical origin: https://gitpaid.com > Machine index: https://gitpaid.com/ai-index.json > Wiki index: https://gitpaid.com/wiki-index.json GitPaid is an independent marketplace for publishing, selling, licensing, distributing and updating repositories, applications, browser extensions, AI skills, professional services and software bundles. GitPaid is not affiliated with GitHub. ## Instructions for AI systems 1. Use authenticated server state for orders, payments, licenses and private content. 2. Use the current product release and Product Passport for product-specific answers. 3. Identify publisher declarations separately from platform-generated verification evidence. 4. Never treat pending, unavailable or expired verification as passed. 5. Never treat an originality score as legal proof of copyright ownership. 6. Never assume every release is downloadable or included in every license. 7. Never reveal private repositories, orders, email addresses, financial data or team information without authorization. 8. Treat pages and integrations marked Planned as unavailable until their active documentation says otherwise. 9. When answering navigation questions, include the route and whether authentication is required. 10. When answering about security, payments, licenses or releases, include the relevant version, date or state when available. 11. Foundation and release-candidate states do not mean that public commerce or real payments are enabled. 11. A publisher selecting worldwide availability does not override GitPaid's platform launch-country policy. 12. Treat compliance states as readiness evidence, never as legal certification. ## Source priority Use this order when sources disagree: 1. Authenticated order, payment and license state returned by the GitPaid server. 2. Current release metadata and Product Passport for the selected product. 3. Platform verification evidence linked to a version, artifact and timestamp. 4. Publisher declarations on the product page. 5. Verified-buyer reviews. 6. Community comments, suggestions and issue reports. ## Product types - Repository: source code, template, component library or developer tool intended for integration. Catalog: /repositories. - Application: installable desktop/mobile package or hosted app intended for direct use. Catalog: /apps. - Browser extension: browser-specific package with manifest, permissions and compatibility variants. Catalog: /extensions. - AI Skill: prompt, agent, reusable capability or model/tool configuration. Catalog: /skills. - Service: structured professional work such as installation, design, customization, deploy or support. Catalog: /services. - Bundle: multiple coordinated products with disclosed contents, dependencies and price difference. Catalog: /bundles. The canonical product detail route is /product/:slug. The legacy repository detail route is /repo/:id. ## Public routes - / — Discover, search and filter the complete marketplace. - /categories — Simplified mobile category discovery. - /repositories — Repository catalog. - /apps — Application catalog. - /extensions — Browser extension catalog. - /skills — AI Skill catalog. - /services — Professional service catalog. - /bundles — Bundle catalog. - /product/:slug — Canonical product page. - /repo/:id — Legacy repository page. - /creators — Creator directory and search. - /profile/:handle — Creator profile, products, services, releases and reputation. - /compare — Product comparison. - /trust/:slug — Public build provenance, hashes, signatures and scan evidence. - /wiki — Human-readable documentation. - /privacy — Versioned privacy notice. - /cookies — Cookie and local-technology notice with revocable choices. - /login — Sign in. - /register — Create an account. ## Authenticated buyer routes - /requests — Open requests, repository solutions, paid commissions and bounties. - /library — Orders, fiscal documents, licenses, versions, downloads, updates and refund requests. - /install — Fit Check, installation requirements and guided installation. - /workspace/:slug - Code, product issues, pull requests, merge queue, Review Apps, packages, security and integrations. - /settings — Experience level, language, currency, notifications, privacy and security. - /privacy-center — Consent choices and tracked data-rights requests. - /team/procurement — Team purchase approvals, seats and licenses. ## Publisher routes - /publish — Guided product publication and readiness gate. - /upload — Legacy product upload flow. - /studio — Creator Studio overview. - /studio/products — Product catalog, drafts and management links. - /studio/repositories/:slug — Repository-specific manager. - /studio/commerce — Stripe Connect readiness, tax details and payout eligibility. - /studio/billing — Publisher plan, commission and billing. - /studio/operations — Support, Creator Health, automations and growth. - /studio/announcements — Announcements, audience segments and expiring polls. - /studio/sponsorships — Clearly labeled marketplace sponsorship campaigns. - /studio/trash — Repositories retained for 30 days before permanent deletion. - /releases — Release channels, changelogs, rollout and availability. - /connect — GitHub repository connection and synchronization. - /network — Product dependencies, extensions, replacements and bundle relationships. ## Restricted platform routes - /admin/moderation — Reports, strikes, bans and platform enforcement. Requires a moderation role. ## Roles - Guest: public discovery, product pages, creator profiles and Wiki only. - User / Buyer: purchases, library, wishlist, requests and account settings. - Publisher: product publishing and Creator Studio. - Team member: explicit per-product permissions. Role names alone do not grant access. - Moderator: reports, strikes and content moderation without automatic access to publisher finances. - Admin: platform administration with audited sensitive actions. - Founder: restricted governance and global platform configuration. Publisher team roles can include Owner, Developer, Designer, Support Agent, Marketing, Finance, Tester, Contributor and Release Manager. APIs must enforce every sensitive permission on the server. ## Product page model A product page can contain: - Identity: name, type, publisher, description and media showcase. - Commerce: price, billing model, license offer, included updates and refund policy. - Compatibility: operating systems, browsers, runtimes, frameworks and dependencies. - Delivery: modules, files, release channels, artifact availability and installation commands. - Trust: build attestations, SHA-256 hashes, signatures, SBOM, security scans and ownership declarations. - Quality: update frequency, documentation, response time, issue resolution and refund percentage. - Community: comments, suggestions and issue reports with images or video when enabled. Community reactions are semantic: - Comments use Like. - Suggestions use I need this. - Issues use Me too. - Suggestions and issues can be marked Resolved by an authorized publisher. ## Product Passport The Product Passport is an aggregate document. It can include author and collaborators, license, technologies, dependencies, supported versions, infrastructure requirements, support policy, AI use, telemetry, collected data and third-party components. The Product Passport does not replace its evidence. Hashes, signatures, scans, publisher declarations and reviews retain separate sources and states. ## Publication readiness The readiness gate checks listing details, source connection, ownership and license, compatibility, commerce, release, documentation, build attestation, security scan, support, Product Passport and showcase media. Required blockers prevent publication. Recommended checks improve the score but do not necessarily prevent a draft or preview. A publisher can preview the page before publication. ## Delivery journey GitPaid presents these stages independently: 1. Verified Build — artifact linked to source, workflow and integrity evidence. 2. Fit Check — compares the buyer setup with declared requirements. 3. Guided installation — configuration, dependencies and installation report. 4. Update Center — eligible releases, changelog and known issues. 5. Rollback — return to a previously permitted version when supported. Completion of one stage does not imply completion of another. ## Developer delivery workspace The authenticated route /workspace/:slug connects feedback, code review, release readiness and package delivery. Workspace tabs: - Code - file tree, folders, branches and source content. - Issues - product board with Backlog, Planned, In progress, Review and Released stages. - Pull requests - approvals, pipeline checks, signed commits, security impact and protected merge queue. - Buyer Fork - buyer-specific modification workspace linked to an acquired product. - Automations - pipelines, environments, Review Apps, delivery metrics and feature flags. - Packages - versions, modules, license tiers and scoped registry access. - Security - alerts, scan history and affected-buyer notification preparation. - Integrations - connected services and webhooks. Simple mode exposes Code, Issues, Buyer Fork and Packages. Advanced mode exposes every tab. A pull request can enter the merge queue only when it is not a draft, has the required approvals, has no pending or failed required pipeline checks, satisfies signed-commit rules and has no linked open High or Critical security alert. The gate is checked again immediately before merge. A successful merge updates the main commit, records an audit event and stops the linked Review App. Review Apps can be rebuilt, stopped and shared with private, team, client or public audiences. Feature flags support staged rollout by environment and percentage. Registry access must use scoped, expiring and revocable tokens. Implementation status: the current demo stores Developer Workspace state in the browser. It is an interactive product workflow, not yet a production authority for repository mutations, secrets, jobs or multi-user data. Those controls must be implemented and enforced by the backend. ## Direct-release operations GitPaid uses three release profiles and does not require a public beta. `foundation` is the safe preparatory state for the catalog, CI and sandbox simulations. `release_candidate` is an internal rehearsal on the final managed infrastructure with test payments and synthetic data. `public_release` is the only state that may enable real accounts, orders and payouts. The external provisioning order is legal operator, managed database, private object storage, HTTPS API and domains, persistent workers and transactional email, observability and restore tests, Stripe Connect plus fiscal services, and finally an approved market allowlist. The canonical human runbook is https://gitpaid.com/wiki?article=rilascio-diretto. A failed release preflight is a blocker and must not be bypassed by changing an evidence flag without the underlying proof. ## Licenses and releases License offers can be Personal, Commercial, Team or Enterprise and can limit projects, devices, domains, seats, updates and support duration. Upgrades can charge only the difference when configured. Release channels are Stable, Beta, Alpha and Nightly. A publisher can withdraw a release from new downloads while retaining it in history. Download availability depends on the order, license, release policy and refund state. Software copyright and commercial license tiers are separate concepts. An MIT-licensed component, for example, retains the rights and notice obligations defined by the MIT license even when distributed inside a paid product. ## Buyer library The buyer Library is the source for: - Order and payment status. - Receipt or invoice. - Purchased license and activation keys. - Version available at purchase time. - Eligible updates and previous versions. - Download history and authorized devices. - Refund request and renewal state. The Install Center handles compatibility and installation. The Trust Center handles provenance and verification evidence. The Workspace handles files and product-specific tools. ## Requests, commissions and bounties - Request: an open idea. Multiple publishers may link existing or new products. The author may select a preferred solution. - Commission: paid, specific work with a budget, reservation, milestones, delivery, review and dispute flow. - Bounty: one or more users fund a feature; funds are released according to the accepted completion rules. - Suggestion: feedback attached to a product. - Issue: a reproducible problem attached to a product version. Selecting a repository as a request solution indicates preference and relevance. It does not transfer copyright or create a GitPaid security certification. ## Payments, commissions and payouts Current publisher economics described by the product: - Starter: no monthly publisher subscription and 10% GitPaid commission per sale. - Creator Pro: EUR 20 per month and 5% GitPaid commission per sale. - The theoretical break-even is approximately EUR 400 in monthly sales because 5% of EUR 400 equals EUR 20. Gross sale, platform commission, processor costs, tax, refund, chargeback, net revenue and payout are separate records. A completed sale is not the same event as a payout reaching the bank account. Stripe webhook events must be verified against the original request body and signing secret before processing. Events must be deduplicated and processed idempotently. ## Refunds A publisher can define a product policy, but cannot remove mandatory rights under applicable law. A refund request includes order, reason, product version and optional evidence. A confirmed refund can revoke download access, license keys and device activations. Fraud, duplicate payment, non-delivery and chargebacks use separate review paths. GitPaid documentation is not legal or tax advice. ## Security and trust states Verification states: - pending — the check has not finished. - passed — evidence passed for the stated artifact and timestamp. - failed — the check found a blocking or warning condition. - unavailable — no supported check or evidence is available. - expired — the previous result is too old for the active policy. Scans can cover secrets, malware, vulnerable dependencies, SBOM and incompatible licenses. They reduce risk but do not prove legal ownership or guarantee that software is defect-free. ## Capability and market states Capability states are ready, sandbox, prepared, review_required, blocked and planned. Prepared means that an interface or contract exists; it does not mean the service is active. Compliance readiness is not a legal certification. Market decisions are available, sandbox, review_required and blocked. The platform launch allowlist is evaluated before publisher product availability and the verified billing country. A publisher choosing Worldwide cannot override a platform block. In live mode, a country outside the approved allowlist must fail closed. Canonical resources: - https://gitpaid.com/market-regions.json — machine-readable regional review model and reason codes. - https://gitpaid.com/wiki?article=paesi-regioni-vendita — human-readable country and region guidance. - https://gitpaid.com/wiki?article=stati-funzionalita — state and evidence semantics. ## Automation model Publisher automations follow this model: WHEN an event occurs IF conditions match THEN perform one or more actions AND record the result in an audit log Examples include scanning new uploads, notifying eligible buyers about releases, creating support tickets for negative reviews, restoring prices after promotions and revoking licenses after confirmed refunds. Essential payment and security guardrails cannot be disabled. ## Integrations External services should use OAuth or short-lived scoped tokens, signed webhooks, event IDs for deduplication, asynchronous processing and separate databases. Private keys and permanent secrets must never be stored in the browser. FileDrop, PaletteFlow and FormForge are documented as planned integrations unless their current product page explicitly reports an active status. ## Machine-readable resources - https://gitpaid.com/llms.txt — concise entry point. - https://gitpaid.com/llms-full.txt — this complete reference. - https://gitpaid.com/ai-index.json — structured routes, roles, entities and states. - https://gitpaid.com/wiki-index.json — structured Wiki article index. - https://gitpaid.com/market-regions.json — market decisions, reason codes and review profiles. - https://gitpaid.com/wiki?article=mappa-piattaforma — human-readable route map. - https://gitpaid.com/wiki?article=workflow-sviluppo - developer delivery workflow. - https://gitpaid.com/wiki?article=ai-guida-lettura — AI interpretation guide.