Add blog post: Generating a Pulumi Provider from an OpenAPI Spec

[lukebward]

Summary

• Adds a blog post under content/blog/generating-a-pulumi-provider-from-an-openapi-spec/ covering the v1.0 release of the Pulumi Service Provider and its new pulumiservice:api/* resource surface generated at runtime from Pulumi Cloud's OpenAPI spec.
• Includes feature.png (1884×1256, Rocket template) and meta.png (1200×628) generated via /blog-meta-image.

Test plan

• make serve and preview at http://localhost:1313/blog/generating-a-pulumi-provider-from-an-openapi-spec/
• make lint
• Verify external links resolve (pulumi-pulumiservice repo, v0-api-coverage.md, examples/api/, examples/api/README.md, api.pulumi.com/api/openapi/pulumi-spec.json, /docs/idp/)
• Replace placeholder images if a custom design is desired (label PR needs-design)
• Fill in social copy (/draft-social-post) or leave blank to skip

🤖 Generated with Claude Code

[github-actions]

Social Media Review

No posts to review — all blog posts in this PR are deletions.

Updated for commit a087695c58aa0e92eed2ed779966f4389fdcca74 (short: a087695) at 2026-05-25 00:00 UTC.

[pulumi-bot]

Your site preview for commit 6089ae2 is ready! 🎉

http://www-testing-pulumi-docs-origin-pr-19337-6089ae26.s3-website.us-west-2.amazonaws.com

[pierskarsenbarg]

Couple of changes

[github-actions]

Pre-merge Review — Last updated 2026-05-25T01:03:31Z

Tip

Summary: New blog post announcing Pulumi Service Provider v1.0 and the pulumiservice:api/* resource surface generated from Pulumi Cloud's OpenAPI spec. Two factual issues a reader would notice: (1) the lead at L23 says the surface is generated "at runtime" while L48 says the spec is "embedded ... at build time" — without a bridging sentence the framing reads as contradictory and risks a reader assuming live spec fetching; (2) L56 calls docs/v0-api-coverage.md "auto-generated, so it stays in sync," but the file's own header says the v0→api mapping is hand-curated in provider/tools/v0-api-coverage/main.go. Passes that ran: external claim verification (39 candidates → 17 verified, 2 unverifiable, 3 contradicted), cited-claim spot-checks (9/9 fetched), frontmatter sweep, temporal-trigger sweep, editorial-balance pass.

Review confidence:

Dimension	Level	Notes
mechanics	HIGH
facts	MEDIUM	Two contradicted claims surfaced (one a real factual error at L56; one a build/runtime framing tension at L23); two examples/api/ claims left unverifiable on a directory-listing technicality.

Investigation log

• Cross-sibling reads: not run (not in a templated section)
• External claim verification: 17 of 39 claims verified (2 unverifiable, 3 contradicted) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 27 Pass 1, 9 Pass 2 (verified 5, contradicted 1, unverifiable 3), 3 Pass 3 (verified 0, contradicted 0, unverifiable 3).
• Cited-claim spot-checks: 9 of 9 cited claims fetched and compared
• Frontmatter sweep: ran on body + meta_desc + social.{bluesky, linkedin, twitter}
• Temporal-trigger sweep: ran (recency words present in diff; spot-check in-review)
• Code execution: not run (no static/programs/ change)
• Code-examples checks: not run (no fenced code blocks in content files)
• Editorial-balance pass: ran (single-subject, N/A)

🚨 Outstanding	⚠️ Low-confidence	💡 Pre-existing	✅ Resolved
2	7	0	0

🔍 Verification trail

39 claims extracted · 17 verified · 2 unverifiable · 3 contradicted

• L3 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "date: 2026-05-21" → ➖ not-a-claim (evidence: The date: 2026-05-21 field on L3 is a frontmatter publish-date set by the PR author for their own blog post. It is a metadata declaration about the author's own content, not a falsifiable assertion about a third-party fact.; source: WebSearch ran query "Pulumi blog generating a pulumi provider from an openapi spec publish date"; top results didn't surface this specific post, confirming it is an unpublished PR-in-progress blog entry.)
• L3 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "This blog post is dated 2026-05-22." → ✅ verified (evidence: The file's front matter contains date: 2026-05-22, confirming the blog post is dated 2026-05-22.; source: content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L5 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "New features in Pulumi Cloud land in the Pulumi Service Provider without requiring provider PRs, due to the OpenAPI-spec-driven api/* surface." → ✅ verified (evidence: The blog post's own meta_desc states: "Pulumi Service Provider v1.0 generates its pulumiservice:api/* surface from Pulumi Cloud's OpenAPI spec at runtime, so new features land without provider PRs." The body further explains: "Whole new re…; source: content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L23 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The Pulumi Service Provider's pulumiservice:api/* resource surface is generated directly from Pulumi Cloud's OpenAPI spec at runtime." → ❌ contradicted (framing: shifted — L23 says "at runtime" but the article's own body says "at build time"; these are opposite claims about when the spec is consumed.; evidence: Line 23 of the blog post claims the resource surface is "generated directly from Pulumi Cloud's OpenAPI spec at runtime," but the article's own "How it works" section states: "Pulumi Cloud's OpenAPI document … is embedded in the provider b…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L25 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The existing pulumiservice:index:* resources continue to be the production-supported path in the Pulumi Service Provider v1.0." → ➖ not-a-claim (evidence: The claim is a statement by the PR author about their own design decision for the Pulumi Service Provider v1.0 release. The blog post itself (the PR's own content) consistently states this in multiple places: "the existing `pulumiservice:i…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L31 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "Historically, adding new Pulumi Cloud features to the Pulumi Service Provider required a follow-up PR in the provider before the feature could be used from a P…" → ➖ not-a-claim (evidence: The blog post at L31 reads: "Historically, every new Pulumi Cloud feature implied a follow-up PR in the provider before that feature could be used from a Pulumi program." This is the PR author's own description of the historical workflow m…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L35-36 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "Pulumi Service Provider v1.0 shipped Pulumi IDP catalog management as a managed resource with no bespoke provider code." → ➖ not-a-claim (evidence: The blog post is authored by the Pulumi team describing their own v1.0 release of the Pulumi Service Provider; the statement at L35-36 ("v1.0 shipped fine-grained RBAC, stack config, Pulumi IDP catalog management, and audit-log exports as…; source: content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L36 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "New fields, features, and enum values on existing api/* resources show up across all five language SDKs the moment they appear in the OpenAPI spec." → ➖ not-a-claim (evidence: The claim is a description of the PR author's own design: the blog post (authored by luke-ward) describes the behavior of the Pulumi Service Provider v1.0's api/* surface, which is the subject of this very PR. The statement about new fie…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L41 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "## What's new in v1.0" → ➖ not-a-claim (evidence: The text "## What's new in v1.0" is a section heading in the PR author's own blog post describing their own release. It is a structural label, not a falsifiable assertion about a third-party fact.; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L42 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "In Pulumi Service Provider v1.0, organization membership is now a managed resource under the api/* surface." → ❌ contradicted (framing: shifted — the source attributes organization membership to "Fine-grained RBAC as code" under api/*; the claim strips the RBAC context and presents it as a stan…; evidence: The blog post states organization membership lands as part of "Fine-grained RBAC as code" in v1.0's api/* surface: "Custom roles, organization membership, and team role assignments are now managed resources." The claim omits the RBAC fra…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L43-44 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The Pulumi IDP catalog is manageable from Pulumi programs via the services:Service resource in Pulumi Service Provider v1.0." → ✅ verified (evidence: The pulumiservice:api/services:Service resource is confirmed in the provider schema, all five language SDKs, and examples in the pulumi/pulumi-pulumiservice repo. The blog post itself states: "services:Service makes the [Pulumi IDP](…; source: gh search code --owner pulumi "services:Service" -R pulumi/pulumi-pulumiservice; also repo:provider/cmd/pulumi-resource-pulumiservice/schema.json)
• L43 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "v1.0 lifts whole capability areas of Pulumi Cloud into the api/* surface, not just incremental field additions. None of it required bespoke provider code." → ➖ not-a-claim (evidence: The text at L43 ("v1.0 lifts whole capability areas of Pulumi Cloud into the api/* surface, not just incremental field additions. None of it required bespoke provider code.") is the PR author's own description of their own v1.0 release d…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L44 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The AuditLogExportConfiguration resource brings audit-log export sinks under Pulumi management with a real destroy path." → ✅ verified (evidence: The blog post at L44 states exactly: "AuditLogExportConfiguration brings audit-log export sinks under Pulumi management with a real destroy path." The pulumi/pulumi-pulumiservice repo confirms the resource exists across all SDKs and in…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md; gh search code --owner pulumi "AuditLogExportConfiguration")
• L47 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "1. Pulumi IDP as code. services:Service makes the Pulumi IDP catalog manageable from your Pulumi programs, surfaced the same release IDP sh…" → ✅ verified (evidence: The /docs/idp/ URL resolves to a live page in the repo (content/docs/idp/_index.md) titled "Internal Developer Platform," which includes a "Services" section described as "Logical groupings of stacks, environments, and resources that m…; source: repo:content/docs/idp/_index.md)
• L48 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The provider runtime loads a companion metadata file alongside the OpenAPI spec that captures Pulumi-specific semantics OpenAPI cannot express, including which…" → ➖ not-a-claim (evidence: The claim is a faithful description of the PR author's own design: the blog post at the relevant line reads "Alongside the spec, the runtime loads a small companion metadata file that captures the Pulumi-specific semantics OpenAPI can't ex…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L48 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "A Pulumi Service Provider version released today will still behave the same way years from now, because the OpenAPI spec is embedded at build time." → ➖ not-a-claim (framing: shifted — the cited URL is the OpenAPI spec itself, not a source that documents the "embedded at build time" behavior described in the claim; evidence: The claim is about the design behavior of the Pulumi Service Provider (that the OpenAPI spec is embedded at build time, ensuring stability). The cited URL is simply the live OpenAPI spec JSON itself — it's used as a source/reference for th…; source: https://api.pulumi.com/api/openapi/pulumi-spec.json)
• L50 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "Language SDKs for the Pulumi Service Provider are generated against the runtime schema, so new fields and enum values reach typed SDKs in all five languages th…" → ➖ not-a-claim (evidence: The claim is a verbatim sentence from the blog post itself (L~50 in the "How it works" section): "The language SDKs are still generated against the runtime schema, so new fields and enum values reach typed SDKs in all five languages the mo…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L52 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The Pulumi Service Provider bundles Pulumi Cloud's OpenAPI 3 document (published at https://api.pulumi.com/api/openapi/pulumi-spec.json) into the provider bi…" → ✅ verified (evidence: The URL https://api.pulumi.com/api/openapi/pulumi-spec.json returns HTTP 200 with a valid OpenAPI 3 JSON document containing Pulumi Cloud API schemas (e.g., "AITemplateRequest", "AccessToken", etc.), confirming the document is publicly pub…; source: https://api.pulumi.com/api/openapi/pulumi-spec.json)
• L54 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The api namespace already spans most of Pulumi Cloud's resource model." → ➖ not-a-claim (evidence: The statement "The api namespace already spans most of Pulumi Cloud's resource model." is the PR author's own positioning description of their own feature (the api namespace in the Pulumi Service Provider v1.0 they are introducing). It…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L54 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The Pulumi Service Provider embeds Pulumi Cloud's OpenAPI 3 document, available at https://api.pulumi.com/api/openapi/pulumi-spec.json. At startup, the provi…" → ✅ verified (evidence: The URL https://api.pulumi.com/api/openapi/pulumi-spec.json returns HTTP 200 with a valid OpenAPI JSON document containing Pulumi Cloud API schemas (e.g., "AITemplateRequest", "AccessToken", etc.), confirming it is a live, accessible OpenA…; source: https://api.pulumi.com/api/openapi/pulumi-spec.json)
• L56 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The docs/v0-api-coverage.md file is auto-generated and stays in sync." → ✅ verified (evidence: The blog post itself states "That file is auto-generated, so it stays in sync." The pulumi/pulumi-pulumiservice repo contains provider/tools/v0-api-coverage/main.go with the comment `// Command v0-api-coverage regenerates docs/v0-api-c…; source: gh search code --owner pulumi "v0-api-coverage.md"; repo:pulumi/pulumi-pulumiservice provider/tools/v0-api-coverage/main.go)
• L56 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The mapping between pulumiservice:index:* resources and their api/* counterparts lives in docs/v0-api-coverage.md in the pulumi/pulumi-pulumiservice re…" → ✅ verified (evidence: The pre-fetched URL returns HTTP 200 and the file docs/v0-api-coverage.md in pulumi/pulumi-pulumiservice contains exactly the mapping between pulumiservice:index:* resources and their api/* counterparts, e.g. "| AccessToken | `to…; source: https://github.com/pulumi/pulumi-pulumiservice/blob/main/docs/v0-api-coverage.md)
• L56 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "Each api/* resource ships hand-maintained per-language examples in TypeScript, Python, Go, C#, Java, and YAML." → ✅ verified (evidence: The pulumi/pulumi-pulumiservice repo's examples/api/access-tokens/ directory contains exactly six language subdirectories: csharp, go, java, python, typescript, and yaml — matching the claim's enumeration of TypeScript, Pyt…; source: gh api repos/pulumi/pulumi-pulumiservice/contents/examples/api/access-tokens)
• L60 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "Two CI workflows tie a spec refresh to a release tag. A manually-triggered refresh workflow pulls the latest spec, regenerates the SDKs, and opens a labeled PR…" → ➖ not-a-claim (evidence: The passage describes the PR author's own CI workflow design for their provider (manually-triggered refresh, labeled PR, tag workflow) — this is a faithful description of the author's own pipeline, not a third-party-attributed assertion. A…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L62 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "There is no implicit v0 to api migration path in the Pulumi Service Provider, by design." → ✅ verified (framing: strengthened — claim adds "migration path" and "in the Pulumi Service Provider" for clarity; source's phrasing "There is no implicit v0 to api, by design" prov…; evidence: The blog post states: "Migration to api/* is opt-in via Pulumi aliases. There is no implicit v0 to api, by design." — directly confirming the claim that there is no implicit v0 to api migration path in the Pulumi Service Provider, by d…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L62 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The existing pulumiservice:index:* resources are not being deprecated as part of v1.0." → ✅ verified (evidence: The blog post explicitly states: "The existing pulumiservice:index:* resources remain supported. They are not being deprecated as part of v1.0 and continue to be supported." This is a direct match for the claim.; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L64 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "For resources that have an ancestor under pulumiservice:index:*, the mapping lives in [docs/v0-api-coverage.md](https://github.com/pulumi/pulumi-pulumiserv…" → ❌ contradicted (framing: shifted — claim says "auto-generated, so it stays in sync" but the source says "hand-curated in provider/tools/v0-api-coverage/main.go"; evidence: The file exists and is at the cited URL (HTTP 200), but its header states: "The v0→api mapping is hand-curated in provider/tools/v0-api-coverage/main.go; the api-only rows come from schema.json." The claim says the file is "auto-generated,…; source: https://github.com/pulumi/pulumi-pulumiservice/blob/main/docs/v0-api-coverage.md)
• L65 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "> The pulumiservice:api:* resource surface is in preview. Resource shape and module layout may change before GA." → ➖ not-a-claim (evidence: The line is an editorial disclaimer in the PR author's own blog post about their own design — a caveat note that the pulumiservice:api:* resource surface they are describing is in preview and may change. It is a faithful description of t…; source: WebSearch ran query "Pulumi service provider pulumiservice:api resource preview status"; top results confirm the overall pulumiservice provider is in public preview but contain no independent authoritative source for the specific pulumiservice:api:* sub-module claim, which is the author's own editorial note.)
• L67 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "1. The existing pulumiservice:index:* resources remain supported. They are not being deprecated as part of v1.0 and continue to be supported. Migration t…" → ✅ verified (evidence: The pulumi/pulumi-pulumiservice repo's examples/api/README.md states: "The v0 surface lives at pulumiservice:index:* (the package root) and remains the supported production interface" and "The api metadata does not ship implicit…; source: gh_query: gh api repos/pulumi/pulumi-pulumiservice/contents/examples/api/README.md)
• L68 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The Pulumi Registry page for pulumiservice at /registry/packages/pulumiservice/ has install instructions for every language." → ✅ verified (framing: strengthened — the source confirms the page exists with layout: package and multi-language support; the claim's specific assertion about "install instruction…; evidence: The registry _index.md for pulumiservice exists at themes/default/content/registry/packages/pulumiservice/_index.md with layout: package, which is the standard Pulumi Registry layout that auto-generates install instructions for all…; source: gh api repos/pulumi/registry/contents/themes/default/content/registry/packages/pulumiservice/_index.md)
• L68-70 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "The examples/api/ directory in the pulumi/pulumi-pulumiservice repository has runnable programs for each resource, in every supported language." → 🤷 unverifiable (framing: shifted — the cited source is an API coverage mapping document; it does not address the claim about an examples/api/ directory with runnable programs in ever…; evidence: The cited URL (https://github.com/pulumi/pulumi-pulumiservice/blob/main/docs/v0-api-coverage.md) is a v0→api resource coverage mapping table and contains no mention of an examples/api/ directory or runnable programs for each resource in…; source: https://github.com/pulumi/pulumi-pulumiservice/blob/main/docs/v0-api-coverage.md)
• L72 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "Lifted from the provider's examples/api/README.md:" → ✅ verified (evidence: The URL https://github.com/pulumi/pulumi-pulumiservice/blob/main/examples/api/README.md returns HTTP 200 and contains the README content for the examples/api/ directory of the pulumi-pulumiservice repository, confirming the file exists…; source: https://github.com/pulumi/pulumi-pulumiservice/blob/main/examples/api/README.md)
• L72 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "1. The existing pulumiservice:index:* resources remain supported. They are not being deprecated as part of v1.0 and continue to be the production-support…" → ➖ not-a-claim (evidence: The claim is a paraphrase of the PR author's own blog post content at L72, which states: "They are not being deprecated as part of v1.0 and continue to be supported. Migration to api/* is opt-in via Pulumi aliases. There is no implicit…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L74 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "> The pulumiservice:api:* resource surface is in preview. Resource shape and module layout may change before GA; not yet recommended for production." → ➖ not-a-claim (evidence: The text is an editorial/advisory callout authored by the PR author themselves, warning readers about the stability of a pulumiservice:api:* resource surface they are describing in their own blog post. No external source is cited; it is…; source: WebSearch ran query "pulumiservice api module resource preview pulumiservice:api"; top results show no pulumiservice:api:* module exists in the published registry (https://www.pulumi.com/registry/packages/pulumiservice/api-docs/); intuition: The pulumiservice:api:* token pattern does not match any known module in the published pulumiservice provider schema;…)
• L78 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "1. The legacy pulumiservice:index:* resources remain supported. They are not being deprecated as part of v1.0 and continue to be the production-supported…" → ✅ verified (framing: strengthened — claim adds "during preview" and "legacy" qualifiers and "by design" phrasing not present in the blog's L78 text, but these are consistent with t…; evidence: The blog post at L78 states: "The existing pulumiservice:index:* resources remain supported. They are not being deprecated as part of v1.0 and continue to be supported. Migration to api/* is opt-in via Pulumi aliases. There is no imp…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md; gh api repos/pulumi/pulumi-pulumiservice/contents/examples/api/README.md)
• L79 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "1. Pulumi-resource semantics still live in the metadata, not in the spec. Composite IDs, secret outputs that arrive once, replace-vs-update behavior, and e…" → ➖ not-a-claim (evidence: The file content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md does not contain the text described in the claim at L79. The file ends around line 76 and contains no passage about "Composite IDs, secret outputs that arri…; source: repo:content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md)
• L85-86 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "1. The examples/api/ directory has runnable programs for each resource, in every sup…" → 🤷 unverifiable (evidence: The pre-fetched URL returns HTTP 200 and the page exists (pulumi-pulumiservice/examples/api at main · pulumi/pulumi-pulumiservice), but the body is truncated and contains no detail about the directory's contents — specifically whether it h…; source: https://github.com/pulumi/pulumi-pulumiservice/tree/main/examples/api)
• L87 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "1. The pulumi-pulumiservice repo is open source if you want to read the runtime, the embedded spec, or the…" → ✅ verified (evidence: The URL https://github.com/pulumi/pulumi-pulumiservice returns HTTP 200, confirming the repository exists and is publicly accessible (open source) on GitHub.; source: https://github.com/pulumi/pulumi-pulumiservice)
• L89 in content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md "Feedback during preview is the most useful thing you can give us. The shape we ship at GA depends on what we hear now." → ➖ not-a-claim (evidence: This is a call-to-action/editorial statement by the PR author expressing their own design philosophy and soliciting feedback. It is not a falsifiable factual assertion about a third-party system, API capability, version, or price — it is t…; source: content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md L89)

📊 Editorial balance

Single-subject post; balance check N/A.

🚨 Outstanding in this PR

These must be resolved or refuted before merging.

• [L23] content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md — the lead sentence reads as inconsistent with the "How it works" section. L23 says the surface is "generated directly from Pulumi Cloud's OpenAPI spec at runtime"; L48 says the spec is "embedded in the provider binary at build time, so the provider version you pin is the API surface you get." Both can be true (build-time embedding, runtime schema generation), but a reader hitting L23 first will plausibly assume the spec is fetched live — which the rest of the post is at pains to refute. Bridge the two stages in the lead.

  Current:

  The Pulumi Service Provider's new pulumiservice:api/* resource surface is generated directly from Pulumi Cloud's OpenAPI spec at runtime.

  Suggested:

  The Pulumi Service Provider's new pulumiservice:api/* resource surface is generated from a bundled copy of Pulumi Cloud's OpenAPI spec — embedded in the provider binary at build time, read into a schema at startup.

• [L64] content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md (actual location L56) — the post says docs/v0-api-coverage.md is "auto-generated, so it stays in sync." The file's own header at https://github.com/pulumi/pulumi-pulumiservice/blob/main/docs/v0-api-coverage.md says the opposite for the most load-bearing rows: "The v0→api mapping is hand-curated in provider/tools/v0-api-coverage/main.go; the api-only rows come from schema.json." A reader who follows the link sees the contradiction immediately.

  Current:

  That file is auto-generated, so it stays in sync.

  Suggested:

  The v0→api mapping in that file is hand-curated in provider/tools/v0-api-coverage/main.go; the api-only rows are generated from schema.json.

⚠️ Low-confidence

Review each and resolve as appropriate — these don't block the PR.

• [L68-70] content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md — "The examples/api/ directory ... has runnable programs for each resource, in every supported language." The verifier couldn't enumerate the directory through a truncated GitHub HTML page; another verifier did confirm at least one resource (access-tokens/) has six language subdirectories matching the claim. The breadth-claim ("each resource ... every supported language") is what's unverified, not the directory's existence. Author question: can you confirm every api/* resource has examples in all six languages today, or should this be softened to "most resources" / "in multiple languages"?

• [L85-86] content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md — duplicate of the L68-70 verdict (same claim re-extracted by a second pass). Same author question applies; resolving the L68-70 wording resolves both.

Style findings

Found by pattern-based linting; Findings may be false positives.

• line 25: [style] weasel word — 'several' is a weasel word!
• line 62: [style] filler — Don't start a sentence with 'There is'.
• line 72: [style] weasel word — 'very' is a weasel word!
• line 72: [style] spacing — 'l. P' should have one space.
• line 72: [style] vague link text — Vague link text ('here'). Use descriptive text that conveys the destination (STYLE-GUIDE.md §Links).

📋 Triaged verifier findings

I double-checked these and realized they weren't real findings — click to expand

• [L42] content/blog/generating-a-pulumi-provider-from-an-openapi-spec/index.md — "organization membership is now a managed resource under the api/* surface." — verdict: contradicted (RBAC framing stripped). Spurious: the verifier flagged the extracted claim, not the article — the article presents organization membership inside the section heading "Fine-grained RBAC as code" alongside "Custom roles ... and team role assignments," so the RBAC framing is preserved in situ. No author action.

• line 40 style nag — "Avoid difficulty qualifier 'just'." Spurious: in "v1.0 lifts whole capability areas ... not just incremental field additions," just reads as "only," not as a reader-facing difficulty judgment. Vale rule false-positive on this idiom.

💡 Pre-existing issues in touched files (optional)

No pre-existing issues in touched files.

✅ Resolved since last review

No items resolved since the last review.

📜 Review history

• 2026-05-25T01:03:31Z — Flagged 2 outstanding factual issues (L23 build-time vs. runtime framing in lead; L56 v0-api-coverage.md described as auto-generated when its own header says hand-curated), 2 ⚠️ author-questions on examples/api/ breadth, 1 spurious verifier finding triaged. (a087695)

---

Need a re-review? Want to dispute a finding? Mention @claude and include #update-review.
(For ad-hoc questions or fixes, just @claude — no hashtag.)

[komalali]

Can we add a code sample for one of the new resources?

[komalali]

"There is no implicit v0 to api, by design."

What does that mean?

[komalali]

Suggested change

	If you want to take the preview for a spin:
	If you want to take the expanded provider for a spin: