Connectors › Attio

Attio assert

Deliver a person to Attio by asserting (upserting) the record on email; idempotent natively, so re-delivery never duplicates.

Connector	`attio/assert`
Role	deliver
Records	person
Tier	verified since 2026-09-27
Credential	`ATTIO_API_KEY` stored once with `gtme secret set ATTIO_API_KEY`
Cost	$0
Calls	`PUT https://api.attio.com/v2/objects/{{config.object}}/records`
Source	github.com/gtme-run/gtme-bindings/attio-assert

Use it

Install it from the registry. Nothing installs unverified: the fixtures run offline first.

gtme adapters add github.com/gtme-run/gtme-bindings/attio-assert@main

The command prints the hosts the binding will call and the credentials it will ask for, then pins the commit it fetched. Then, in a pipeline file:

steps:
  - id: assert
    use: attio/assert

gtme plan pipeline.yaml checks the credential is set and that every field this step needs is provided by a step before it, without calling anyone.

Needs

Whatever fields the step's uses: line names. The runner checks them at plan time.

Provides

Nothing. A deliver step writes to the target and records a receipt.

Config

Key	Type	What it does
`object`	string	Attio object slug to assert into Default `people`.
`matching_attribute`	string	Attribute Attio matches existing records on Default `email_addresses`.
`base_url`	string	Override the API host (testing) Default `https://api.attio.com`.

What a response looks like

Recorded from a real response to PUT /v2/objects/people/records, status 200. The conformance kit proves this payload in produces canonical records out, and gtme run --simulate serves it in place of the network.

{
  "data": {
    "id": {
      "workspace_id": "ws_fixture",
      "object_id": "obj_people",
      "record_id": "rec_fixture_1"
    },
    "created_at": "2026-08-16T00:00:00.000000000Z"
  }
}

On this page, connector means what gtme calls an adapter. This one is a binding from the registry. Two adapter tiers explains the difference.