Skip to content

monday.com

The engine reads the items, column values and updates on the boards you name into a knowledge base.

Content is read in place, in your deployment, in your own account. LightHouse receives ids, hashes and counts only. The records are not transmitted, and LightHouse does not open the credential.

Way What you do
Paste an API token Paste an API token, ideally an integration account’s that has been added only to the boards named, and name the boards by id

You need the Client administrator (client_admin) role, signed in as a person, and a deployment whose engine reads this connector (compatibility reference) and keeps credentials in your own store.

  1. Go to Setup and admin → Connectors, find monday.com (search for it, or filter by its family), and choose Connect.
  2. Fill in boards (board ids, separated by commas).
  3. Under What agents may do with it, keep Read only unless your agents are to write through approved cards.
  4. Paste the API token. Your browser seals it to your deployment; LightHouse never sees it.
  5. Your deployment keeps it and checks it at the provider. The card shows the result.
- id: monday-knowledge
purpose: Read monday.com into the knowledge base.
executor: python
target: aal_engine.ingest.connector:run_card
overseer: ops-lead@example.com
budget_usd: 0
effect: internal
source:
kind: monday
boards: ["1234567890"] # board ids, named; never a whole account
updates: 20 # the latest updates read with each item
label: internal
credential_secret: <connection id>
requires:
reads: [monday:the delivery board's items and their updates]
reason: the delivery agents answer from the project's own tracker
  • monday.com does not state a token’s permissions: a token carries its user’s own. That is why the boards are named, and why an integration account that sees only those boards is the right one to make it on.
  • Read and write is recorded as your administrator’s choice, for agents that write through approved cards.
  • The health check: your deployment asks who the token belongs to. The card says monday.com did not state the permissions.
  • One host: api.monday.com.

LightHouse never opens this credential. It is sealed in your browser, or by lighthouse-ai connect monday --credential-stdin, to your deployment’s own key, and your deployment keeps it in your own secrets store under lighthouse/connectors/monday/<connection id>. A request that sends it to LightHouse unsealed is refused with 422 sealing_required. LightHouse keeps the connection’s fingerprint, the access level, the scopes the provider states and when it was checked: never the credential, and never what it reads.

See Where every credential is held.

  • Items on the boards named: their group, column values and latest updates, one document per item.
  • How often, and what is read each time: on the card’s schedule. monday.com filters items by column, not by when they changed, so each named board is read whole on every pull (100 items a page), and only items whose updated_at is after the cursor are written. An unchanged board writes nothing.
  • Deletions: a whole read is also the deletion check: an item no longer on the board is removed on the same pull.
  • Rate limits: monday.com’s complexity budget. A query over budget waits the seconds monday.com names (up to a minute, three times) and asks again; it fails rather than write part of a board.
  • Never read: boards you do not name, files, and docs.
  • The source’s run note in your deployment: written N, unchanged N, quarantined N, removed N.
  • Agents → Knowledge: documents from monday.
  • Content is read in place, in your deployment. LightHouse receives ids, hashes and counts only; the records are not transmitted.

On the card, choose Disconnect. Your deployment deletes the credential from your store. Regenerate the token in monday.com (Developers → My access tokens). Documents already written stay in the corpus until you delete them.