attio-deploy-integration

Plan and execute a staged deployment for an external Attio REST integration with secret injection, contract tests, read-only smoke evidence, canary writes, and rollback. Use when releasing Attio-backed services. Trigger with "deploy Attio integration", "Attio rollout", or "Attio release plan".

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 Integration Rollout

Overview

This skill releases application code that calls Attio's REST API. It uses progressive evidence so a bad schema mapping, scope, or retry policy is caught before broad CRM mutation.

Prerequisites

  • A versioned application artifact and tested configuration
  • Environment-specific Attio workspace and secret references
  • A disposable canary record or approved read-only smoke path
  • Defined rollback owner, trigger, and previous artifact

Tool Discipline

Use Read, Glob, and Grep to inspect deployment manifests, secret names, health checks, migrations, and rollback commands. Use WebFetch only for current official Attio documentation. Use Write or Edit after the rollout target and approval boundary are confirmed.

Current Contract

  • Inject tokens from the deployment platform; never bake them into images or manifests.
  • Validate object and list schemas in the target workspace before enabling writes.
  • Keep read and write traffic controls separate because Attio publishes different limit tiers.
  • A successful process health check is not proof that CRM mutations are correct.

Authentication

Use the target environment's least-privilege single-workspace token or tenant-specific OAuth token. Confirm workspace identity and required endpoint scopes before canary traffic.

Instructions

  1. Compare artifact, configuration, secret references, workspace alias, and endpoint set with the approved release record.
  2. Run offline contract and redaction tests on the exact artifact.
  3. Deploy with Attio writes disabled and perform a bounded read-only smoke request.
  4. Confirm current object/list attributes and pagination behavior in the target workspace.
  5. Enable one idempotent or reversible canary write, then read it back.
  6. Expand traffic gradually while watching 4xx, 429, 5xx, latency, duplicate writes, and queue age.
  7. Roll back on a declared trigger and verify both application and CRM state.

Approval Boundaries

Production writes, token rotation, schema changes, and cleanup of canary data require exact target display and owner approval. Do not roll forward through unexplained validation or authorization failures.

Output

Return artifact identity, environment checks, read smoke, canary evidence, traffic stage, observed metrics, rollback status, and residual risks.

Error Handling

Condition Response
Workspace identity is uncertain Stop before enabling traffic.
Schema differs from staging Disable writes and reconcile mappings.
429 rate increases Hold or reduce traffic and honor Retry-After.
Canary is not reversible Do not use it; choose a safer proof.

Examples

Input:


artifact=release-sha; environment=production; writes=initially-disabled

Expected handoff:


read-smoke=pass; canary=verified; expansion=approved; rollback=ready

This result binds the rollout decision to the tested artifact and rollback path.

Resources

Ready to use attio-pack?