If your docs live in GitBook, an action's content draft can now go straight to a GitBook change request. Your team reviews and merges it in GitBook, under your space's own merge rules. DevTune never merges.
Connect GitBook in project settings under Content repositories with a GitBook personal access token. We recommend a dedicated GitBook member with the Editor role, so the change requests aren't attributed to one person and keep working when someone leaves. The connection shows whose token it is. Then map each part of your site to the GitBook space that publishes it.
An action with a draft for a page under a mapped space shows Create change request. DevTune writes the draft into the change request and checks that GitBook stored it as written. When you open a newer draft, DevTune updates the same change request. Close change request archives it.
When the change request is merged in GitBook, DevTune marks the action live at GitBook's merge time, and its before/after window opens in Results from that moment. A change request that's archived and later reopened is still followed for 90 days.
Automatic change requests work as they do for GitHub. Turn them on per source, and each finished draft opens or updates its change request. When a draft refreshes an existing page, the Section Editor quotes the live GitBook page, so its edits match what the change request changes.
If the token stops working or loses access to a space, DevTune marks the connection or space for reconnecting and tells you once, in the app and by email. Replace token restores a connection without remapping anything, and a space comes back once the token can edit it again.
GitBook change requests are available on every plan with content drafts. Over API v2 and MCP, the same draft pull request endpoints and tools work for GitBook sources. Pull requests carry provider and space, content sources carry provider, space and connection, and you can pass pagePath to choose the page. See GitBook change requests for setup.