> ## Documentation Index
> Fetch the complete documentation index at: https://help.dsalta.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AppSignal

> APM & error tracking — members, apps & access

<Tabs>
  <Tab title="Overview">
    Connect AppSignal with a personal API token to sync organization members, applications, and run access reviews. Requires an organization on an active plan or trial. Read-only. Data feeds into your Access accounts and Inventory pages.

    <Info>
      **Read-only access.** DSALTA only reads data from this integration. It never creates, modifies, or deletes anything in your environment, and every remediation step is performed by your team directly in the third-party product.
    </Info>

    <Info>
      **What you'll see.** The Access page lists the members of every AppSignal **organization** the token's user can see, one row per person, with their name (or their email address when AppSignal has no name for them) and their email. AppSignal exposes no per-member role: the token's own user is shown as **Owner** when AppSignal reports it as the organization's owner (**Owner, Member** when it owns one organization and is a plain member of another), and every other member is shown as **Member**, whatever their role in AppSignal. Organization membership has no status field, so every member is shown as **Active** and stamped with the date of the sync. AppSignal keeps pending invitations on a separate list, so an invitation that has not been accepted does not appear. An organization whose API access AppSignal reports as restricted is skipped. AppSignal reports no per-user MFA state, so the **MFA** column is blank (shown as a dash).
    </Info>

    <Note>
      DSALTA collects this integration's data when you connect it — you can refresh it at any time with **Sync from integrations** on the **Integrations** page. The compliance checks below re-run once a day at 02:00 America/New\_York.
    </Note>

    ## What DSALTA reads

    DSALTA reads each organization's member roster — names and emails — which appears on your **Access** page; and each organization's **applications**, which appear on your **Inventory** page with their organization, environment, status, platforms, languages and the time of their last push (or **no data pushed yet**). Apps appear once an agent has pushed data. The roster and the apps come from a single request per organization, so an organization that cannot be read contributes neither. AppSignal serves API data only to accounts on an active plan or trial: a token from an organization whose trial has ended, or whose account is locked or past its free-plan usage limit, still passes AppSignal's authentication check but is refused data, and DSALTA reports that plan gate by name rather than as a bad token. An organization whose API access AppSignal reports as restricted is skipped, and when no organization can be read the sync fails with a message naming the first one. The organization's Push API key, each app's Front-End API key, per-app incidents, deploy markers and telemetry are never read.

    It calls these AppSignal endpoints on `appsignal.com`:

    * `/api/v2/auth` (the REST authentication check, used to prove the token)
    * `/graphql` — `viewer { … organizations { … } }` (the token's own user and its organizations)
    * `/graphql` — `organization(slug: …) { … apiAccessRestricted currentUserIsOwner users { … } apps { … } }` (one query per organization)

    Every request is a read — the GraphQL calls are queries, never mutations. DSALTA has no code path that creates, modifies, or deletes anything in your AppSignal environment.

    ## Troubleshooting

    <AccordionGroup>
      <Accordion title="The connection is rejected with a message about the organization's plan or trial">
        The token is valid, but AppSignal refuses API data for its account: the organization's trial has ended, or the account is locked or past its free-plan usage limit. Choose a plan in AppSignal (**Organization → Billing**), or connect with a personal API token from an account on an active plan or trial. An organization whose free plan lapses after connecting loses the integration the same way until a plan is chosen.
      </Accordion>

      <Accordion title="The connection is rejected as an invalid token">
        The value is not the personal API token from **Profile → Account settings → Personal → API**. The organization's Push API key, an app's Front-End API key and an MCP token do not authenticate the API, and DSALTA rejects them at connect time.
      </Accordion>

      <Accordion title="An organization, or its members, is missing from the Access page">
        The token is personal and sees exactly what its user sees, so an organization the user does not belong to is never listed. An organization whose API access AppSignal reports as restricted is skipped without failing the sync while other organizations are readable. Apps are only listed once an agent has pushed data for them. Click **Sync from integrations** on the **Integrations** page to retry.
      </Accordion>
    </AccordionGroup>

    <AccordionGroup>
      <Accordion title="How do I check whether the connection is healthy?">
        Open **Integrations** in the DSALTA sidebar, stay on the **Connected** tab, and click **Manage** on the integration's card. Open the **Status** tab: it shows either **Connected and working properly** or **Connection issues detected**.

        Use the **Status** tab, not **Overview** — Overview always reports **Connected** regardless of the real state.
      </Accordion>

      <Accordion title="A check shows Failed and nothing changed on my side">
        On an integration-powered check, **Failed** normally means DSALTA was blocked rather than that you are non-compliant. Open the test, go to **Source Data**, and read the result code: **403** is a missing permission, **428** is a setting DSALTA still needs, **500** is a failure on DSALTA's side.

        A real compliance gap shows **207** and leaves the test looking **Completed**. See [Understanding Test Results](/guides/compliance/test-results).
      </Accordion>

      <Accordion title="Data looks out of date">
        Compliance checks re-run once a day at 02:00 America/New\_York. To refresh sooner, open **Integrations → Connected** and click **Sync from integrations** at the top right — it refreshes every connected integration at once.
      </Accordion>

      <Accordion title="How do I repair a broken connection?">
        There is no Reconnect, Repair or Refresh Token button. The only repair available is to disconnect and connect again.

        <Warning>
          **Disconnecting is destructive and cannot be undone.** DSALTA removes the access records, inventory, vulnerabilities, code changes, incidents and device records collected from this integration, and deletes the test results tied to the connection. Export anything you still need as audit evidence first — see [Integration errors](/troubleshooting/integration-errors).
        </Warning>
      </Accordion>

      <Accordion title="Configure scope will not let me change anything">
        That is expected. **Configure scope** is read-only — it shows what DSALTA is permitted to read, and has no Save action. To change what DSALTA can see, change the permissions on the credential in the third-party product, then disconnect and connect again.
      </Accordion>
    </AccordionGroup>
  </Tab>

  <Tab title="How to connect">
    An AppSignal personal API token from an organization owner on an active plan or trial. Organizations are detected automatically. Read-only.

    **Before you begin**

    * An AppSignal organization owner whose account is on an active plan or trial — a token from a locked or post-trial account authenticates but returns no data.

    You will need:

    | Field | Where to find it | Example |
    | - | - | - |
    | **Personal API token** | [appsignal.com/users/edit](https://appsignal.com/users/edit) → **Profile → Account settings → Personal → API** | `AppSignal personal API token` |

    <Steps>
      <Step title="Start in DSALTA">
        Open **Integrations** in the DSALTA sidebar, find **AppSignal**, and click **Connect** to open the connect panel.
      </Step>

      <Step title="Sign in as an organization owner on an active plan">
        Sign in at [appsignal.com](https://appsignal.com) with an account that owns the organization to review. The token is personal and sees exactly what its user sees.

        <Note>
          AppSignal only serves API data to accounts on an active plan or trial. If the organization's trial has ended, choose a plan first — the token is otherwise accepted but refused data.
        </Note>
      </Step>

      <Step title="Copy your personal API token">
        Open [appsignal.com/users/edit](https://appsignal.com/users/edit), then **Profile → Account settings → Personal → API**, and copy the personal API token.

        <Warning>
          **Do not use the organization's Push API key, an app's Front-End API key or an MCP token.** None of them authenticates the API, and DSALTA rejects them at connect time.
        </Warning>
      </Step>

      <Step title="Connect AppSignal">
        Return to the connect panel, paste the personal API token, and click **Connect**.
      </Step>
    </Steps>

    <Check>
      DSALTA validates the token when you click **Connect**, by checking it against AppSignal's REST authentication endpoint, listing the organizations it can see, and reading the first organization's API-access flag and members. On success the integration moves to the **Connected** tab, and **Manage → Status** reads **Connected and working properly**. Checks begin reporting after the first sync.
    </Check>

    <Warning>
      **If the connection is rejected.** An invalid token or a key of the wrong kind, an account whose trial has ended or that is locked or past its usage limit, a token that can see no organization, an organization whose API access is restricted, or an organization whose member list comes back empty.

      The on-screen message is generic — see [Connection error messages](/troubleshooting/connection-error-messages).
    </Warning>
  </Tab>

  <Tab title="Automated checks">
    Each check below re-runs once a day, at 02:00 America/New\_York, while this integration is connected. Click any check for step-by-step remediation guidance.

    | Check | Severity | What it verifies |
    | - | - | - |
    | [User access to Critical System should be valid](/integrations/appsignal/user-access-to-critical-system-should-be-valid) | Info | Checks that everyone with AppSignal access is an active employee on the People page. |
    | [Offboarded users should not have active access](/integrations/appsignal/offboarded-users-should-not-have-active-access) | High | Checks that offboarded employees no longer have active AppSignal access. |
  </Tab>

  <Tab title="Useful links">
    | Topic | Link |
    | - | - |
    | Setup | [AppSignal GraphQL API authentication](https://docs.appsignal.com/api/graphql) |
    | Remediation | [AppSignal organization members](https://docs.appsignal.com/organization/team/members) |
    | General | [AppSignal](https://appsignal.com) |
    | DSALTA | [Connection error messages](/troubleshooting/connection-error-messages) |
  </Tab>
</Tabs>