Connectors
Every vendor, file, and step gtme can run, on one page. Each entry is generated from the adapter itself, so this list can't say something the binary doesn't.
gtme's own word for a connector is adapter. A connector is what most people search for, so it is the word on these pages; in a pipeline file and in the CLI it is an adapter, and the declarative kind is a binding: a directory of YAML and recorded fixtures that cannot execute code. Three tiers, one way to use them:
- Built in ships inside the binary. Write
use: apollo/searchandgtme planresolves it. - Verified lives in the gtme-bindings registry, where CI runs its fixtures.
gtme adapters addfetches it at a pinned commit, verifies it offline, and installs it. - Community lives in its author's repository and is listed in the same index. Same install, same verification, maintained by whoever wrote it.
An entry whose fixtures stop passing drops off the index, and with it off this page. Agents read the same index through gtme adapters search.
Vendors
APIs that hold or receive your records. Each needs one credential, stored once with gtme secret.
Apollo
B2B contact database. Search finds people at $0 with names and titles but no email; enrich reveals the rest per record.
| Connector | Role | Cost | Tier |
|---|---|---|---|
apollo/enrichReveal one searched Apollo person by id: email, full name, LinkedIn, location and company details, one credit per match. | enrich | $0.01 per record | verified |
apollo/searchSource people from Apollo's API search: masked rows (first name, title, company, has-email) at no credit cost; reveal the ones worth paying for with apollo/enrich. | source | $0 | verified |
Attio
CRM. Records are asserted into an object and matched on email, so a re-run updates rather than duplicates.
| Connector | Role | Cost | Tier |
|---|---|---|---|
attio/assertDeliver a person to Attio by asserting (upserting) the record on email; idempotent natively, so re-delivery never duplicates. | deliver | $0 | verified |
Harvest API
LinkedIn profile data by URL: headline, about, role history, recent posts.
| Connector | Role | Cost | Tier |
|---|---|---|---|
harvest/post-searchSource people from LinkedIn post content via HarvestAPI post search — the record is the post's author, with the post itself carried alongside so a downstream step can quote what surfaced them; page pagination, `limit` is the spend control. | source | $0 | verified |
harvest/profileEnrich a person from their LinkedIn profile via HarvestAPI, by any LinkedIn URL shape: headline, about, location, current role and company, role history. | enrich | unset | verified |
harvest/recent-postsEnrich a person with the text of their recent LinkedIn posts via HarvestAPI, at most posts_limit, for a compose step to read. | enrich | unset | verified |
HubSpot
CRM. Contacts come out through the CRM v3 Search API.
| Connector | Role | Cost | Tier |
|---|---|---|---|
hubspot/contact-searchSource HubSpot contacts via the CRM v3 Search API, filtered by one HAS_PROPERTY predicate — reproduce a list's membership server-side; cursor pagination, standard portal properties only. | source | $0 | verified |
Instantly
Cold email sending. Records become leads in a campaign, with merge variables from the ledger.
| Connector | Role | Cost | Tier |
|---|---|---|---|
instantly/add-to-campaignAdd a person to an Instantly campaign, named by its id; preflights the campaign and attests each lead by re-reading it. | deliver | $0 | verified |
Files and HTTP
The floor. A CSV on disk or a URL you control, at either end of a pipeline.
CSV files
A file on disk as the start or the end of a pipeline. No keys, no spend.
| Connector | Role | Cost | Tier |
|---|---|---|---|
csv/deliverAppends each record to a CSV file, one column per step variable. The file gets a header on first write. | deliver | $0 | built in |
csv/sourceReads people or companies from a CSV file. The header row names the fields; columns maps the rest onto canonical names. | source | unset | built in |
HTTP
Any URL. Fetch a page or a JSON endpoint per record, or post each record to an endpoint you run.
| Connector | Role | Cost | Tier |
|---|---|---|---|
http/deliverPosts each record to a URL you choose, with the body templated from the step's variables. The endpoint is yours. | deliver | unset | built in |
http/enrichFetches a URL templated from the record's fields and stores the page as markdown, or extracts fields from a JSON response. | enrich | unset | built in |
Steps
Judgment in the middle of a pipeline: a model, an agent, a person, or a template answers per record.
AI steps
A model reads each record and answers the step's declared fields. Needs ANTHROPIC_API_KEY; the receipt shows the spend per step.
| Connector | Role | Cost | Tier |
|---|---|---|---|
ai/composeA model writes the step's declared fields from a template over the record's fields, in batches, with fetched fields fenced as data. | compose | unset | built in |
ai/filterA model keeps or drops each record against a template. The verdict and its reason are cached, so a re-run spends nothing. | filter | unset | built in |
ai/reviewA model reviews each record and answers the step's declared fields. | review | unset | built in |
Agent steps
The same three roles as the AI steps, answered by an agent you run instead of a model the runner calls. Records wait in the ledger for gtme answer.
| Connector | Role | Cost | Tier |
|---|---|---|---|
agent/composeAn agent writes the step's declared fields for each record, shown a template over the record's fields. | compose | unset | built in |
agent/filterAn agent decides pass or fail for each record, and the reason lands in the ledger. | filter | unset | built in |
agent/reviewAn agent reviews each record and answers the step's declared fields. | review | unset | built in |
Human steps
A person answers, at the terminal as the run walks the records or later with gtme answer.
| Connector | Role | Cost | Tier |
|---|---|---|---|
human/composeA person writes the step's declared fields for each record, at the terminal or later with gtme answer. | compose | unset | built in |
human/filterA person decides pass or fail for each record, at the terminal or later with gtme answer. | filter | unset | built in |
human/reviewA person reviews each record and answers the step's declared fields. | review | unset | built in |
Text steps
A template rendered per record, no model call, $0.
| Connector | Role | Cost | Tier |
|---|---|---|---|
text/composeRenders one template per record into one field. No model, no key, $0. | compose | unset | built in |
Demo
A keyless, pretend-priced enrichment for practicing runs and receipts. It calls no one and spends nothing.
| Connector | Role | Cost | Tier |
|---|---|---|---|
demo/enrichScores each record with a pretend price so a first run has a receipt with numbers in it. No key, no network, no spend. | enrich | $0.01 per record | built in |
A vendor that isn't here
Write it. A binding is a YAML file and one recorded response per request, and an agent can draft one from the vendor's API docs in a few minutes. Add a vendor walks through it, gtme help --bindings prints the contract, and a pull request to gtme-bindings puts it on this page.