Skip to main content

​
Overview

Workspace APIs are for team workflows: private lists, briefs, coverage targets, watches, usage proof, and Scout sync. They help teams act on source-backed research while keeping public records, private notes, and review state separate. For exact workspace endpoints and schemas, use the API reference.

​
The rule

Public Atlas records should be backed by public evidence. Workspace context is private unless a user deliberately publishes a public-safe record. An integration should never treat a private brief, note, list, or coverage target as public evidence. Keep it scoped to the workspace unless the API response explicitly says a record is public.

​
What belongs in a workspace

Use workspace APIs for:
  • Draft briefs and source-linked decision artifacts.
  • Coverage targets for places, issues, actor types, and source gaps.
  • Watches that keep a team aware of actor or coverage changes.
  • Usage proof for evidence opens, exports, and workflow activity.
  • Scout sync receipts and review state.
  • Private notes that should not appear in the public directory.
Keep public actor facts and source evidence separate from team-only judgment, planning notes, and workflow status.

​
Understand entry links

Scout and workspace import flows may return entry_links. These links connect records from one context to another:
  • A local Scout entry to an Atlas entry.
  • A workspace-private entry to a public directory entry.
  • A run result to a brief, list, or coverage target.
Treat entry_links as mappings, not proof. The link tells you how systems refer to the same or related record. The source evidence tells you whether the record is strong enough to use.

​
Read visibility as a publication decision

Visibility tells you who should be able to see a record. If an endpoint returns a more specific status, prefer the endpoint response over this general model.

​
Safe workspace pattern

Use this pattern for imports, syncs, briefs, and exports:
  1. Authenticate as the correct workspace.
  2. Preserve source ids or source URLs with every imported actor.
  3. Store returned entry links.
  4. Store visibility and review state.
  5. Keep private notes out of public records.
  6. Re-check source freshness before publication, outreach, or funding review.
  7. Export evidence with the artifact, not separately from it.

​
Example: build a source-backed brief

For a nonprofit entering Phoenix, a safe workflow could be:
1

Find public actors

Use public place and entity APIs to find housing, wage-theft, and immigrant-worker organizations.
2

Inspect evidence

Review the sources that support each actor and issue connection.
3

Create a workspace brief

Save selected actors, sources, notes, and review state inside the team’s workspace.
4

Track gaps

Add coverage targets for source types, issue areas, or places that need more review.
5

Export proof

Export the brief with source context preserved.

​
What not to do

  • Do not publish private workspace notes as source evidence.
  • Do not treat entry links as confidence scores.
  • Do not discard source URLs when exporting a brief.
  • Do not assume a single-source lead is ready for outreach.
  • Do not merge Scout entries into public records without visibility review.
  • Do not present usage proof as public impact evidence without context.

Team workflows

Build briefs, track coverage, watch changes, and export proof.

Sync Scout results

Sync reviewed Scout results into Atlas.

Trust and provenance

Interpret source-backed claims and uncertainty.

API reference

Inspect exact workspace request and response schemas.