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. Requires boards:read scope.	full
`items`	Extracts all items (tasks/rows) from Monday.com boards. Includes column values, group membership, creator, board reference, parent item, assets, subscribers, and subitem references. Requires boards:read scope.	full
`users`	Extracts all users from Monday.com, including profile details, admin/guest status, timezone, and team memberships. Requires users:read scope.	full
`teams`	Extracts all teams from Monday.com, including team name, picture URL, and member user references. Requires teams:read scope.	full
`workspaces`	Extracts all workspaces from Monday.com, including name, kind, and description. 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. Requires updates:read scope.	full
`tags`	Extracts all tags from Monday.com, including name and color. Requires tags:read scope.	full
`docs`	Extracts all WorkDocs from Monday.com, including name, kind, creation timestamp, associated object, relative URL, and content blocks. 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. The `data` field holds JSON whose structure monday.com does not fully document. 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://{workspace}.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 waits and tries again when monday.com limits requests, so the first sync of a large dataset can take longer.

Who reads monday.com rows

In monday.com, a main board is open to the people who can open its workspace: every member for an open workspace, and only the workspace’s members for a closed one. Every member can open the Main workspace. A private board is open only to its owners and the people and teams they invite, and a shareable board only to its subscribers, who can be guests. A guest never sees a main board.Parable reads monday.com as the one user who connected it, so it reads only the boards, items, and docs that this user can open. While your Workspace turns on Enforce source permissions, and on a table where a Provider Policy rule reads Source permissions (Source permissions), each member reads only these monday.com rows:

Tables	Who reads a row
`workspaces`	Every active member who is not a guest for an open workspace. For a closed or template workspace, only its subscribers and owners, people and teams.
`boards`, and their `items`, `updates`, and `activity_logs`	For a main board: its owners and subscribers, people and teams, and the readers of its workspace. A main board in the Main workspace opens to every active member who is not a guest. For a private or shareable board: only its owners and subscribers, people and teams.
`docs`	For a main doc: its creator and the readers of its workspace, or every active member who is not a guest in the Main workspace. For a private or shareable doc: only its creator.
`users`, `teams`, `tags`	Every active member who is not a guest

Parable matches each member to their monday.com user by the email they sign in with. A member with no active monday.com user reads no monday.com row.
A guest reads only the shareable boards that name them, with their items and updates.
When monday.com deactivates or deletes a user, or a user’s invitation is still pending, that member reads no monday.com row after the next sync of users, with no action from you.
When someone is removed from a board’s subscribers, they stop reading the board, its items, and its updates after the next sync.
People with All data access read every row. Each such read is recorded in your Workspace’s audit events.

Parable reproduces less access than monday.com gives in some cases, and never more:

monday.com does not list who is invited to a private or shareable doc, so only its creator reads it.
Parable reads the first 25 subscribers, owners, and teams of each workspace. A closed workspace with more members admits only those 25 to its main boards. The board’s own subscribers still read the board.
A board shared with the “everyone at account” team admits only its other owners and subscribers.
A user is active only when monday.com reports enabled as true and is_pending as false. When either value is missing, that member reads no monday.com row.
A user is a member only when monday.com reports is_guest as false. When the value is missing, Parable treats the user as a guest.
Only a main (public) board or doc inherits its workspace. A board or doc with a missing kind, or a kind that monday.com adds later, admits only its owners and subscribers, or its creator.
A workspace with a missing kind, or a kind that monday.com adds later, admits only its subscribers and owners.

monday.com Enterprise can also limit a board’s viewers to the items they created or are assigned to. The API does not say which boards do this, so every reader of such a board reads all of its items in Parable. To narrow such a board, give the items table a Provider Policy rule.

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. Parable reads the entries of each board, and each sync reads the entries since the previous sync. The data field is JSON, and monday.com does not fully document its structure. Requires boards:read scope; Enterprise plan required.

Enables: trace Enterprise board actions to the provider-reported actor, event, and time.
Scope: Reads the records that changed since the previous sync through the monday.com GraphQL API. The operation requires the stated monday.com read scope and an Enterprise plan.
Source permissions: An entry reads as its board does.

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. Its values are not guaranteed to be unique.

Board ID

Developer identifier: activity_logs.board_idBoard ID is the ID of the board on which the activity occurred. Parable copies it from the parent board. 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. Its values are not guaranteed to be unique. For source permissions, Parable makes each activity log entry inherit the access of its board (board_id to boards.id): a reader who can open the board reads it.

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 holds configured attributes whose keys and shapes can vary.

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. Check the keys in your Workspace’s data rather than assume a fixed set.

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; 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, this value describes the work record, not a person’s performance.

Developer identifier: activity_logs.idID is the unique activity log entry identifier. It is the record key, so rows with the same value describe the same record.

Enables: identify each activity log record across syncs.
Interpretation: The provider supplies id at one value per activity log record, and it is 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. Its values are not guaranteed to be unique.

Boards

Developer identifier: boardsBoards contain all boards from Monday.com, including metadata such as name, description, board kind, type, state, workspace, creator, owners, subscribers, team owners, team subscribers, top group, columns, groups, tags, and views. Requires boards:read scope.

Enables: catalog monday.com boards and their workspace, owners, columns, groups, tags, and views.
Scope: Reads every record through the monday.com GraphQL API on each sync. Results are limited to objects returned under the stream’s stated monday.com read scope. A board that the previous complete read held and this one does not, because monday.com deleted or archived it, is marked deleted.
Source permissions: A main board admits its owners and subscribers, users and teams, and inherits the access of its workspace. A board in the Main workspace, which names no workspace, admits every active member who is not a guest. A private or shareable board admits only its owners and subscribers. Its items, item updates and activity log entries read as the board does.

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. Its values are not guaranteed to be unique.

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, this value describes the work record, not a person’s performance. For source permissions, only a public (main) board inherits its workspace’s access. A private or share board, a null value and any other value inherit nothing: only the board’s owners and subscribers, users and teams, can open it.

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; 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 is the key of this nested record.

Enables: identify each column record.
Interpretation: The provider supplies id at one value per column record, and it is the key of this nested record.

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, this value describes the work record, not a person’s performance.

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 is the key of this nested record.

Enables: identify each user record.
Interpretation: The provider supplies id at one value per user record, and it is the key of this nested record.

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; 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 is the key of this nested record.

Enables: identify each group record.
Interpretation: The provider supplies id at one value per group record, and it is the key of this nested record.

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 is the record key, so rows with the same value describe the same record.

Enables: identify each board record across syncs.
Interpretation: The provider supplies id at one value per board record, and it is 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. For source permissions, each user in the list can open the board, its items, their updates and its activity log, whatever the board kind.

Developer identifier: boards.owners.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.owners.idID is the unique user identifier. It is the key of this nested record.

Enables: identify each user record.
Interpretation: The provider supplies id at one value per user record, and it is the key of this nested record. For source permissions, Parable reads this id as a monday.com user who can open the board.

Name

Developer identifier: boards.owners.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.

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, this value describes the work record, not a person’s performance.

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. For source permissions, each user in the list can open the board, its items, their updates and its activity log, whatever the board kind.

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. `{workspace}.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)

​Who reads monday.com rows

​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)

Who reads monday.com rows

Personal API Token

Common Issues

Some boards are missing

OAuth 2.0 Authorization Code (3LO)