--- title: "Papyrs Integration" description: "Papyrs is the drag-and-drop intranet and wiki. Agents create and update pages and the widgets inside them, read and write form records, search the site, look up the people directory, and follow the activity stream." url: https://flowrunner.ai/integrations/papyrs date_modified: 2026-09-04T14:52:04-07:00 --- # Papyrs [Productivity](https://flowrunner.ai/integrations/category/project-management-productivity) Papyrs is the drag-and-drop intranet and wiki. Agents create and update pages and the widgets inside them, read and write form records, search the site, look up the people directory, and follow the activity stream. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 16 actions · API key · available [Papyrs website](https://papyrs.com/) · [Platform Documentation](https://papyrs.com/docs/api) · Capability data verified 2026-08-24 1. A process closes upstream and owes the company a written record, such as a completed onboarding or a shipped policy change 2. The agent gathers the facts from the systems that hold them and assembles the page as columns of widgets 3. List People returns the directory so the audience can be expressed as the user ids Papyrs actually wants 4. Search confirms no page already covers this, so the intranet gains a page rather than a duplicate 5. The agent builds the whole page in one Create Page call rather than adding widgets one at a time against a tight rate limit 6. Post To Activity Stream announces the new page to everyone with access 7. Before the page is created, a person confirms the permission map, because a page published to the wrong audience cannot be edited, only deleted and rebuilt at a new URL ## What This Integration Enables Papyrs is an intranet made of widgets rather than documents, and its API is honest about it. A page is a list of columns, each holding text boxes, headings, attachments, and forms. There is no page update route at all. A page is changed by creating, updating, and deleting individual widgets on it, and updating a widget gives it a new id while returning the old one alongside. The rate limit is six requests every sixty seconds, which is tight enough that editing a page widget by widget is a real cost rather than a footnote. The practical conclusion, and the way this connector is best used, is to build a page whole and let the source systems own the truth. That makes Papyrs a good target for agents and a poor target for scripts. FlowRunner agents assemble a page from the systems that already hold the facts, publish it in one call, read the form submissions people make on it, search the whole site across pages, files, people, form entries, and comments in a single query, and post into the activity stream and page discussions. Where a step is consequential, [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) puts a person in front of it rather than trusting a template. Every action is built and verified against Papyrs' published v1 API. ### Without FlowRunner **The intranet decays quietly**: Pages are written once and nobody notices when the process behind them changed **Form entries live where nobody looks**: Submissions sit inside the page they were made on and are read only when somebody remembers to check **Audience set by habit**: Permissions are chosen at creation time by whoever happened to be writing, with no consistent rule ### With FlowRunner **Pages assembled from the source**: An agent builds the page from the systems that hold the facts, so the record matches what actually happened **Submissions become work**: Form records are read on a schedule and routed into the tools where the work gets done **Audience is an explicit decision**: The permission map is built from the People Directory and confirmed by a person before the page exists ## Use Case Scenarios ### Form submissions that turn into work A department runs its requests through a Papyrs form: equipment, access, travel, whatever the team has standardized. On a schedule, the agent calls List Page Records to read the submissions made on that page. Each record comes back as a list of field and value pairs rather than an object, so the agent reads fields by name and normalizes them before anything downstream sees them. Complete requests open a ticket in [ServiceNow](https://flowrunner.ai/integrations/servicenow) or a task in [Asana](https://flowrunner.ai/integrations/asana) with the submitter resolved against List People. Incomplete ones get a comment back on the page through Post Comment To Page, on the page's own discussion where the submitter is already looking. The form stays where people know how to use it; the work leaves it. ### The policy page that rebuilds itself A procedure changes in the system of record. Rather than asking someone to remember that the intranet says something different, the agent assembles the new page: headings, the current steps, the owner, and the effective date, plus the source document as an attachment widget. Because there is no update route, the agent uses Create Page to publish the new version whole, then Post To Activity Stream so everyone with access sees that it moved. The previous page is retired with Delete Page only after the new one is confirmed live. The result is an intranet page whose contents are downstream of the process rather than a snapshot of what it looked like the day someone wrote it. ### A search that answers a question instead of a person Somebody asks in [Slack](https://flowrunner.ai/integrations/slack) where the expense policy lives. The agent runs Search, which queries pages, files, people, form entries, and comments at once and labels each result with its kind, so the agent can prefer a page over a stray comment that happens to mention the phrase. It replies with the page and the specific widget that answers the question, pulled with Get Page. When nothing matches, it says so and offers to open a request for the page to be written, rather than returning the closest thing and letting the asker work out that it is wrong. ## Human-in-Loop Highlight The gate here sits before the page exists, which is unusual, and it exists because Papyrs cannot patch a mistake. Leaving Permissions out of Create Page gives administrators edit access and everyone else none, unless the group has a default template. A page published that way is not broken in any visible sense. It is simply invisible to the people it was written for, and since there is no page update route, the fix is to delete it and create it again, which loses its id and its URL and every link anyone has already shared. So the publishing agent builds the permission map from List People, resolves each name to the user id Papyrs wants, and then stops: "Publishing 'Expense Policy 2026' to the Finance group, 14 people by user id, plus edit for the two policy owners. Nobody outside that map will see the page, and this cannot be changed afterwards without republishing at a new URL. Confirm the audience?" A person confirms, and the page is created once, correctly, at a URL that will keep working. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 16 actions ### Pages 5 - **List Pages** Returns every page the token's user can see, newest first, with title, folder, and tags. It does not carry contents, so a workflow that needs the widgets follows with Get Page. - **Get Page** Returns one page with its whole contents as columns of widgets, plus its permission and notification maps keyed by user id. This is where widget ids come from. - **Create Page** Creates a page with its contents in one call. Building a page whole here is much cheaper than adding widgets one at a time, and the permission map decides who can see it at all. - **Delete Page** Deletes a page and everything on it. Used to retire a superseded page after its replacement is confirmed live. - **List Page Records** Returns the form submissions made on a page. Each record is a list of field and value pairs rather than an object, so a workflow reads fields by name. ### Widgets 6 - **Get Widget** Returns one widget from a page. The kind has to be named, because Papyrs routes text boxes, headings, and attachments to different endpoints rather than looking an id up. - **Create Text Widget** Adds a text box or a heading to a page. Format decides how the value is read, and it defaults to HTML, so a value containing angle brackets is treated as markup. - **Update Text Widget** Rewrites a text box or heading. Papyrs assigns the widget a new id on every update and returns the old one alongside, and both keep working, so a workflow that caches ids should keep the original. - **Create Attachment Widget** Uploads a file onto a page as a new attachment widget. Used to put the source document beside the page that summarizes it. - **Update Attachment Widget** Uploads a file into an existing attachment widget, replacing what was there. Like the text widgets, its id changes on update. - **Delete Widget** Removes a widget from a page. The precise edit, used when rebuilding the whole page would cost more than it is worth. ### Search 1 - **Search** Runs a query through Papyrs' own search engine across pages, files, people, form entries, and comments at once, with each result naming its kind so a workflow can filter after the fact rather than choosing a scope up front. ### People 2 - **List People** Returns everyone in the People Directory, newest first, including who has been invited but has not accepted yet. This is where the user ids for permission maps come from. Guests invited to a single page are not included. - **Delete Person** Permanently deletes a user from the account, and only a site administrator can do it. A workflow reaching for this one should be part of an offboarding process with its own approval, not a cleanup script. ### Feed 2 - **Post To Activity Stream** Posts a message to the account's activity stream, where everyone with access sees it. Used to announce that something people rely on has changed. - **Post Comment To Page** Posts a comment onto a page's discussion, which is where a reply to a form submission belongs. It requires the page to have a Discussion widget, since without one there is nothing to post to. ## Frequently Asked Questions ### What can FlowRunner do with Papyrs? FlowRunner agents can run List Pages, Get Page, and Create Page in Papyrs, plus 13 more actions. ### Does connecting Papyrs to FlowRunner require OAuth? No. Papyrs connects to FlowRunner with an API key, no OAuth flow required. ### Can Papyrs trigger a FlowRunner workflow automatically? Papyrs doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Papyrs?** This integration exposes Papyrs to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/papyrs. Site index: https://flowrunner.ai/llms.txt