API

Authentication

Create a token in Settings, CLI tokens. The secret is shown once and stored only as a hash. Send it as a bearer token:

curl https://meshie.ai/api/w/acme/graph/search?q=Status__c \
  -H "Authorization: Bearer agtm_..."

• A token is scoped to one workspace and to the user who created it, and carries that user’s role. It cannot reach another workspace.
• Creating a token requires the Pro plan. The local CLI, which needs no token, works on any plan.
• A token carries scopes: read on every token, plus scan, propose or record when ticked at creation. A non-read route called with a token that lacks its scope gets 403 naming the scope. Tokens minted before scopes existed have read only.
• Revoke from the same page. Revocation takes effect on the next request; a revoked or unknown token gets 401.

Routes

Every route below is under /api/w/{slug}, where the slug is your workspace’s. All of them require a workspace member.

The impact payload

The shape worth knowing, because it is the one thing most integrations read. The CLI emits the same field names, minus the two view URLs:

{
  "target_id": "salesforce:CustomField:Account.Status__c",
  "target_view_url": "https://acme.my.salesforce.com/lightning/setup/ObjectManager/Account/FieldsAndRelationships/Status__c/view",
  "reachable_from_unknown": false,
  "direct_references": [
    {
      "source_id": "salesforce:Flow:Account_Router",
      "edge_type": "FILTERS_ON",
      "tier": "DECLARED",
      "confidence": 1.0,
      "evidence_file": "flows/Account_Router.flow-meta.xml",
      "view_url": null
    }
  ],
  "affected_by_system": { "salesforce": ["..."], "hubspot": ["..."] },
  "depth": 2,
  "field_references_tracked": true,
  "coverage": {
    "hubs": [
      { "hub_key": "salesforce", "label": "Salesforce", "status": "CHECKED", "checked": true, "detected_records": 0, "note": "..." },
      { "hub_key": "hubspot", "label": "HubSpot", "status": "CHECKED", "checked": true, "detected_records": 3, "note": "..." },
      { "hub_key": "make", "label": "Make", "status": "NOT_CONNECTED", "checked": false, "detected_records": 1, "note": "Make detected as connected but not monitored; edges into it are not visible." }
    ],
    "complete": false,
    "detection_measured": true,
    "note": "Checked: HubSpot, Salesforce. Not checked: Make (detected as connected but not monitored); edges into these are not visible."
  }
}

reachable_from_unknown is the field to branch on. It is true when something reaches the node through a reference Meshie cannot resolve, which means the list you are holding is a floor rather than the whole answer. The CLI turns it into exit code 5 for exactly this reason. See Unknown edges.

Two details that catch people out. view_url and target_view_url point into the system the node lives in, not into Meshie, and are null whenever a link cannot be built with confidence: Salesforce flows, Apex and reports need an internal record id that static metadata does not carry, so those are always null today. And evidence_file is relative to the system’s metadata root (the same layout as an SFDX project), so it never names Meshie’s storage or an internal id.

Errors

Errors come back as JSON with a detail string written for a person to read. Log it; it usually says exactly what is wrong.

Using it from an agent

There is no MCP server yet. Until there is, the practical path is the CLI with --json, which gives an agent one command per question, structured output and an exit code that distinguishes “no” from “I cannot tell”. The CLI page has the shapes and codes, and llms.txt indexes these docs for an agent fetching the site.