Repository navigation
chore(release): promote develop to main - #179
Merged
Merged
Conversation
…2) (#164) Lockfile-only, semver-compatible bumps: 4 high and 1 low closed, 48 -> 42 total. The 42 that remain both need a major bump of a direct dependency and so are not appropriate for a lockfile sweep — recorded in the Change Request issue instead: - @faker-js/faker (high), reached through postman-collection; fix is docusaurus-theme-openapi-docs@2.1.3, a major. - @tiptap/core (moderate, 36 instances across the tiptap extension set); fix is the tiptap 3.31.3 line, also a major. Not addressed here: vendor/docusaurus-plugin-llms is a git submodule, so it has no lockfile entry in this repo and Dependabot cannot see it. Its own tree audits at 44 advisories, but every one is in upstream's dev/test toolchain rather than anything this site ships. Noted in the CR issue. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
added 14 commits
September 23, 2026 11:57
…ining docs/API/*.api.mdx Rolls out the PR #155 pattern (real description, when-to-use, curl example, verified request/response, common-errors table, related links) to every docs/API/*.api.mdx page under 300 live words, excluding the 3 pages #155 already enriched (delete-template, get-templates-and-folders, upload-template-with-optional-default-values) and the turbodocx-api-documentation info page. Covered: 3 template endpoints (edit-template-metadata, get-template-by-id, extract-template-placeholders-and-generate-preview), all 10 TurboSign webhook endpoints (create/get/update/delete/notify/test/regenerate-secret/ list-deliveries/replay-delivery/get-stats), and 8 tag/variable endpoints (create/read/update-tag, delete-tags-by-i-ds, create-image-variable-folder, read-variables-folder, update-variable-by-id, delete-variables-by-i-ds). Every path, method, field, response shape, and error was verified against the route/handler code in RapidDocxBackend (Template, Webhooks, Tag, Variable routes + handlers), not the OpenAPI spec, which is stale in several places. Also fixed two pre-existing frontmatter issues on webhook pages: an em-dash and an inaccurate "soft-delete" claim on delete-webhook (the handler hard-deletes the row).
…/SDKs 10 deliverable-*/partner-* pages carried a full copy of the generic Error Handling intro + status-code table already documented once on each language's canonical page (javascript.md, python.md, go.md, php.md, java.md). template-detector.mjs flagged the same 5-word phrases across ~17 files, matching the URL Inspection evidence that javascript, python, java, quote-javascript, webhooks-java, deliverable-go, and deliverable-php are crawled/discovered but not indexed. Replaced the duplicated table on each deliverable-*/partner-* page with a short paragraph naming the errors that operation actually raises (verified against /home/nicolas/repos/SDK), followed by a link to the language's own Error Handling reference for the full table. Kept the already-differentiated code samples and product-specific notes (Go's errors.As, PHP's typed exceptions, Java's nested TurboDocxException.* classes, partner's IOException/409-conflict callouts) as-is. Also: - Fixed a real bug found while verifying code samples: index.md's PHP error handling example called $e->getCode(), but PHP's Exception::getCode() is hardcoded to 0 by TurboDocxException's constructor; the real field is $e->errorCode. - Fixed two broken links (go.md, java.md pointed at /docs/TurboSign/API-Signatures instead of the correctly-encoded .../API%20Signatures used elsewhere in the same files) and two broken anchors (partner-php.md, partner-javascript.md linked to #orguserrole-organization-users, truncated; the real heading slugifies to #orguserrole-organization-users-and-org-api-keys). - Shortened 11 frontmatter descriptions over 160 chars (agent-skills + 5 quote-*/5 webhooks-* pages) to <=155 chars, language + product first. Not fixed (noted for the owner): docs/SDKs/ruby.md and deliverable-ruby.md 404 live but still get search impressions. This is intentional (draft: true, set in 40efd12 because the gem isn't on RubyGems yet); Docusaurus excludes draft pages from the production build. If those impressions are worth capturing, that needs a redirect decision, not a content change.
…s, fix canonical tables
Follow-up to the previous commit after review found three real gaps:
1. The 5 canonical per-language pages (javascript.md, python.md, go.md,
php.md, java.md) still shared the generic "The SDK provides typed
error(s)/exception(s) for different ... scenarios" intro sentence
verbatim, and 3 of them (javascript, python, java) are themselves
evidence pages (crawled/discovered but not indexed). Rewrote each
intro to state the real, verified idiom for that language: Go's
errors.As + embedded struct, PHP's readonly statusCode/errorCode
(and the getCode()-returns-0 gotcha), Java's nested
TurboDocxException.* classes with getCode()'s orDefault fallback,
JS's code passthrough from the API response, Python's DEFAULT_CODE
class attribute and Exception-subclass catch order. Sourced from
packages/{go,php,java,js,py}-sdk directly (errors.ts,
TurboDocxException.java, TurboDocxException.php, http.py).
2. deliverable-go.md and deliverable-php.md linked to go.md/php.md as
the canonical Error Handling reference for classes those pages
didn't actually document: go.md's table was missing ConflictError
(it exists in http.go) and php.md's was missing
AuthorizationException and ConflictException (both exist in
packages/php-sdk/src/Exceptions/). Added the missing rows so the
canonical pages actually contain what the product pages point to.
3. Removed unverified "most commonly" frequency language from the 10
deliverable-*/partner-* pages' Error Handling intros (added in the
previous commit); rephrased as "returns/throws/raises X when Y"
without a frequency claim.
Also swept remaining em-dashes in the 5 base-language pages, now that
they have real body edits (previously only go.md/java.md were fully
swept, for their link fixes).
…andling intro
The previous wording implied errors.As was needed specifically because
TurboDocxError is embedded by value ("so match... rather than a type
switch"), which isn't the right causal link and isn't accurate SDK
guidance (a plain type switch would work fine on the unwrapped return
values; errors.As is just the more defensive/robust choice against any
future wrapping). Reworded to state two independently-true facts: by-
value embedding promotes the fields for direct access, and the SDK's
own example already uses errors.As.
Second review pass found more accuracy issues: - go.md/java.md/python.md's Code-field descriptions said the machine- readable code is "always populated". True only for the 7 named subclasses (each has a default). The bare base error returned for an unmapped HTTP status (e.g. an unexpected 5xx) can have an empty/null code, verified: Go's defaultErrorCode() returns "" in its default case, Java's HttpClient.java falls through to `new TurboDocxException(message, code, ...)` with no fallback, and Python's base TurboDocxError has DEFAULT_CODE = None. Qualified all three. - index.md's Java Error Handling tab imported `com.turbodocx.sdk.*` (wrong package; the SDK's actual package is `com.turbodocx`, no `.sdk`), used a response type SigningResult that doesn't exist, and called `turboSign.sendSignature(...)` on a bare variable instead of `client.turboSign().sendSignature(...)`. All three didn't match java.md's own (correct) examples. Fixed to match. - Five deliverable-*.md pages claimed ValidationError fires when a variable is missing "placeholder or mimeType". Checked RapidDocxBackend's actual generate-deliverable handler (DeliverableGenerationHandlers.ts): the Variable interface has `placeholder: string` (required) but `mimeType?: string` (optional). Dropped the incorrect mimeType half of the claim.
…ied field claim
Third review pass on index.md's Error Handling tabs (the same code
block already touched for the PHP getCode()/Java package fixes):
- Go tab: errors.As(err, &turboErr) targeted *sdk.TurboDocxError only.
Go's errors.As requires the target's concrete type to match; the 6
named error types (ValidationError, AuthenticationError, ...) are
distinct types from TurboDocxError even though they embed it, and
none implement Unwrap/As, so this silently matched nothing except
the generic unmapped-status case. The VALIDATION_ERROR branch shown
was dead code. Fixed to match *sdk.ValidationError directly.
- Python tab: printed e.message, but TurboDocxError.__init__ never
sets self.message and Python 3's Exception doesn't have one either,
so this raises AttributeError at runtime. Fixed to {e} (str(e)),
matching python.md's own examples.
- Java tab: missing the com.turbodocx.models.* import that
SendSignatureResponse needs (follow-up to the package-name fix in
the previous commit).
- The "code is always populated" line above these tabs had the same
gap already qualified on the language pages. Qualified it the same
way.
Also corrected the 5 deliverable-*.md pages' claim that ValidationError
fires on a variable missing "placeholder or mimeType". Checked
RapidDocxBackend's DeliverableGenerationHandlers.ts: the Variable
interface has placeholder required, mimeType optional (the reverse of
what was claimed), and I could not find where a missing placeholder is
actually validated at the HTTP boundary (the handler doesn't appear to
check it before using it). Rather than assert an unverified 400, all 5
now say "missing a required field" without naming one, matching
deliverable-java.md's already-safe phrasing.
…rors broke the build) 11 SDK pages (agent-skills, quote-*, webhooks-*) had unquoted description values like 'TurboQuote Go SDK: ...'; YAML reads the second ': ' as a mapping and Docusaurus fails to build. Quote them.
Playbook task: meta-length-checker (Google truncates descriptions over ~160 chars). Rewrites 26 frontmatter descriptions to <= 155 chars, keeping the main keyword first. Frontmatter description lines only. docs/SDKs/* and docs/API/* are left to their own Trace PRs. Three embedded-signing pages that exist only on feature/turbosign-embedded-identity are not included here.
Fixed broken internal links across docs site: - 25 Wrike integration links (converted relative paths to absolute /docs/ paths) - 6 Pipelines links (converted relative paths to absolute /docs/ paths) - 5 TurboDocx Templating links (converted relative paths, removed non-existent page links) - 3 TurboQuote links (converted relative paths) - 2 Dashboard links (converted relative paths) - 2 TurboSign links (converted relative/absolute paths) Reduced broken links from 56 to 19 (13 in SDK files owned by other PR, 2 commented-out images, 1 directory link in Webhooks). Excluded from fixes: - Links within docs/SDKs/ and docs/API/ (owned by SDK/API enrichment PRs) - Redirected external links that resolve to current URLs - Rate-limited or auth-gated external URLs (false positives) Test plan: - Before: 56 broken links found - After: 19 broken links (all in SDK files or commented content) - Internal link fixes: ./path -> /docs/path conversion - Removed broken links to non-existent pages, keeping text
The broken-link checker resolved Docusaurus file-relative links (./setting-up-automation.md, ../../TurboSign/Webhooks.md) against the site root instead of the source file's directory, so it flagged many working links as broken. This reverts those 25 files back to their original relative links, which resolve correctly on the live site. It also removes the '(coming soon)' text the previous commit added for genuinely dead links, since that publicly promises features that may not exist (one of them, Webhook Integration, already has a real page). The three files with real dead links now either point to the correct existing page or have the dead bullet removed: - Webhook Integration / Webhook Configuration -> /docs/TurboSign/Webhooks - Bulk Document Generation / Bulk Processing -> removed (no matching page) - Template Version Management -> removed (no matching page) - Template Management Guide -> removed (no matching page) - Integration Examples -> removed (/docs/Integrations 404s live; no index page exists for it) - API Authentication -> reverted to /docs/API/turbodocx-api-documentation (the original target, confirmed live 200; the previous commit had pointed it at /docs/API/Deliverable%20API instead)
/ renders ~1 word to a first-pass crawler: it's a client-side redirect (<Redirect to="/docs" /> from @docusaurus/router) to the real hub at /docs. Per config/noindex-strategy.json (auto-noindex under 100 words), add a noindex,follow meta tag via @docusaurus/Head and exclude / from the sitemap plugin's ignorePatterns so the two signals agree. A server-side redirect (e.g. a Cloudflare Pages static/_redirects entry) would be the long-term fix so crawlers and users never hit the client-rendered stub at all, but that's out of scope here.
This was referenced Sep 23, 2026
2 of 3 tasks
2 tasks
The Create Webhook and Regenerate Webhook Secret response examples used realistic-looking whsec_ values (TurboDocx format: whsec_ + 64 hex), which secret scanners report as a Stripe webhook secret. Replace them with an obvious placeholder.
nicolasiscoding
marked this pull request as ready for review
September 23, 2026 18:49
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promotes
developtomain. Merging this deploys docs.turbodocx.com to production —deploy.ymlruns on push tomain.What's in this release (2 commits)
CI fix (production-blocking)
cloudflare/pages-actionwas removed from GitHub (404 ongh api repos/cloudflare/pages-action); every deploy offmaincurrently fails at "Set up job" with "Unable to resolve actions. Cannot access repositories 'cloudflare/pages-action'". Replaces the deploy step withcloudflare/wrangler-action@v4(command: pages deploy build --project-name=turbodocx-docs), sameapiToken/accountId/gitHubTokensecrets. Verified green ondevelopvia fix(ci): deploy with cloudflare/wrangler-action (pages-action was removed) #178's PR-triggered deploy check. Closes fix(ci): deploys fail, cloudflare/pages-action removed from GitHub #177.Dependencies
Note for whoever merges
main's last few production deploys all predate Cloudflare removingpages-action, so they show green from before the break — they are not evidence this is already fixed onmain. This PR's merge is the first deploy onmainwith the corrected action; watch theDeploy to Cloudflare Pagescheck on this PR and the post-merge run onmainfor green, and confirm in the Cloudflare Pages dashboard that the post-merge run lands as a Production deployment (not a preview) before considering this done.