Clean-room sample

Slack users.list sample: a worked integration decision.

Review sample — not a production integration, a customer engagement, or a case study.

QCC built this read-only TypeScript sample independently from Slack's public documentation. It is one bounded, reviewable slice of a connector for a SaaS product: collecting vendor observations, with code, tests, and a vendor-behavior note.

Open the public repository

Illustrative scenario

Import Slack observations without creating false findings.

Imagine a security/compliance SaaS adding a Slack connector to its product. Its customers' security and compliance teams would use the imported observations in dashboards and evidence reviews.

If the product turned an absent or inaccessible has_2fa value into “MFA disabled,” it could flag a customer incorrectly, send their team chasing unnecessary remediation, and make future findings harder to trust.

The custom integration brings Slack observations into the SaaS product; it does not replace Slack's native security controls. This sample implements the collection slice, not product storage, dashboards, or a findings engine.

Decisions in the code

Three decisions that keep the answer honest.

  1. A missing has_2fa means unknown, not disabled.

    Slack documents has_2fa as visible to admin callers, and the field can be absent. An unreadable field is not evidence that someone turned 2FA off, so a missing or null value becomes unknown. A malformed value fails the scan.

  2. A short page does not prove the scan is complete.

    Slack can return a short page and still include a next cursor. The connector follows cursors until they end, and rejects malformed metadata, repeated cursors, and page-cap exhaustion.

  3. A later failure must not look like a complete result.

    If page three fails, pages one and two are not returned. An incomplete result carries no partial observations, so it cannot be mistaken for a full list of users.

What the product can honestly report.

“We completed the scan” and “we know every person's MFA status” are different claims. A complete result means cursor pagination ended normally, not complete knowledge. Missing fields remain unknown.

Slack-native 2FA is not SSO or identity-provider MFA. Even a visible false value describes Slack-native 2FA only; this sample cannot establish an organization's overall MFA compliance and is not a compliance audit.

What the evidence shows, and what it does not.

The sample makes no write calls and requests no endpoint other than users.list. It does not output names, emails, or raw responses, and it logs nothing.

Shown

  • Synthetic tests cover pagination, malformed responses, rate limiting, and error redaction. The fixtures are hand-written, not recorded Slack responses.
  • In one consented live check, the connector completed a read-only users.list scan of one terminal page in one workspace. Fields that were omitted stayed unknown.

Not established

  • The pagination and rate-limit tests are synthetic, not live multi-page pagination evidence or live rate-limit validation.
  • The retained evidence does not show whose has_2fa value was visible, or why other entries omitted it.
  • Enterprise Grid org-level tokens are not supported.

Before adapting it to your codebase.

These are decisions for the team adapting the sample, not features it implements.

  • Deadlines and body limits: The sample's default transport has no explicit request deadline or response-body cap. Use your transport's limits.
  • Runner and retry model: The sample allows at most one optional rate-limit retry per run and has no checkpoint/resume support. A new run starts over; fit recovery to your job runner.
  • Identity mapping: Map workspace and user IDs through your approved identity model before drawing cross-system conclusions.
  • Enterprise Grid and account states: Decide whether you need org-level tokens, and which account states your controls actually use.

What a subscription request delivers.

For your own integration, the written scope for a request names deliverables such as:

  • Connector code that fits your existing framework.
  • Tests for the vendor behavior your integration depends on.
  • Vendor-behavior notes that separate documented, observed, and unknown.
  • A reviewable handoff in your repository.

This sample shows the shape of that work.

How the subscription works

Have a vendor integration with edge cases like these?

Send the vendor or API, the outcome, and your stack. An inquiry does not start work or authorize access.