canonical: https://jentic.com/apis/attio.com/attio

# Attio API

Attio is a customisable CRM built around objects, attributes, and lists rather than fixed contact and deal tables. The API exposes the full data model: standard and custom objects (people, companies, deals, custom records), the attributes that describe them, list entries, notes, meetings, and workspace members. Operations are consistent across object types, so the same shape of call manages a person record, a company record, or a custom object - making it well suited to bidirectional sync with sales, ops, and product systems.

## For AI agents

Read and write Attio CRM data - objects, attributes, records, lists, notes, and meetings - using a consistent shape across standard and custom objects.

## Scope

Does not handle email sending, marketing automation, or telephony - use for CRM object, record, attribute, note, and meeting management only.

## Capabilities

- List, create, get, and update objects (people, companies, deals, custom) via /v2/objects
- Manage object and list attributes through /v2/{target}/{identifier}/attributes
- Create and read records and list entries to drive bidirectional CRM sync
- Attach notes and meetings to records to keep activity history aligned with sales data
- Manage workspace members and the SCIM schema surface for identity-aware integrations
- Maintain select-option dictionaries on attributes for picklist consistency

## Use cases

### Bidirectional Product to CRM Sync

Product teams want signups, plan changes, and usage milestones to land in Attio so the GTM team can act on them. The Attio API lets a sync agent map product events into person and company records via /v2/objects/{object} writes, then read CRM-side updates (deal stage, owner) back into product. The same operation shape works whether the target is a standard 'people' object or a custom 'workspaces' object.

Example prompt: When a product signup event fires, upsert a person record in Attio with the user's email, signup date, and plan, then write the linked company record

### Sales Activity Logging

Sales reps log calls, meetings, and notes against the company or deal they relate to. The /v2/notes and /v2/meetings endpoints accept references to the parent record, so a logging agent can post both into Attio with a single call apiece. Combined with deal updates, this keeps the activity stream in Attio rich enough to drive forecast and pipeline reviews.

Example prompt: After a Zoom call, create an Attio meeting record linked to deal id 'deal_123' with the title, attendees, and recording URL

### Custom Object Schema Management

Operations teams iterate on the Attio data model - adding attributes, renaming fields, adjusting select options. The attribute and select-option endpoints expose the schema as data, so a schema-management agent can promote changes from staging to production by reading the source workspace and applying matching writes. This avoids manual schema drift between workspaces.

Example prompt: Read attributes on the 'workspaces' object in workspace A and create matching attributes (with select options) in workspace B

### Attio Automation via Jentic

Through Jentic, an AI agent automating Attio searches by intent ('create a person record') and Jentic returns the matching /v2/objects/{object}/records operation with its attribute schema. The Attio OAuth credentials are held in your Jentic One instance, so the agent never sees the token. This makes CRM updates accessible directly from an LLM chat or scheduled workflow.

Example prompt: Use Jentic to search 'create an Attio person record', load the matching POST operation, and execute with the new contact's email and name

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v2/objects | List objects (standard and custom) |
| POST | /v2/objects | Create a custom object |
| GET | /v2/objects/{object} | Get a single object definition |
| PATCH | /v2/objects/{object} | Update an object definition |
| GET | /v2/{target}/{identifier}/attributes | List attributes on an object or list |
| POST | /v2/{target}/{identifier}/attributes | Create an attribute |
| GET | /v2/{target}/{identifier}/attributes/{attribute}/options | List select options for an attribute |

## Key resources

- **Objects** — Standard and custom object definitions (people, companies, deals)
- **Attributes** — Attribute definitions for each object or list
- **Records** — Object records - the actual data rows
- **Lists** — List definitions used for pipelines and segmentation
- **Entries** — List entries linking records into a list
- **Notes** — Notes attached to records
- **Meetings** — Meeting records attached to people, companies, or deals
- **Workspace Members** — Users in the Attio workspace
- **Meta** — Workspace and identity metadata
- **SCIM schemas** — SCIM schema definitions for identity provisioning

## Why Jentic

- **Setup:** Wiring Attio by hand means running its OAuth 2.0 flow for a scoped bearer token and threading object and target identifiers through its CRM paths. Through Jentic you install once, import the Attio API from the API Directory, store the client credentials once, and your agent calls it.
- **Permission scoping:** Attio puts the object and target identifier in the URL path (/v2/objects/{object}, /v2/{target}/{identifier}/attributes), so a rule can pin your agent to one object such as people. You choose the operations it may call, so patching an object is not included unless you add it alongside reads.
- **Credential handling:** Your Attio client credentials are stored once, encrypted, by your own Jentic One instance and exchanged for a scoped bearer token at execution time. The raw secret never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an Attio person record', and Jentic returns the matching object and record operation with its attribute schema so the agent posts the right shape across standard and custom objects.

## Related APIs

- **HubSpot** — Established CRM with marketing and sales hubs
- **Salesforce** — Enterprise CRM with deep customisation and SOQL
- **Pipedrive** — Sales-pipeline focused CRM

## FAQ

### What authentication does the Attio API use?

The Attio API uses OAuth 2.0. Through Jentic, the OAuth credentials are held in the encrypted vault and a scoped access token is exchanged at call time, so the raw client secret never enters the agent's context.

### Can I create custom objects with the Attio API?

Yes. POST /v2/objects creates a new object definition in the workspace, and the /v2/{target}/{identifier}/attributes endpoints let you add attributes (including select options) to that object. Records on the new object are then managed through the same shape as standard people and companies.

### What are the rate limits for the Attio API?

Attio throttles per workspace, with limits documented in the developer portal. The spec does not encode them numerically - back off on HTTP 429 responses and prefer batched reads (filter + page) over per-id polling.

### How do I attach a note to a record through Jentic?

Search Jentic for 'create an Attio note', load the POST /v2/notes operation, and execute with the parent record reference and note body. Jentic injects the OAuth bearer and validates the parent_record_id before the call hits api.attio.com.

### Can I list attributes on a list as well as on an object?

Yes. The endpoint shape is /v2/{target}/{identifier}/attributes where {target} is 'objects' or 'lists', so the same call returns attributes on either, keeping a custom integration consistent across both surfaces.

### Does the Attio API expose SCIM for identity provisioning?

Yes. The spec includes a SCIM schemas resource, so identity providers can read the schema definitions Attio expects when provisioning workspace members.

### Can I limit what my agent is allowed to do with the Attio API?

Yes. Because your Jentic One instance is self-hosted, your own rules decide which Attio operations and credentials the agent may use. Attio carries the object and target identifier in the URL path (/v2/objects/{object} and /v2/{target}/{identifier}/attributes), so a rule can pin the agent to a single object such as people and to specific calls. You choose the operations it may run, so a write like PATCH /v2/objects/{object} is not available unless you add it alongside the reads.