monday.com - Parable

Sync boards, items, users, teams, workspaces, updates, tags, docs, and activity logs from monday.com.

Overview
Setup Guide
Permissions
Troubleshooting

Personal API Token

Connect Parable to Monday.com using a personal API token and the GraphQL API. The token is tied to your user and inherits your account permissions, so the data Parable can sync depends on what your user can see. For full-account coverage, use an administrator’s token.

Info: The token inherits your user’s permissions. A member token only reaches boards that user is subscribed to; an administrator token reaches the whole account.

Boards & work items

Boards, groups, columns, items, subitems, tags, activity logs

People & workspaces

Users, teams, workspaces

Collaboration

Updates, replies, WorkDocs

Personal API Token

All of the tables below are collected for a connection. The access level of your token determines how much data each returns.

Data	Access needed
Boards, groups, columns	Admin, or member subscribed to the board
Items, subitems, column values	Admin, or member subscribed to the board
Users	Admin (member tokens return limited results)
Teams	Admin
Workspaces	Admin
Updates & replies	Admin, or access to the item’s board
Tags	Admin
WorkDocs	Access to the doc or its workspace
Activity logs	Admin and an Enterprise plan

OAuth 2.0 Authorization Code (3LO)

Connect Parable to Monday.com using OAuth 2.0. You create a Monday.com app in the Developer Center, create the connection in Parable, register Parable’s redirect URI on your app, then authorize through Parable’s in-app wizard. Parable exchanges the authorization code for an access token and stores it securely.

Info: You do not enter an access token manually. The in-app wizard completes the OAuth flow for you.

Boards & work items

Boards, groups, columns, items, subitems, tags, activity logs

People & workspaces

Users, teams, workspaces

Collaboration

Updates, replies, WorkDocs

Data streams

This Provider Plugin defines 9 data streams.

Stream	Description	Sync
`boards`	Extracts all boards from Monday.com, including metadata such as name, description, board kind, type, state, workspace, creator, owners, subscribers, top group, columns, groups, tags, and views. Uses page-based pagination with limit=50 per page. Requires boards:read scope.	full
`items`	Extracts all items (tasks/rows) from Monday.com boards using cursor-based pagination via items_page per board, then next_items_page for subsequent pages. Includes column values, group membership, creator, board reference, parent item, assets, subscribers, and subitem references. Requires iterating over all boards first. Requires boards:read scope.	full
`users`	Extracts all users from Monday.com, including profile details, admin/guest status, timezone, and team memberships. Uses page-based pagination with limit=500 per page. Requires users:read scope.	full
`teams`	Extracts all teams from Monday.com, including team name, picture URL, and member user references. No pagination documented; returns all teams in a single response. Requires teams:read scope.	full
`workspaces`	Extracts all workspaces from Monday.com, including name, kind, and description. Uses page-based pagination with limit=50 per page. Requires workspaces:read scope.	full
`updates`	Extracts all updates (comments and activity posts) on Monday.com items, including body text, creator, timestamps, and nested replies. Uses page-based pagination with limit=100 per page. Requires updates:read scope.	full
`tags`	Extracts all tags from Monday.com, including name and color. No pagination documented; returns all tags in a single response. Requires tags:read scope.	full
`docs`	Extracts all WorkDocs from Monday.com, including name, kind, creation timestamp, associated object, relative URL, and content blocks. Uses page-based pagination with limit=50 per page. Requires docs:read scope.	full
`activity_logs`	Extracts activity log entries per board from Monday.com (Enterprise plan only). Each entry records who performed what action on a board and when. Traverses all boards and fetches activity_logs per board with time-range filtering for incremental sync. Confidence on data field schema is moderate (0.70) as the field is JSON-encoded and its internal structure is not fully documented. Requires boards:read scope; Enterprise plan required.	incremental

Personal API Token

What You’ll Need

Credential	What it is
API Token	Personal API token from your Monday.com account

Info: Setup access in Monday.com. These steps require Administrator (recommended, for full-account access), or a colleague with equivalent permissions who can create credentials for you. If that is not you, ask your Monday.com administrator.

Any account member can generate a personal token, but the token only reaches data that user can access.
An Administrator token is recommended so Parable can sync all boards, users, teams, and workspaces.
Activity logs require a Monday.com Enterprise plan.

Step 1: Open your developer settings

Sign in to Monday.com (use an administrator account for full-account access).
Click your avatar (bottom-left) and open Developers.
Select API token.

Step 2: Copy your API token

Click Show to reveal your personal token, or Regenerate to create a new one.
Copy the token.

You can return to this page and click Show whenever you need to display the token again.

Warning: Regenerating a token invalidates the previous one. Any connection still using the old token stops syncing until you update it.

Step 3: Confirm the token’s access level

The token inherits the permissions of your user account:

Administrators reach every board, user, team, and workspace.
Members reach only the boards they are subscribed to.

Tip: Use an administrator account so Parable can sync your full account.

Step 4: Enter the token in Parable

Open the Monday.com API Token Provider in Parable and add a connection.
Enter a connection name.
Paste your API Token.
Click Save & test connection.

OAuth 2.0 Authorization Code (3LO)

What You’ll Need

Credential	What it is
Client ID	OAuth application client ID from the Monday.com Developer Center
Client Secret	OAuth application client secret

Info: Setup access in Monday.com. These steps require Administrator (to create apps in the Developer Center), or a colleague with equivalent permissions who can create credentials for you. If that is not you, ask your Monday.com administrator.

A Monday.com app created in the Developer Center with OAuth enabled
The read scopes listed in step 2 enabled on the app
Permission to register a redirect URI on the app’s OAuth settings
Activity logs require a Monday.com Enterprise plan

Step 1: Create a Monday.com app

Sign in to Monday.com as an administrator.
Open https://{your-account}.monday.com/apps/manage, replacing {your-account} with your Monday.com account subdomain. Confirm My Apps is selected, then click Create app.
Open the app’s OAuth & Permissions section and note the Client ID and Client Secret.
If Monday.com requires a redirect URL before you can continue, enter a valid placeholder URL. You will replace it with the Parable redirect URI in step 4.

Warning: Copy your Client Secret now! This is the only time it will be displayed. Store it in a secure password manager before closing this page.

Step 2: Enable the required scopes

On the app’s OAuth & Permissions page, enable every read scope below so Parable can sync all Monday.com data:

Scope	Enables
`boards:read`	Boards, groups, columns, items, subitems, activity logs
`users:read`	Users
`teams:read`	Teams
`workspaces:read`	Workspaces
`updates:read`	Updates and replies
`tags:read`	Tags
`docs:read`	WorkDocs

Info: These are read-only scopes. Monday.com’s OAuth here is 3-legged (authorization code); Parable stores the access token after you approve. Activity logs also require an Enterprise plan.

Step 3: Create the connection in Parable

Open the Monday.com OAuth Provider in Parable and add a connection.
Enter a connection name.
Copy the Redirect URI shown on the form.
Click Continue to OAuth setup.

Parable creates the connection and opens the OAuth authorization screen.

Step 4: Register the redirect URI in Monday.com

In your Monday.com app OAuth & Permissions settings, add the Redirect URI you copied from Parable under Redirect URLs, replacing any placeholder URL entered in step 1.
Register it exactly as shown, including your workspace subdomain and path.

Info: The redirect URI includes your workspace subdomain. Example: https://{tenant-name}.parable.work/platform/providers/oauth/callback. Do not register the apex host alone (https://parable.work/...). Monday.com must match the subdomain of the workspace where you started the connection.

Step 5: Authorize with Parable

On the OAuth authorization screen, enter your Client ID and Client Secret.
Click Connect with OAuth. You are redirected to Monday.com to approve the requested permissions.
After you approve, Parable redirects back automatically, stores your access token securely, and validates the connection.

Info: Monday.com’s legacy OAuth returns a long-lived access token that stays valid until the app is uninstalled. To rotate credentials or recover from a revoked token, click Re-authorize with OAuth on the connection page.

OAuth 2.0 Authorization Code (3LO)

Scope	Enables
`boards:read`	Boards, groups, columns, items, subitems, activity logs
`users:read`	Users
`teams:read`	Teams
`workspaces:read`	Workspaces
`updates:read`	Updates and replies
`tags:read`	Tags
`docs:read`	WorkDocs

Info: Enable all scopes above for complete coverage. Activity logs also require a Monday.com Enterprise plan.

Success: After authorization, Parable shows an authorized status and validates the connection automatically.

Tip: Rate Limits: Monday.com enforces rate limits of complexity-based (up to 10,000,000 complexity points/minute depending on plan), plus a global cap of about 1.67 requests/second. Parable handles rate limiting automatically with exponential backoff, but initial syncs of large datasets may take longer due to these limits.

Activity Logs

Developer identifier: activity_logsActivity Logs contain activity log entries per board from Monday.com (Enterprise plan only). Each entry records who performed what action on a board and when. Traverses all boards and fetches activity_logs per board with an explicit time-range request for incremental sync. Confidence on data field schema is moderate (0.70) as the field is JSON-encoded and its internal structure is not fully documented. Requires boards:read scope; Enterprise plan required.

Enables: trace Enterprise board actions to the provider-reported actor, event, and time.
Scope: Reads provider changes through the declared GraphQL operation using the declared incremental request boundary. The operation requires the stated monday.com read scope and an Enterprise plan.

Account ID

Developer identifier: activity_logs.account_idAccount ID is the ID of the account that initiated the event. It is needed to resolve references that repeat the same provider identifier.

Enables: match activity log records to provider records that carry the same account ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies account_id as a record-level identifier on ActivityLog. It is not a uniqueness guarantee unless a connector directive says so.

Board ID

Developer identifier: activity_logs.board_idBoard ID is the ID of the board on which the activity occurred. Derived from the parent boards query traversal. It is needed to resolve references that repeat the same provider identifier.

Enables: match activity log records to provider records that carry the same board ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies board_id as a record-level identifier on ActivityLog. It is not a uniqueness guarantee unless a connector directive says so.

Created At

Developer identifier: activity_logs.created_atCreated At records the timestamp indicating when the event occurred. Board logs use 17-digit Unix time. It anchors the named event or boundary on the record’s timeline.

Enables: place activity log records on a timeline by created at and select the records within an explicit reporting window.
Interpretation: The provider supplies created_at per activity log record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Data

Developer identifier: activity_logs.dataData records JSON-encoded event-specific data payload. Internal structure varies by event type and is not fully documented. Confidence: 0.70. It retains configured attributes whose keys or shape are not fixed by this base schema.

Enables: interpret data according to the provider and Workspace configuration that produced each activity log record.
Interpretation: Keys and value shapes within data can vary with provider and customer configuration; consumers must inspect the observed Workspace schema rather than assume a fixed contract.

Entity

Developer identifier: activity_logs.entityEntity records entity the event refers to (e.g. board, pulse, column). It preserves the containing or referenced object needed to reconstruct the provider relationship.

Enables: reconstruct the declared entity layout or dimensional scope of each activity log record.
Interpretation: The provider returns entity as a nested object or reference on ActivityLog; an absent value does not prove that no related object exists outside the credential’s visibility.

Event

Developer identifier: activity_logs.eventEvent states event type describing the action performed (e.g., create_item, change_column_value). It preserves the provider’s current classification of this record.

Enables: separate activity log records by the exact provider-reported event value when describing their recorded state.
Interpretation: The provider supplies event per activity log record using its own state vocabulary; unknown and missing values must remain distinct. In monday.com, event is the work record’s classification, not an individual-performance measure.

Developer identifier: activity_logs.idID is the unique activity log entry identifier. It supplies the declared record identity used when repeated ingestions represent the same source row.

Enables: recognize repeated ingestions of the same activity log source row before constructing its represented state.
Interpretation: The provider supplies id at one value per activity log record, and x-transformDedupKey explicitly marks it as the record key.

User ID

Developer identifier: activity_logs.user_idUser ID is the ID of the user who performed the action. It is needed to resolve references that repeat the same provider identifier.

Enables: match activity log records to provider records that carry the same user ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies user_id as a record-level identifier on ActivityLog. It is not a uniqueness guarantee unless a connector directive says so.

Boards

Developer identifier: boardsBoards contain all boards from Monday.com, including metadata such as name, description, board kind, type, state, workspace, creator, owners, subscribers, top group, columns, groups, tags, and views. Uses page-based pagination with limit=50 per page. Requires boards:read scope.

Enables: catalog monday.com boards and their workspace, owners, columns, groups, tags, and views.
Scope: Reads the declared collection through the declared GraphQL operation as a full snapshot. Results are limited to objects returned under the tap’s stated monday.com read scope.

Board Folder ID

Developer identifier: boards.board_folder_idBoard Folder ID is the ID of the folder containing this board, if any. It is needed to resolve references that repeat the same provider identifier.

Enables: match board records to provider records that carry the same board folder ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies board_folder_id as a record-level identifier on Board. It is not a uniqueness guarantee unless a connector directive says so.

Board Kind

Developer identifier: boards.board_kindBoard Kind states visibility kind of the board: public, private, or share. It preserves the provider’s current classification of this record.

Enables: separate board records by the exact provider-reported board kind value when describing their recorded state.
Interpretation: The provider supplies board_kind per board record using its own state vocabulary; unknown and missing values must remain distinct. In monday.com, board kind is the work record’s classification, not an individual-performance measure.

Columns

Developer identifier: boards.columnsColumns records array of column definitions on this board. It preserves the containing or referenced object needed to reconstruct the provider relationship.

Enables: reconstruct the declared columns layout or dimensional scope of each board record.
Interpretation: The provider returns columns as a list on Board; an absent value does not prove that no related object exists outside the credential’s visibility.

Developer identifier: boards.columns.idID is the unique column identifier within the board. It supplies the declared record identity used when repeated ingestions represent the same source row.

Enables: recognize repeated ingestions of the same column source row before constructing its represented state.
Interpretation: The provider supplies id at one value per column record, and x-transformDedupKey explicitly marks it as the record key.

Title

Developer identifier: boards.columns.titleTitle records display title of the column. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact title value attached to each column record.
Interpretation: The provider supplies title at column granularity in the format stated by its description; omitted or redacted content remains unknown.

Type

Developer identifier: boards.columns.typeType states column type identifier (e.g., text, status, date, people, numbers). It preserves the provider’s current classification of this record.

Enables: separate board records by the exact provider-reported type value when describing their recorded state.
Interpretation: The provider supplies type per column record using its own state vocabulary; unknown and missing values must remain distinct. In monday.com, type is the work record’s classification, not an individual-performance measure.

Creator

Developer identifier: boards.creatorCreator captures the user who created this board. It keeps the provider-reported person or account context attached to the record.

Enables: attribute the board record to the provider-reported actor represented by creator.
Interpretation: The provider supplies creator as identity or attribution context on each board record. In monday.com, creator is attribution or membership context for the work record, not a measure of an individual’s performance.

Developer identifier: boards.creator.emailEmail records email address of the user. It keeps the provider-reported person or account context attached to the record.

Enables: attribute the user record to the provider-reported person or account represented by email.
Interpretation: The provider supplies email as identity or attribution context on each user record. In monday.com, email is attribution or membership context for the work record, not a measure of an individual’s performance.

Developer identifier: boards.creator.idID is the unique user identifier. It supplies the declared record identity used when repeated ingestions represent the same source row.

Enables: recognize repeated ingestions of the same user source row before constructing its represented state.
Interpretation: The provider supplies id at one value per user record, and x-transformDedupKey explicitly marks it as the record key.

Name

Developer identifier: boards.creator.nameName records display name of the user. It keeps the provider-reported person or account context attached to the record.

Enables: attribute the user record to the provider-reported person or account represented by name.
Interpretation: The provider supplies name as identity or attribution context on each user record. In monday.com, name is attribution or membership context for the work record, not a measure of an individual’s performance.

Description

Developer identifier: boards.descriptionDescription records optional description of the board. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact description value attached to each board record.
Interpretation: The provider supplies description at board granularity in the format stated by its description; omitted or redacted content remains unknown.

Groups

Developer identifier: boards.groupsGroups records array of group definitions on this board. It preserves the containing or referenced object needed to reconstruct the provider relationship.

Enables: associate each board record with the specific provider container named by groups.
Interpretation: The provider returns groups as a list on Board; an absent value does not prove that no related object exists outside the credential’s visibility.

Color

Developer identifier: boards.groups.colorColor records hex color code associated with the group. It preserves the provider’s visual treatment for the represented object.

Enables: reproduce or compare the provider-supplied color for the represented design or board object.
Interpretation: The provider supplies color in its own color, opacity, stroke, emoji, or style vocabulary for the represented object.

Developer identifier: boards.groups.idID is the unique group identifier within the board. It supplies the declared record identity used when repeated ingestions represent the same source row.

Enables: recognize repeated ingestions of the same group source row before constructing its represented state.
Interpretation: The provider supplies id at one value per group record, and x-transformDedupKey explicitly marks it as the record key.

Title

Developer identifier: boards.groups.titleTitle records display title of the group. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact title value attached to each group record.
Interpretation: The provider supplies title at group granularity in the format stated by its description; omitted or redacted content remains unknown.

Developer identifier: boards.idID is the unique board identifier. It supplies the declared record identity used when repeated ingestions represent the same source row.

Enables: recognize repeated ingestions of the same board source row before constructing its represented state.
Interpretation: The provider supplies id at one value per board record, and x-transformDedupKey explicitly marks it as the record key.

Items Count

Developer identifier: boards.items_countItems Count reports the number of items on the board. It preserves the stated measure at this record’s granularity.

Enables: measure the provider-reported items count for each board record.
Interpretation: The provider supplies items_count at board granularity as a count at one value per record; zero and missing are not interchangeable.

Name

Developer identifier: boards.nameName records display name of the board. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact name value attached to each board record.
Interpretation: The provider supplies name at board granularity in the format stated by its description; omitted or redacted content remains unknown.

Owners

Developer identifier: boards.ownersOwners records users who own this board. It keeps the provider-reported person or account context attached to the record.

Enables: attribute the board record to the provider-reported actor represented by owners.
Interpretation: The provider supplies owners as identity or attribution context on each board record. In monday.com, owners is attribution or membership context for the work record, not a measure of an individual’s performance.

Permissions

Developer identifier: boards.permissionsPermissions states board permission setting. It documents the access-related value reported for this object or membership.

Enables: describe the provider-reported permissions attached to each board record.
Interpretation: The provider supplies permissions at board granularity. It describes provider-reported context and does not prove effective access beyond the returned record.

State

Developer identifier: boards.stateState states lifecycle state of the board: active, archived, or deleted. It preserves the provider’s current classification of this record.

Enables: separate board records by the exact provider-reported state value when describing their recorded state.
Interpretation: The provider supplies state per board record using its own state vocabulary; unknown and missing values must remain distinct. In monday.com, state is the work record’s classification, not an individual-performance measure.

Subscribers

Developer identifier: boards.subscribersSubscribers records users subscribed to this board. It keeps the provider-reported person or account context attached to the record.

Enables: attribute the board record to the provider-reported person or account represented by subscribers.
Interpretation: The provider supplies subscribers as identity or attribution context on each board record. In monday.com, subscribers is attribution or membership context for the work record, not a measure of an individual’s performance.

Personal API Token

Error	Meaning	Solution
`Not Authenticated`	Invalid or revoked token	Re-copy the token from API token, or regenerate it
`Unauthorized`	Token lacks access to the resource	Use an administrator token for full-account access
Missing users, teams, or workspaces	Member-level token	Reconnect with an administrator token
Empty activity logs	Non-Enterprise plan	Activity logs require an Enterprise plan
`ComplexityException`	Query exceeded the complexity budget	Parable batches and retries automatically; retry after the reset window

Common Issues

Some boards are missing

Token access is limited to boards the user can see. Reconnect with an administrator account for full access.

OAuth 2.0 Authorization Code (3LO)

Error	Meaning	Solution
`401 Unauthorized`	Invalid client credentials or access token	Verify the Client ID and Secret, or re-authorize with OAuth
`403 Forbidden`	Missing OAuth scope	Enable the required scope on the app and re-authorize
Authorization redirect fails	Redirect URI mismatch	Copy the redirect URI from Parable (must include your workspace subdomain, e.g. `{tenant-name}.parable.work`) and add it exactly under Redirect URLs
Re-authorization required	Access token revoked or app uninstalled	Click Re-authorize with OAuth on the connection page
Empty activity logs	Non-Enterprise plan	Activity logs require an Enterprise plan
`ComplexityException`	Query exceeded the complexity budget	Parable batches and retries automatically; retry after the reset window

Monday.com OAuth guide — Official OAuth 2.0 documentationMonday.com API — GraphQL API reference

​Personal API Token

​Boards & work items

​People & workspaces

​Collaboration

​Personal API Token

​OAuth 2.0 Authorization Code (3LO)

​Boards & work items

​People & workspaces

​Collaboration

​Data streams

​Personal API Token

​What You’ll Need

​Step 1: Open your developer settings

​Step 2: Copy your API token

​Step 3: Confirm the token’s access level

​Step 4: Enter the token in Parable

​OAuth 2.0 Authorization Code (3LO)

​What You’ll Need

​Step 1: Create a Monday.com app

​Step 2: Enable the required scopes

​Step 3: Create the connection in Parable

​Step 4: Register the redirect URI in Monday.com

​Step 5: Authorize with Parable

​OAuth 2.0 Authorization Code (3LO)

​Personal API Token

​Common Issues

​Some boards are missing

​OAuth 2.0 Authorization Code (3LO)

Personal API Token

Boards & work items

People & workspaces

Collaboration

Personal API Token

OAuth 2.0 Authorization Code (3LO)

Boards & work items

People & workspaces

Collaboration

Data streams

Personal API Token

What You’ll Need

Step 1: Open your developer settings

Step 2: Copy your API token

Step 3: Confirm the token’s access level

Step 4: Enter the token in Parable

OAuth 2.0 Authorization Code (3LO)

What You’ll Need

Step 1: Create a Monday.com app

Step 2: Enable the required scopes

Step 3: Create the connection in Parable

Step 4: Register the redirect URI in Monday.com

Step 5: Authorize with Parable

OAuth 2.0 Authorization Code (3LO)

Personal API Token

Common Issues

Some boards are missing

OAuth 2.0 Authorization Code (3LO)