n8n-nodes-tidycal

Community node for TidyCal — scheduling/booking API.

Status

Generated from a complete OpenAPI spec (TidyCal_openapi_Docs.json), so every
resource/operation in the spec is implemented — no functionality TODOs.

Known limitations in this version: list operations expose page as a manual
parameter and there is no auto-pagination / "Return All" toggle, so each
execution returns a single page. The OAuth2 credential does not declare
scopes; the Personal Access Token path is the tested one.

Resources & operations

• Booking — Get Many, Get, Cancel
• Booking Type — Get Many, Create, Get Available Timeslots, Create Booking
• Contact — Get Many, Create
• Account — Get (profile info)
• Team — Get Many, Get, Get Bookings, Get Users, Add User, Remove User, Get Booking Types, Create Booking Type

Auth

Two credential types, selectable in the node's "Authentication" dropdown:

• Personal Access Token (TidyCalApi) — simplest, Bearer header. Create one
  at tidycal.com/integrations/advanced (requires a paid plan).
• OAuth2 (TidyCalOAuth2Api) — for building an integration where end
  users authorize your app. Needs a TidyCal OAuth client (same Integrations
  page) with your own Client ID/Secret entered in n8n's credential UI.

One spec quirk to know about

The spec marks several query params (page, starts_at, ends_at,
cancelled, include_teams on /bookings and /booking-types) as
"in": "path", but none of those appear as {placeholders} in the actual
URL templates. Implemented here as query string params — the only reading
consistent with the URL templates themselves and with how the correctly
labeled pagination params elsewhere in the same spec behave. Worth a quick
sanity check against a real account after building.

Setup

npm install
npm run build
npm run lint     # n8n's community package scanner

Publish

npm login
npm publish --access public

Then on a self-hosted n8n instance: Settings → Community Nodes →
Install → n8n-nodes-tidycal. Unverified community nodes are not
installable on n8n Cloud; that requires going through n8n's verification
process.

Before publishing for real

• Replace the placeholder icon (nodes/TidyCal/tidycal.svg, a generic
  calendar) with TidyCal's actual logo only if you have rights to use it —
  otherwise keep something original
• Test the credential's test request (GET /me) against a real
  Personal Access Token
• Test at least one call per operation against a live TidyCal account —
  especially the page/starts_at/ends_at query params noted above,
  and the package-booking JSON fields on "Create Booking"
• Decide if you actually need the OAuth2 credential for v1, or if
  Personal Access Token alone covers your use case — you can drop the
  OAuth2 credential file and its displayOptions branch to simplify if so

Going for n8n-verified status

Verification is what makes a node discoverable in the in-app nodes panel and
installable on n8n Cloud. See n8n's current requirements at
https://docs.n8n.io/integrations/creating-nodes/deploy/submit-community-nodes/
— notably English-only throughout, single-service scope, the community package
scanner passing, and (as of May 2026) publishing via a GitHub Actions workflow
with a provenance statement rather than from a local machine.