Reference · built on requestConnectorCRM & sales

Attio

People, company, and deal records, lists, notes, and tasks from an Attio workspace, with signed webhooks on change.

Request accessPricing ↗

About

Attio is a CRM built on a configurable data model. Objects such as people, companies, and deals hold records; lists group records into entries with attributes of their own; notes, tasks, and comments attach to either. Attio's REST API exchanges JSON over HTTPS, and webhooks fire on record, list-entry, note, task, comment, and workspace-member events, each signed with the webhook's secret.

Fibric reads the objects and lists you choose and subscribes to those webhooks. An operator proposes a record change or a list-entry update, a person approves it, and the write happens once and is recorded.

This is a reference listing. It documents what Fibric would read from Attio and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Records of any object through POST /v2/objects/{object}/records/query, with filter, sorts, limit (default 500), and offset
  • Saved views applied server-side through filter_view_id instead of a filter body
  • Objects and their attributes through GET /v2/objects, including the standard people, companies, and deals objects and any custom object
  • List entries, with the list's own attributes, through the entries endpoints
  • Notes and tasks attached to records
  • Webhook events record.created, record.updated, record.deleted, record.merged, list-entry.created, list-entry.updated, list-entry.deleted, note.created, task.created, and comment.created

Proposed actions

  • Target capability: propose an attribute update on a person, company, or deal record for a person to approve
  • Target capability: propose adding a record to a list, or updating a list entry's attributes
  • Target capability: propose a task on a record with an assignee and a deadline
  • Target capability: propose a note on a record explaining what changed and why

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Reply to new people on an inbound list

    When a list-entry.created event lands on your inbound list, the operator reads the person and company records and drafts the first reply and a task for the owner.

    With Lead Response

  • Keep deal records current

    Deal records with no note, task, or attribute change since a date you set are listed with their owner. The operator proposes the next step and a stage attribute update.

    With Stale Pipeline

  • Hand off a closed deal with the whole record

    A record.updated event on a deal's stage attribute triggers a handoff packet: company, people, notes, and open tasks. A person approves it before it goes to delivery.

    With Deal Handoff

  • Catch duplicate records before they diverge

    New people and company records are matched on email and domain. The operator proposes a merge, a person confirms it, and the record.merged event closes the loop.

    With Duplicate Lead

Requirements

  • An Attio workspace and an access token with the scopes each endpoint needs, for example record_permission:read and object_configuration:read
  • An HTTPS endpoint to register as a webhook target
  • Storage for each webhook's secret, used to check the Attio-Signature header
  • Handling for at-least-once delivery, since the same event can arrive more than once
Authentication
A single-workspace access token created in the workspace's developer settings, or OAuth 2.0 for an app installed in several workspaces; either is sent as a Bearer token and is limited to the scopes it was granted.

Limits

  • 100 read requests per second and 25 write requests per second; a 429 carries Retry-After, usually the following second
  • List records and list entries queries also carry a complexity score, judged over a 10-second sliding window across all tokens
  • Webhook delivery is capped at 25 requests per second per target URL, with a 5-second timeout per request
  • A failed webhook delivery is retried up to 10 times over roughly 3 days

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Attio ↗

Questions and answers

Which events can trigger the connector?
Attio's webhook reference lists record.created, record.updated, record.deleted, record.merged, list-entry.created, list-entry.updated, list-entry.deleted, note.created, note.updated, note.deleted, task.created, task.updated, task.deleted, comment events, list and attribute events, and workspace-member.created.
How does the connector confirm a webhook came from Attio?
Every delivery carries an Attio-Signature header, a SHA256 HMAC computed with the webhook's secret. The connector recomputes it and drops anything that does not match. Delivery is at least once, so a repeated event is expected and ignored.
What are the rate limits?
100 read requests and 25 write requests per second, plus a complexity score on record and entry queries. A 429 response includes Retry-After. Attio states the throttled request was not processed, so it can be retried once the limit resets.
Ask about Attio

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Attio through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy