Attio Record Lifecycle

Overview

This skill builds a record workflow from the workspace's actual object and attribute schema. It favors deterministic identity and reversible updates over blind create calls.

Prerequisites

• A named object slug or UUID and the target workspace
• Current attribute definitions for that object
• A stable matching attribute for assert or deduplication
• An approved write and deletion boundary

Tool Discipline

Use Read, Glob, and Grep to inspect the local data model, mapping code, tests, and request wrapper. Use WebFetch only for current official Attio documentation. Use Write or Edit after the object contract and approval boundary are explicit.

Current Contract

• Objects define attributes; records are instances of an object.
• Record values are shaped by each attribute type, not by one universal scalar rule.
• Query records with POST /v2/objects/:object/records/query; this endpoint uses limit and offset.
• Choose create versus assert deliberately. Assert is appropriate only when a documented matching attribute supplies stable identity.
• PUT and PATCH have different multiselect behavior; confirm the endpoint reference before updating.

Authentication

Send a single-workspace or OAuth access token as Authorization: Bearer <access_token>. Confirm the endpoint's object-configuration and record-permission scopes before any write.

Instructions

1. Resolve the object and fetch its current attribute definitions.
2. Map source fields to exact attribute slugs and value shapes; reject unknown mappings.
3. Choose query, create, or assert based on the integration's identity policy.
4. For updates, state whether multiselect values must be overwritten or appended and select the documented method.
5. Persist the Attio record ID and source identity mapping after a successful write.
6. Read the record back and compare only the fields owned by this integration.
7. Require explicit approval before deletion and verify the exact record identity afterward.

Approval Boundaries

Never infer a destructive target from a display name. Record deletion, bulk writes, schema changes, and overwrite updates require the exact workspace, object, record IDs, and owner approval.

Output

Return the schema snapshot, identity rule, request plan, redacted response evidence, read-after-write comparison, and rollback or cleanup status.

Error Handling

Examples

Input:

object=companies; operation=assert; match=domains; owned-fields=description,domains

Expected handoff:

schema=confirmed; identity=stable; write=verified; foreign-fields=untouched

Resources

• Skill-specific official documentation
• Objects and lists
• List records
• OpenAPI specification