diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml index d4834762..5ca58387 100644 --- a/.github/workflows/deploy.yml +++ b/.github/workflows/deploy.yml @@ -17,6 +17,10 @@ jobs: steps: - name: Checkout uses: actions/checkout@v4 + with: + # Full history so showLastUpdateTime and the sitemap use each + # doc's real last commit date instead of the build date. + fetch-depth: 0 - name: Setup Node.js uses: actions/setup-node@v4 diff --git a/docs/Advanced-Configuration/SCIM-Provisioning.md b/docs/Advanced-Configuration/SCIM-Provisioning.md index 3cf1386e..3e6eb61f 100644 --- a/docs/Advanced-Configuration/SCIM-Provisioning.md +++ b/docs/Advanced-Configuration/SCIM-Provisioning.md @@ -1,6 +1,7 @@ --- -title: SCIM User Provisioning -description: Set up SCIM 2.0 provisioning so your identity provider can create, update, and deactivate TurboDocx accounts automatically. +title: "SCIM Provisioning: Automate User Accounts" +sidebar_label: SCIM User Provisioning +description: Set up SCIM provisioning (SCIM 2.0) so your identity provider creates, updates, and deactivates TurboDocx user accounts automatically. keywords: - scim provisioning - user provisioning @@ -11,9 +12,11 @@ keywords: - automated user management --- -# SCIM User Provisioning +# SCIM Provisioning -TurboDocx supports SCIM 2.0 user provisioning, so your identity provider can automatically create, update, and deactivate TurboDocx accounts within your organization as employees join, change roles, or leave. SCIM manages accounts; pair it with [Single Sign-On](./Single-Sign-On.md) if you also want your identity provider to handle authentication. +SCIM provisioning lets your identity provider create, update, and deactivate TurboDocx accounts in your organization automatically as employees join, change roles, or leave. TurboDocx supports the SCIM 2.0 User schema. SCIM manages accounts; pair it with [Single Sign-On](./Single-Sign-On.md) if you also want your identity provider to handle authentication. + +**In short:** TurboDocx support issues your organization a SCIM base URL and bearer token, you enter both in your identity provider's provisioning app, and from then on account changes in your identity provider flow into TurboDocx without manual user management. Removing someone in your identity provider takes away their TurboDocx access but keeps their documents. ## Prerequisites @@ -28,6 +31,27 @@ TurboDocx supports SCIM 2.0 user provisioning, so your identity provider can aut 3. Map your identity provider's user attributes to the SCIM 2.0 User schema TurboDocx expects: `name.givenName`, `name.familyName`, `emails` (with a primary address), and `active`. Most SCIM apps do this mapping by default. 4. Turn on provisioning and run your identity provider's test or "provision a single user" action first, then confirm the account appears in TurboDocx before assigning the rest of your users. +### Example: the request your identity provider sends + +You don't write this request yourself; your identity provider sends it when you assign a user. It is shown here so you can check your attribute mapping. A new user arrives as a standard SCIM 2.0 `POST` to the `/Users` endpoint under your base URL: + +```http +POST {your SCIM base URL}/Users +Authorization: Bearer {your SCIM token} +Content-Type: application/scim+json + +{ + "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], + "externalId": "00u1a2b3c4d5e6f7g8h9", + "userName": "jane.doe@example.com", + "name": { "givenName": "Jane", "familyName": "Doe" }, + "emails": [{ "value": "jane.doe@example.com", "type": "work", "primary": true }], + "active": true +} +``` + +TurboDocx uses the primary email (or the first email if none is marked primary) as the account's email address and answers `201 Created` with the provisioned user. + ## What SCIM provisioning does - **Create:** a new user assigned in your identity provider creates a matching TurboDocx account in your organization. If an inactive TurboDocx account with the same email already exists, SCIM reactivates it instead of creating a duplicate. diff --git a/docs/Integrations/Fireflies.md b/docs/Integrations/Fireflies.md index 4c0f2ffe..08f751dd 100644 --- a/docs/Integrations/Fireflies.md +++ b/docs/Integrations/Fireflies.md @@ -97,7 +97,7 @@ Your API key is like a password - never share it publicly or include it in email ## Step 2: Configuring TurboDocx -### 🔧 How to Configure Fireflies in Settings +### How to Configure Fireflies in Settings 1. Click your **account avatar** at the bottom of the left sidebar, then click **Settings** diff --git a/docs/Pipelines/Cloud-Connectors.md b/docs/Pipelines/Cloud-Connectors.md index 518d1bd3..088d5ea9 100644 --- a/docs/Pipelines/Cloud-Connectors.md +++ b/docs/Pipelines/Cloud-Connectors.md @@ -1,9 +1,12 @@ --- -title: Cloud Connectors (Enterprise) +title: "Pipeline Connectors: Private Cloud Connector" +sidebar_label: Cloud Connectors (Enterprise) sidebar_position: 6 -description: Cloud connectors resolve signer details from systems behind your firewall without inbound access. Secure lookup from databases and internal APIs. +description: A private cloud connector lets TurboDocx pipelines look up signers in databases and internal APIs behind your firewall, with no inbound access. keywords: - cloud connectors + - pipeline connectors + - private cloud connector - signer resolution - internal database lookup - behind firewall integration @@ -17,9 +20,11 @@ keywords: - white-glove setup --- -# Cloud Connectors (Enterprise) +# Pipeline Connectors: Private Cloud Connector (Enterprise) -Sometimes the details you need to send a document for signature, such as the signer's name and email, live in a system TurboDocx can't reach directly: an internal database behind your firewall, or an internal API that never faces the public internet. A **Cloud connector** bridges that gap, securely, without ever exposing your systems. +A private cloud connector is the pipeline connector for systems TurboDocx can't reach directly. Sometimes the details you need to send a document for signature, such as the signer's name and email, live in an internal database behind your firewall or an internal API that never faces the public internet. The connector bridges that gap securely, without exposing those systems. + +**How it works in practice:** you run a small worker inside your own network. When a pipeline needs a signer from one of your private systems, the worker picks up the lookup over outbound HTTPS, queries your system locally, and sends back only the signer's name and email. You open no inbound firewall ports, and our team sets it up with you.
diff --git a/docs/SDKs/agent-skills.md b/docs/SDKs/agent-skills.md index 0eeb59f2..bc2bfca1 100644 --- a/docs/SDKs/agent-skills.md +++ b/docs/SDKs/agent-skills.md @@ -182,4 +182,3 @@ The skill is open source at **[github.com/TurboDocx/quickstart](https://github.c - [SDKs Overview](./index.md) - [TurboSign JavaScript SDK](/docs/SDKs/turbosign?language=js) - [TurboSign Python SDK](/docs/SDKs/turbosign?language=python) -- [TurboPartner JavaScript SDK](./partner-javascript.md) diff --git a/docs/TurboSign/How-to-Configure-Signature-Appearance.md b/docs/TurboSign/How-to-Configure-Signature-Appearance.md index 53e9de13..306d83c8 100644 --- a/docs/TurboSign/How-to-Configure-Signature-Appearance.md +++ b/docs/TurboSign/How-to-Configure-Signature-Appearance.md @@ -1,8 +1,10 @@ --- -title: How to Configure Signature Appearance +title: Custom Signature Appearance in TurboSign +sidebar_label: How to Configure Signature Appearance sidebar_position: 8 description: "Control how signed fields look on TurboSign PDFs: toggle the signature outline, label and verification hash, and how locked fields appear to signers." keywords: + - custom signature appearance - turbosign signature appearance - signature outline - verification hash @@ -13,19 +15,21 @@ keywords: - signing portal appearance --- -# How to Configure Signature Appearance +# Custom Signature Appearance in TurboSign -TurboSign stamps each signed field onto the finished PDF with a thin outline, a small label, and a verification hash. It also decides how **locked fields** — read-only values imported onto a document that the signer can't change — appear while someone is signing. You can control all of this for your whole organization from one settings screen. +Custom signature appearance controls how each signed field looks on the finished PDF. By default, TurboSign stamps every signed field with a thin outline, a small label, and a verification hash. It also decides how **locked fields** (read-only values imported onto a document that the signer can't change) appear while someone is signing. You set all of this for your whole organization from one settings screen. + +**Where it applies:** an admin chooses the options once in **Settings** > **Features and integrations** > **Configure E-Signature**, and they apply to every new signature request in the organization, whether it is sent from the app, a pipeline, or the TurboSign API. Your API calls don't need to pass any appearance options. This guide shows you how to find and change the **Signature Appearance** and **Locked Fields Rendering** options. :::note What these options do -**Signature Appearance** — how each signed field looks on the finished PDF: -- **Show signature outline and label** — the thin border and caption drawn around each signed field on the PDF. -- **Show verification hash** — the short verification code printed beneath a signature. +**Signature Appearance:** how each signed field looks on the finished PDF: +- **Show signature outline and label:** the thin border and caption drawn around each signed field on the PDF. +- **Show verification hash:** the short verification code printed beneath a signature. -**Locked Fields Rendering** — how locked (read-only) fields look to the signer in the signing portal: -- **Show locked fields with grey background** — draw each locked field as a grey box, or, when turned off, render its value as plain document text (and hide blank locked fields entirely) for a cleaner page. +**Locked Fields Rendering:** how locked (read-only) fields look to the signer in the signing portal: +- **Show locked fields with grey background:** draw each locked field as a grey box, or, when turned off, render its value as plain document text (and hide blank locked fields entirely) for a cleaner page. All three are **on** by default, so your documents look the same until you change them. These settings apply to every new signature request in your organization. ::: @@ -78,5 +82,5 @@ This setting changes what signers see in the **signing portal**; it does not cha :::tip -Turning the two **Signature Appearance** options off gives a cleaner, minimal signature stamp — useful when you want the signature to blend into a formal document layout. Turning **Show locked fields with grey background** off similarly declutters the signing page for the recipient. Signed PDFs still carry their full audit trail either way. +Turning the two **Signature Appearance** options off gives a cleaner, minimal signature stamp. This is useful when you want the signature to blend into a formal document layout. Turning **Show locked fields with grey background** off similarly declutters the signing page for the recipient. Signed PDFs still carry their full audit trail either way. ::: diff --git a/docs/TurboSign/embedded-signing/index.md b/docs/TurboSign/embedded-signing/index.md index 37574bff..913f1642 100644 --- a/docs/TurboSign/embedded-signing/index.md +++ b/docs/TurboSign/embedded-signing/index.md @@ -1,9 +1,9 @@ --- -title: Embedded Signing +title: "Embedded Signing: Sign Inside Your Own App" slug: /TurboSign/embedded-signing sidebar_label: Overview sidebar_position: 1 -description: Embed TurboSign in your own app and verify each signer with a one-time passcode, your own identity provider, or an explicit override. Request a signing URL at the moment a signer is ready, then pick a step-by-step guide. +description: Embedded signing puts TurboSign inside your own app. Request a signing URL when a signer is ready and verify them with a passcode or your identity provider. keywords: - embedded signing - identity verification diff --git a/docusaurus.config.js b/docusaurus.config.js index bc45283a..e5ebb1a4 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -184,6 +184,10 @@ const config = { customCss: require.resolve('./src/css/custom.scss'), }, sitemap: { + // comes from each doc's last git commit date, so CI must + // check out the full history (fetch-depth: 0 in deploy.yml); a + // shallow clone would stamp every page with the build date. + lastmod: 'date', // '/' is a client-side redirect to '/docs' (the real hub) and // carries a noindex meta tag; exclude it from the sitemap too so // the two signals don't conflict. diff --git a/src/theme/DocBreadcrumbs/StructuredData/index.js b/src/theme/DocBreadcrumbs/StructuredData/index.js new file mode 100644 index 00000000..fb408a8b --- /dev/null +++ b/src/theme/DocBreadcrumbs/StructuredData/index.js @@ -0,0 +1,25 @@ +import React from 'react'; +import useDocusaurusContext from '@docusaurus/useDocusaurusContext'; +import { applyTrailingSlash } from '@docusaurus/utils-common'; +import OriginalStructuredData from '@theme-original/DocBreadcrumbs/StructuredData'; + +// Category index pages (docs/**/index.md) carry a raw permalink with a trailing +// slash, e.g. /docs/SDKs/. The visible breadcrumb normalizes it to match +// `trailingSlash: false`, but the BreadcrumbList JSON-LD uses the raw href, so it +// pointed search engines at URLs that 308-redirect. Normalize the hrefs the same +// way does before the original component builds the structured data. +export default function DocBreadcrumbsStructuredData(props) { + const { siteConfig } = useDocusaurusContext(); + const breadcrumbs = props.breadcrumbs.map((item) => + item.href + ? { + ...item, + href: applyTrailingSlash(item.href, { + trailingSlash: siteConfig.trailingSlash, + baseUrl: siteConfig.baseUrl, + }), + } + : item + ); + return ; +} diff --git a/static/_headers b/static/_headers new file mode 100644 index 00000000..72952a6c --- /dev/null +++ b/static/_headers @@ -0,0 +1,12 @@ +# Cloudflare Pages response headers (copied to the build root from static/). +# Every doc page / also serves a markdown twin at /.md (see AGENTS.md +# "Every doc page ships a markdown twin"). The twins are crawlable, so each one +# points search engines at its HTML page as the canonical URL. +# The splat captures everything between /docs/ and .md, e.g. +# /docs/API/delete-webhook.md -> https://docs.turbodocx.com/docs/API/delete-webhook +/docs/*.md + Link: ; rel="canonical" + +# The /docs hub twin lives at /docs.md, which the rule above does not match. +/docs.md + Link: ; rel="canonical"