Reference · built on requestConnectorFiles, documents & spreadsheets

Superhuman Docs

Docs, pages, tables, and rows from Superhuman Docs, formerly Coda, through the Docs API v1.

Request accessPricing ↗

About

Superhuman Docs, formerly Coda, is a document editor whose pages hold tables, buttons, formulas, and controls. Teams run meeting notes, trackers, and small internal tools inside a doc. The Docs API v1 lists docs, pages, tables, columns, and rows, writes rows asynchronously, and can press a button or trigger a webhook-invoked automation inside a doc.

Through Fibric, an operator polls the tables behind a tracker, compares rows with your other systems, and proposes an upsert, a row update, or a button press. You approve first. The edit is queued once, confirmed through its mutation status, and logged in a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Superhuman Docs and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Docs the token can reach through GET /docs, and pages of a doc through GET /docs/{docId}/pages
  • Tables and views through GET /docs/{docId}/tables, with columns from GET /docs/{docId}/tables/{tableIdOrName}/columns
  • Rows through GET /docs/{docId}/tables/{tableIdOrName}/rows, with valueFormat simple, simpleWithArrays, or rich
  • Named formulas and controls through GET /docs/{docId}/formulas and GET /docs/{docId}/controls
  • Page content exported through POST /docs/{docId}/pages/{pageIdOrName}/export and its status endpoint
  • The doc, page, or table behind a browser link through GET /resolveBrowserLink

Proposed actions

  • Target capability: propose inserting or upserting rows through POST /docs/{docId}/tables/{tableIdOrName}/rows, keyed on chosen columns
  • Target capability: propose a row update through PUT /docs/{docId}/tables/{tableIdOrName}/rows/{rowIdOrName}
  • Target capability: propose pushing a button on a row through the buttons endpoint, which runs whatever action the button holds
  • Target capability: propose triggering a webhook-invoked automation through POST /docs/{docId}/hooks/automation/{ruleId}
  • Target capability: propose a new page through POST /docs/{docId}/pages

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Prep from the meeting doc

    The operator reads the agenda page and the decisions table before a meeting, then proposes a short brief as a new page listing open items and what changed since the last one.

    With Meeting Prep

  • Follow up rows past their date

    The operator polls an actions table, finds rows whose due date has passed, and proposes a row update that sets a follow-up flag, plus a note of who was asked.

    With Action Follow-up

  • Weekly review from the tracker

    Each week the operator reads status columns across a table, computes counts by status, and proposes a summary page for the review.

    With Weekly Review

  • Onboarding checklist as rows

    For each new hire the operator proposes upserting checklist rows keyed on the hire's name, then pushes the doc's notify button once you approve.

    With Onboarding Checklist

Requirements

  • A Superhuman Docs account whose user can reach the docs in question; the token acts as that user
  • A token restricted to the docs or tables the operator needs, with write access only where it proposes changes
  • Names or ids of the base tables it writes to; inserts and upserts do not work on views
  • A polling schedule, since the API documents no outbound webhooks
Authentication
An API token created under My account in Superhuman Docs, sent as Authorization: Bearer; a token can be restricted to read or write, and to named docs or tables.

Limits

  • Reads are limited to 100 requests per 6 seconds per user, writes to 10 per 6 seconds, and listing docs to 4 per 6 seconds
  • Writes return 202 and apply a few seconds later; success is confirmed through GET /mutationStatus/{requestId}, kept for about a day
  • Reads come from the latest snapshot of the doc and can trail what a browser shows
  • Row inserts and upserts target base tables only; when several rows match an upsert key, all of them are updated

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Superhuman Docs ↗

Questions and answers

Is this the Coda API?
Yes. Coda became Superhuman Docs, and the API is documented as the Superhuman Docs API v1. Requests go to /apis/v1, tokens are created under My account, and the OpenAPI description is still served from coda.io.
Why do writes return 202?
Edits are queued. Inserting, updating, or deleting rows returns a requestId, and GET /mutationStatus/{requestId} reports whether it was applied. This usually takes a few seconds, and an invalid edit can fail after acceptance.
Does the API send webhooks?
No outbound webhooks are documented. The direction is inbound: POST /docs/{docId}/hooks/automation/{ruleId} triggers a webhook-invoked automation inside a doc. This listing polls tables on a schedule for changes.
Ask about Superhuman Docs

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Superhuman Docs through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy