Skip to Content
SyncGTM PlatformLead SourcingHTTP Request

HTTP Request

The HTTP Request action lets you get or push data between your table and any external API. Call external tools, trigger downstream workflows, send updates to a CRM, or hit an internal service — all from a single row.

It works with any API that accepts POST, GET, PUT or DELETE.

When to use it

  • You want to push enriched data to another system (CRM, Slack, Notion, Google Sheets)
  • You want to trigger an action in an external tool as part of your Sync GTM workflow
  • You want to call a third-party API — a Zapier webhook, an internal tool, your own backend
  • You want to chain responses and send conditional data across platforms

It is the escape hatch: anything without a built-in integration is reachable this way.

Step-by-step guide

  1. Go to your Sync GTM table
  2. Click Add Action → Integration → HTTP Request
  3. Choose the HTTP method (POST, GET, PUT, DELETE)
  4. Enter the API Endpoint URL
  5. Add optional headers (for example, Authorization)
  6. Write your Payload Body — reference row values as dynamic variables like {{domain}} or {{email}}
  7. Click Save and run the action per row or in bulk

Enable Save Response to store the API’s response in a new column.

📹 Video guide: using the HTTP Request action

Schedule Auto Import

When HTTP Request is used as an import (Table → Import → HTTP Request), turn on Enable Auto Import to poll the endpoint on a frequency instead of calling it once. Each run reuses the saved method, URL, headers, payload and column mapping, and appends new items from the response to the same table.

  • Run it manually once and confirm both the response shape and the mapping first — a schedule built on an unverified mapping repeats the same mistake every run
  • Only schedule reads. A GET polled hourly is fine; a POST that writes to another system is not something to run unattended
  • Match the frequency to the other side’s rate limits, and expect to be throttled if the endpoint is strict
  • Dedupe on the response’s stable ID field — most endpoints re-return the same window of items on every call
  • Parse JSON the saved response so each scheduled run lands in typed columns
  • Pick the slowest frequency the use case tolerates — an unattended poll spends credits on every run, whether or not the endpoint returned anything new
  • Pair it with Auto Run so rows a scheduled run creates enrich themselves

Every schedule appears under Manage scheduled imports, where you can pause, edit, run now, or delete it.

Common use cases

  • An HTTP Request column calls a niche or internal API that has no ready-made action
  • Enriched rows get pushed to Slack, Notion or a sheet as they complete
  • A row’s status is written back to the system that created it
  • A second table or an internal service is queried mid-workflow and its answer gates the next step

Best practices

  • Put credentials in headers, not in the payload body
  • Enable Save Response so failures are debuggable instead of invisible
  • Check the response body, not just that the column ran — many APIs return 200 with an error inside
  • Reference row values as dynamic variables rather than hardcoding them
  • Watch the other side’s rate limits — run the column in batches if the API is strict
  • Test on one row before running the column; a bad POST at volume is not undoable

Where to next

  • Set Up a Webhook — the other direction: let rows arrive on their own
  • Actions — dynamic variables and per-row testing
  • Parse JSON — break a saved response into columns
  • API Key — authenticating calls back into Sync GTM
RSS FeedManage scheduled imports