Pull data, not just push

Webhooks send. The API answers.

Read every contact, event, and guest list on demand. Write new records back. Two-way access, on your schedule.

Core resources

The objects you work with in the app.

Contacts, events, and custom fields, available over HTTPS. JSON in, JSON out. Documented at buildwithgatsby.com.

Add-on access

Talk to sales to enable.

Pricing scopes to your use case. Your account team handles access as part of your contract.

Why it matters

Webhooks handle most CRM sync. The API handles everything else.

If you need to push RSVPs into HubSpot or Airtable when a guest registers, webhooks and Zapier cover it. The API is for the workflows webhooks can’t reach: pulling guest history into a data warehouse on a schedule, creating events from a portfolio-company tracker, or running a bulk update against thousands of contacts.

How it works

REST over HTTPS

Standard endpoints, JSON payloads, bearer-token authentication scoped to your organization. Any language with an HTTP client works.

Same data as the app

The API reads from and writes to the same records your team sees in Gatsby. A contact updated through the API appears in the app immediately, with full event history intact.

When to reach for the API

Most teams never need it. Webhooks plus a native CRM integration covers the work. Reach for the API when one of these is true.

Webhooks send one direction. The API reads both.

A webhook fires when something changes inside Gatsby. That’s perfect for keeping a CRM current, but it can’t answer questions on demand. The API can. Pull the full guest list for an event at any time, look up a contact’s complete event history, or fetch every contact who attended your last three dinners.

Signals that you need the API, not webhooks

You need to pull data into your stack on your schedule, not when Gatsby decides to push it
You need to create records from another system (events, contacts, guest lists)
You’re running bulk operations that would be impractical through the app
Your destination tool isn’t supported by Zapier, Make, or n8n, or the available connector is too limited
You’re building an internal dashboard, data warehouse pipeline, or AI workflow that needs structured access

Signals that webhooks are enough

You want guest activity in your CRM as it happens
Your destination is HubSpot, Airtable, Salesforce, Attio, Notion, or another well-supported Zapier app
You don’t need to write data back into Gatsby
You don’t have engineering resources to build and maintain custom integrations

If everything on that list is true, start with the Webhooks & Zapier page instead. You can layer the API on later.

A diagram showing one-way webhook push compared to two-way API access

What the API exposes

Four resource groups, matching the objects your team already works with in the app. The technical reference lives at buildwithgatsby.com. The sections below describe what each resource is useful for.

Contacts

The Person resource gives your developers full read and write access to contact records. Pull a single contact with their event history, search by name or email, list every contact in your org, or create and update records from outside Gatsby.

What you can do with contacts

Read a contact with their complete event participation history
Search contacts by name or by exact email match
List all contacts with pagination for large databases
Create new contacts from an external system (your CRM, your data warehouse, a sign-up form on your own site)
Update contacts including company, title, address, and any custom field
Sync core fields like firstName, lastName, email, company, position, address, and birthday

When teams use this

A VC firm pushes new LPs from their deal-flow tool into Gatsby automatically, so the next event invitation already has the right context
A university development team updates donor records from their fundraising database before every gala
A B2B field marketing team backfills contact records from Salesforce so seating preferences and dietary restrictions carry forward

Events and guest lists

The Event resource lets you list events, then read, add, update, or remove guests on any one of them. Guest list operations include RSVP status and attendance, so you can build registration flows and check-in workflows on top of Gatsby.

What you can do with events and guest lists

List events with pagination
Read the full guest list for an event, with RSVP and attendance status
Add guests to an event (creating new contacts or attaching existing ones)
Update guests to change RSVP status, mark attendance, or adjust custom fields
Remove guests from an event

When teams use this

A conference team pipes registrations from a custom landing page directly into the Gatsby guest list
An investor-relations team auto-populates the guest list for a quarterly LP meeting from their portfolio system, so the right names are pre-loaded the moment the event is created
A membership organization syncs member status changes into RSVP records, so revoked members can’t register for upcoming events

Custom fields

Custom fields are how your team categorizes contacts inside Gatsby. The API lets you manage the field definitions themselves: list every custom field, create new ones, and add options to multi-select fields. Text, number, and multi-select types are all supported.

What you can do with custom fields

List every custom field your org has defined, with all options
Read a single field by ID
Create new fields programmatically, with case-insensitive duplicate protection
Add options to existing multi-select fields, with optional color coding
Configure number fields as currency, percentage, or decimal

When teams use this

A team rolling out a new tagging taxonomy creates dozens of fields at once instead of clicking through the app
An ops team keeps Gatsby custom fields in lockstep with their CRM properties through a nightly sync
A field marketing team adds new product-interest options to a multi-select field whenever the product team ships a new SKU

Webhooks

You can configure webhook subscriptions through the API as well as through the in-app settings. Useful when you need to register and tear down webhooks programmatically (for example, when spinning up a new environment) or when you want to inspect a sample payload before writing receiver code.

What you can do with webhooks

Register a new webhook to receive real-time notifications
Remove an existing webhook
Fetch a sample payload for testing your receiver before going live
Subscribe to Event, EventPerson, and GuestList change notifications

What teams build with it

Concrete patterns we see most often. Most start with one of these and layer on more once the integration is live.

Custom CRM sync where Zapier falls short

Your CRM has its own data model, validation rules, and permissions. When a Zapier zap can’t handle the logic, teams build a small service that reads from Gatsby on a schedule, runs their own matching logic, and writes back to the CRM.

Auto-create events from another system

Investor-relations teams build the event in their portfolio system. Field marketing teams build the event in their campaign-planning tool. The API creates the matching Gatsby event and pre-loads the guest list so nobody has to enter it twice.

Internal dashboards and reporting

Pull attendance and RSVP data across a year of events into a BI tool or a custom dashboard. The API surfaces the same structured data the app uses, so the numbers in your dashboard match the numbers in Gatsby.

Data warehouse pipelines

Land Gatsby data in Snowflake, BigQuery, or Redshift alongside your CRM and product data. Schedule a nightly job that reads contacts, events, and guest lists, then transforms them for your analytics layer.

AI workflows and MCP servers

The same structured data that feeds a CRM sync feeds an AI assistant. Several teams have built MCP servers on top of the Gatsby API so their AI tools can answer questions about guest history, attendance patterns, and event context directly.

Bulk operations and migrations

Importing thousands of contacts from a legacy system, applying a new tagging taxonomy retroactively, or cleaning up duplicates from an acquired list. Operations that would take days through the app run in minutes through the API.

How it works

A one-screen primer for the technical reader. The full reference is at buildwithgatsby.com.

The basics

Protocol and format

REST over HTTPS. Standard verbs (GET, POST, PUT, DELETE).
JSON request and response bodies.
Pagination on list endpoints via limit and skip query parameters.

Authentication

Bearer token obtained through the /login endpoint with your account credentials.
Every request includes your organization slug alongside the token, so the API knows which Gatsby workspace you’re acting on.
Token issuance, rotation, and storage live with your team. Treat tokens the same way you treat any other production secret.

Resources covered

Persons (contacts), with search and event-history lookups
Events, with full CRUD on guest lists
Custom fields, including options for multi-select fields
Webhooks, for programmatic subscription management

Read the full reference

Endpoint paths, request shapes, response examples, error codes, and pagination patterns all live at buildwithgatsby.com. Send the link to your engineering team before your sales call so they can scope the integration ahead of time.

The API works hand in hand with webhooks. Most production integrations use the API for reads and writes on a schedule, and webhooks for real-time notifications. The two are designed to be used together.

Cost and getting access

The Gatsby API is an add-on. Reach out to Gatsby’s sales team and they’ll scope pricing to your use case and add it to your contract.

Common Questions

How is the API different from webhooks and Zapier?

Webhooks push notifications out of Gatsby when something changes. Zapier routes those notifications to other apps. The flow is one-way and reactive. The API is two-way and on demand: your code asks for data when it needs it, and writes data back when it has new data to share. Most production integrations use both.

Do I need engineering resources?

Yes. The API is a developer tool. If your team doesn’t have engineering capacity, start with webhooks and Zapier, or ask your account team about integration partners.

Is the data the same as what I see in the app?

Yes. The API reads from and writes to the same underlying records the app uses. A change made through the API shows up in the app immediately, and vice versa.

What languages does the API support?

Any language that can make HTTPS requests and parse JSON. There’s no official SDK; you call the endpoints directly.

Can I see the docs before I buy?

Yes. The full technical reference is public at buildwithgatsby.com. Read it, share it with your engineering team, then talk to sales about access.

How do I get API access?

Contact sales. The API is an add-on — your account team scopes pricing to your use case and handles it as part of your contract.