attio-install-auth

Choose and configure Attio REST authentication for a single workspace or multi-workspace OAuth app, including least-privilege scopes and a read-only verification. Use when connecting a service to Attio. Trigger with "Attio auth", "Attio API key", or "Attio OAuth setup".

Allowed Tools

ReadGlobGrepWebFetchWriteEdit

Provided by Plugin

attio-pack

Attio CRM integration pack with 18 operator skills

saas packs v1.8.0
View Plugin

Installation

This skill is included in the attio-pack plugin:

/plugin install attio-pack@claude-code-plugins-plus

Click to copy

Instructions

Attio Authentication Setup

Overview

This skill selects the correct Attio access-token path, maps endpoint scopes, and proves the credential with a non-mutating request.

Prerequisites

  • The integration's workspace and tenancy model
  • Exact endpoints and operations the application will use
  • An approved secret store and rotation owner
  • Registered redirect URIs when OAuth is required

Tool Discipline

Use Read, Glob, and Grep to inspect the local auth wrapper, secret names, redirect configuration, and endpoint use. Use WebFetch only for current official Attio documentation. Use Write or Edit after the auth model and target files are confirmed.

Current Contract

  • Prefer OAuth 2.0 for an app that serves multiple Attio workspaces.
  • Use a manually generated workspace API key for one controlled workspace.
  • Both credential types can be sent as Authorization: Bearer <access_token>.
  • Required scopes are documented per endpoint and should be granted operation by operation.
  • Attio also supports Basic authentication with the token as username and an empty password, but Bearer is recommended.

Authentication

For OAuth, validate state, use the registered redirect URI exactly, exchange the code server-side, and encrypt the resulting token at rest. For a workspace key, create it in developer settings with the minimum scopes and store it only in the approved secret manager.

Instructions

  1. Classify the integration as single-workspace or multi-workspace.
  2. Inventory methods and endpoints, then derive scopes from their current reference pages.
  3. Define secret storage, tenant-to-token mapping, rotation, revocation, and audit ownership.
  4. Implement server-side credential injection without token logging.
  5. For OAuth, bind and verify state; never expose the client secret to browser code.
  6. Verify with one read-only endpoint and record only status, workspace alias, and granted scope names.

Approval Boundaries

Do not generate or broaden production credentials, modify redirect URIs, or migrate tenant tokens without the owning administrator's approval and a rollback plan.

Output

Return the chosen auth model, endpoint-to-scope map, secret reference, OAuth control evidence if applicable, read-only verification, and rotation owner.

Error Handling

Condition Response
Tenancy model is unclear Stop before choosing a credential type.
OAuth state mismatch Reject the callback and start a fresh authorization flow.
403 after verification Compare the exact endpoint scopes; do not grant all scopes.
Token appears in logs Revoke or rotate it and scrub retained output.

Examples

Input:


tenancy=multiple-workspaces; endpoint=GET /v2/tasks; storage=encrypted-server-side

Expected handoff:


auth=oauth; state=verified; scopes=endpoint-derived; read-test=pass

Resources

Ready to use attio-pack?