Stripe Projects for developers

Stripe Projects provisions third-party services — hosting, databases, auth, AI, analytics — from the command line, and returns real credentials to you or your agent. This page indexes everything a developer or an agent needs to integrate with it.

Install everything

Stripe Projects is a plugin for the Stripe CLI. This installs the CLI, the plugin, and the agent skill in one command:

npm install -g @stripe/cli@latest && \
  stripe plugin install projects && \
  npx skills add https://github.com/stripe/ai --skill stripe-projects -y -g

Free to use. You pay providers directly at their standard rates.

Install the CLI only

On macOS:

brew install stripe/stripe-cli/stripe && stripe plugin install projects

On Linux and Windows:

npm install -g @stripe/cli@latest && stripe plugin install projects

Other install methods, including Docker: docs.stripe.com/stripe-cli/install

Install the agent skill only

To give an agent end-to-end provisioning capability without reinstalling the CLI:

npx skills add https://github.com/stripe/ai --skill stripe-projects -y -g

The skill drives the full workflow: verify provider, install CLI, install plugin, search catalog, init project, add service, hand off. It is also published as /skill.md and declared for discovery at /.well-known/agent-skills/index.json.

Browse what you can provision

  • Provider catalog — every supported provider with its service slug and category.
  • Templates — starting points with providers already wired together.
  • /llms.txt — the same catalog as a single plain-text file for LLM context.

Site API and discovery

This website exposes a small, public, read-only API used for discovery and health checks. It is not the product API — provisioning happens through the CLI.

Error format

Endpoints under /api/ that return an error respond with RFC 9457 problem details as application/problem+json. The code field is machine-readable and stable; detail is for humans. This includes unrecognised paths: any /api/ URL that does not exist returns a 404 problem document, never an HTML or plaintext error page.

{
  "type": "https://projects.dev/docs/api/#method-not-allowed",
  "title": "Method Not Allowed",
  "status": 405,
  "code": "method_not_allowed",
  "detail": "This endpoint only supports GET.",
  "instance": "/api/health"
}

Versioning and deprecation

Pin to /api/v1/. That is the versioned surface. The unversioned /api/ paths are aliases kept for compatibility and always resolve to the current major version, so they may change behaviour when v2 ships. A v2 prefix would be introduced alongside v1 rather than replacing it.

The description document is separately versioned by info.version in /api/openapi.json, following semantic versioning.

  • Adding an endpoint, or an optional field to a response, is a minor version bump and is not announced.
  • Removing an endpoint or field, or changing a field's type, is a major version bump and gets a new path prefix.
  • Before any breaking change, the affected endpoint returns RFC 9745 Deprecation and RFC 8594 Sunset headers, plus a Link header with rel="deprecation" pointing at an explanation.
  • The window between the first Deprecation header and the Sunset date is at least 90 days.
  • Deprecations are also recorded in the x-deprecation-policy extension in the OpenAPI document and announced on the blog.

Rate limits

There are none. No per-client rate limiting is applied to these endpoints, so no RateLimit headers are returned and you do not need to self-throttle. This is stated rather than left to inference: an absent header here means no limit, not an undocumented one.

If limits are introduced, they will be advertised with the RFC 9331 RateLimit and RateLimit-Policy headers, with Retry-After on a 429, and announced under the deprecation policy above. The current state is also machine-readable as x-rate-limit-policy in /api/openapi.json.