Sympla is a Brazilian platform for selling tickets and managing events, both in person and online. This connector reads your producer account through the official Sympla Public API and brings your events, their sessions (apresentações), every order with buyer, totals, invoice data and UTM, and every participant (ticket) with sector, prices, custom form answers and check-in.

The connector only reads data. It never performs check-ins or creates, changes or deletes anything in Sympla.

Configuring Sympla as a Source

In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Sympla option from the list of connectors. Click Next and you’ll be prompted to add your access.

1. Add account access

The Sympla Public API uses an API token generated by the event producer. Log in to Sympla with the producer account, go to Minha Conta > Integrações and generate (or copy) the token.

API Token: the token you copied.
Start Date: the earliest date synced for orders and participants. Orders and participants created or updated since this date are loaded. Events and sessions are always loaded in full.

The token reads every event of the producer account. If you generate a new token in Sympla, update the source with it.

Once you’re done, click Next.

2. Select streams

Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.

Tip: The stream can be found more easily by typing its name.

Select the streams and click Next.

3. Configure data streams

Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.

Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
Sync Type: keep the suggested type. Orders and Participants are Incremental: each sync reads only what changed since the previous one and merges it into the table. Events and Sessions are Full table: each sync reads them whole and replaces the table.

Once you are done configuring, click Next.

4. Configure data source

Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times). Orders and participants are read incrementally, so an hourly or daily sync works well. During an event, an hourly sync keeps check-ins up to date. Optionally, you can configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here. Once you are ready, click Next to finalize the setup.

5. Check your new source

You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.

For you to be able to see it on your Catalog, you need at least one successful source run.

Streams and Fields

Available streams

The table below lists every stream, its slug (the exact identifier to pass when creating the source via API) and a short description.

Stream	Slug	Sync	Description
Events	`events`	Full table	Every event of the producer account, published or not, past and future, with venue, organizer and categories.
Sessions	`presentations`	Full table	Sessions (apresentações) of every event, with dates, publication and sectors.
Orders	`orders`	Incremental	Every order, cancelled and refunded ones included, with buyer, totals, payment method, invoice data and UTM.
Participants	`participants`	Incremental	Every participant (ticket), cancelled ones included, with ticket type, sector, prices, custom form answers and check-in.

Join orders.event_id, participants.event_id and presentations.event_id with events.id, and participants.order_id with orders.id. Check-ins are part of each participant (check_in, check_in_date).

Fields by stream

Fields marked String (JSON) hold a nested object or list as JSON text; use your warehouse’s JSON functions to read them. Dates are in UTC.

Events

Every event of the producer account.Table: events · Primary key: id · Sync: Full table

Field	Type	Description
`id`	String	Unique identifier (hash) of the event in Sympla; the `event_id` of sessions, orders and participants.
`reference_id`	Integer	Numeric reference id of the event, as shown in the Sympla event URL and panel.
`name`	String	Name of the event.
`detail`	String	Description of the event (HTML), when the API sends it.
`start_date`	Datetime	Date and time the event starts.
`end_date`	Datetime	Date and time the event ends.
`private_event`	Boolean	Whether the event is private (not listed publicly on Sympla).
`published`	Boolean	Whether the event is published.
`cancelled`	Boolean	Whether the event was cancelled.
`image`	String	URL of the event’s cover image.
`url`	String	Public URL of the event page on Sympla.
`address_name`	String	Name of the venue.
`address_street`	String	Street of the venue.
`address_number`	String	Street number of the venue.
`address_complement`	String	Address complement of the venue.
`address_neighborhood`	String	Neighborhood of the venue.
`address_city`	String	City of the venue.
`address_state`	String	State of the venue.
`address_zip_code`	String	Postal code (CEP) of the venue.
`address_country`	String	Country of the venue.
`address_lat`	Number	Latitude of the venue.
`address_lon`	Number	Longitude of the venue.
`host_name`	String	Name of the event organizer (host).
`host_description`	String	Description of the event organizer (host).
`category_prim`	String	Primary category of the event.
`category_sec`	String	Secondary category of the event.

Sessions

Sessions (apresentações) of every event, published or not.Table: presentations · Primary key: event_id, id · Sync: Full table

Field	Type	Description
`id`	Integer	Unique identifier of the session; the `presentation_id` of orders and participants.
`event_id`	String	Identifier of the event the session belongs to.
`start_date`	Datetime	Date and time the session starts.
`end_date`	Datetime	Date and time the session ends.
`start_date_utc`	Datetime	Date and time the session starts, as Sympla sends it in UTC.
`end_date_utc`	Datetime	Date and time the session ends, as Sympla sends it in UTC.
`published`	Boolean	Whether the session is published.
`enabled`	Boolean	Whether the session is enabled for sale.
`closed`	Boolean	Whether the session is closed.
`private_presentation`	Boolean	Whether the session is private.
`presentation_url`	String	Public URL of the session on Sympla.
`sectors`	String (JSON)	Sectors of the session, with id, name and whether they are sold online.

Orders

Every order of every event, cancelled and refunded ones included.Table: orders · Primary key: event_id, id · Sync: Incremental (by updated_date)

Field	Type	Description
`id`	String	Unique identifier of the order in Sympla.
`event_id`	String	Identifier of the event the order belongs to.
`presentation_id`	Integer	Identifier of the session the order is for.
`order_date`	Datetime	Date and time the order was placed.
`updated_date`	Datetime	Date and time the order was last updated.
`approved_date`	Datetime	Date and time the order was approved.
`order_status`	String	Status of the order as Sympla reports it (approved, pending, cancelled, refunded and so on).
`transaction_type`	String	Payment method (transaction type) of the order.
`discount_code`	String	Discount (coupon) code used in the order.
`order_total_sale_price`	Number	Total amount paid by the buyer, in BRL.
`order_total_net_value`	Number	Net amount of the order for the producer after Sympla fees, in BRL.
`buyer_first_name`	String	First name of the buyer.
`buyer_last_name`	String	Last name of the buyer.
`buyer_email`	String	Email address of the buyer.
`invoice_info`	String (JSON)	Invoice (nota fiscal) data informed by the buyer: document type and number, name and address.
`utm_source`	String	UTM source of the visit that generated the order.
`utm_medium`	String	UTM medium of the visit that generated the order.
`utm_campaign`	String	UTM campaign of the visit that generated the order.
`utm_term`	String	UTM term of the visit that generated the order.
`utm_content`	String	UTM content of the visit that generated the order.
`utm_referrer`	String	Referrer URL of the visit that generated the order.
`utm_user_agent`	String	Browser user agent of the visit that generated the order.

Participants

Every participant (ticket) of every event, cancelled ones included, with check-in.Table: participants · Primary key: event_id, id · Sync: Incremental (by ticket_updated_at)

Field	Type	Description
`id`	String	Unique identifier of the participant (ticket) in Sympla.
`event_id`	String	Identifier of the event.
`presentation_id`	String	Identifier of the session of the ticket.
`order_id`	String	Identifier of the order the ticket belongs to (`orders.id`).
`item_id`	String	Identifier of the order item of the ticket.
`ticket_number`	String	Ticket number (código do ingresso).
`ticket_num_qr_code`	String	Value encoded in the ticket’s QR code.
`ticket_status`	String	Status of the ticket.
`ticket_name`	String	Name of the ticket type bought.
`ticket_created_at`	Datetime	Date and time the ticket was created.
`ticket_updated_at`	Datetime	Date and time the ticket was last updated.
`ticket_sale_price`	Number	Price paid for the ticket, in BRL.
`ticket_net_value`	Number	Net value of the ticket for the producer, in BRL.
`ticket_group_id`	Integer	Identifier of the ticket group, when the event groups its tickets.
`ticket_group_name`	String	Name of the ticket group.
`ticket_subgroup_id`	Integer	Identifier of the ticket subgroup.
`ticket_subgroup_name`	String	Name of the ticket subgroup.
`sector_name`	String	Sector of the ticket.
`marked_place_name`	String	Reserved seat (lugar marcado) of the ticket.
`access_information`	String	Access information of the ticket.
`first_name`	String	First name of the participant.
`last_name`	String	Last name of the participant.
`email`	String	Email address of the participant.
`order_status`	String	Status of the order of the ticket.
`order_date`	Datetime	Date and time the order of the ticket was placed.
`order_updated_at`	Datetime	Date and time the order of the ticket was last updated.
`order_approved_date`	Datetime	Date and time the order of the ticket was approved.
`order_discount`	String	Discount applied to the order of the ticket.
`check_in`	Boolean	Whether the participant checked in.
`check_in_date`	Datetime	Date and time of the participant’s check-in.
`check_in_id`	Integer	Identifier of the check-in.
`checkin`	String (JSON)	Check-in data exactly as Sympla sends it.
`custom_form`	String (JSON)	Answers to the event’s custom registration form, with id, name and value of each question.
`included_items`	String (JSON)	Items included with the ticket (kit), when Sympla enables them for the account.

Implementation Notes

Data Quality Considerations

How orders and participants stay up to date. Each sync reads, for every event, the orders and participants changed since the previous sync (with two days of margin). A new event is read in full from the Start Date. If a sync fails, the next one reads the same period again.
Check-ins. Participants of current events (events that ended in the last 7 days, have not ended yet, or have no date) are read in full on every sync, so check-ins made at the door are always loaded, even if Sympla does not mark the ticket as updated.
Drafts and removed events. If Sympla answers “not found” for the orders or participants of an event (for example a draft), that event is skipped, the sync log says so the first time, and it is read in full once Sympla answers. Sessions of an event removed in Sympla while the sync runs are skipped too.
Order status on participants. Use orders.order_status (joined by participants.order_id) as the reference status of a sale: a refund made after the event may not update the participant rows of a past event.
Cancelled and refunded orders are kept, with their current status. Filter by order_status or ticket_status when you need only valid sales.
Unpublished events and sessions are included. Filter by published when you need only public ones.
Affiliates are not available. The current Sympla Public API does not document affiliate (afiliados) data.
Full table tables are never half updated. The connector reads all the data of a full table table before writing any of it. If Sympla fails while it is read, nothing of that table is sent and the sync shows it as failed. On GCP (BigQuery) the table keeps its previous content; on AWS, a full table table whose stream failed may be emptied by the load step until the next successful sync. If the Events table suddenly comes back empty, the sync fails for that table instead of emptying it; if the events really were removed in Sympla, run a full sync of the source to accept it.

API Limits & Performance

Sympla does not publish a request limit. The connector makes at most 5 requests per second and, when Sympla asks it to slow down, waits and tells you in the sync log.
Each sync makes about five requests per event with every table selected (sessions, orders and participants), plus more pages for events with many orders or participants. An account with 2,000 events takes over 30 minutes per sync. If you do not need sessions, deselect the Sessions table to make each sync shorter.
The first sync reads every order and participant since the Start Date.

Troubleshooting

Error or symptom	What it means	What to do
”Sympla rejected the API token of this source”	The token is wrong, was revoked, or a new one was generated since.	Generate or copy the token under Minha Conta > Integrações (logged in as the producer) and update the source.
”The Sympla API token of this source is not allowed to read these tables”	Sympla refused the token for some tables (HTTP 403). Those tables were skipped and not updated; the other tables loaded.	Use the token of the producer account that owns the events (Minha Conta > Integrações), or deselect those tables.
”The Sympla API token of this source is not allowed to read any of the selected tables” or “…to list the account’s events”	Sympla refused the token for every selected table (HTTP 403), so nothing was synced.	Use the token of the producer account that owns the events (Minha Conta > Integrações). If it repeats, contact Nekt support.
”Sympla answered ‘not found’ for the orders (or participants) of N event(s)“	Those events (for example drafts) have no orders or participants available yet.	No action needed; they are read again in the next syncs.
”Sympla is limiting how fast this sync may read”	The request limit was reached, possibly together with other integrations using the same token.	No action needed; the sync waits and continues.
”Sympla returned no events records at all, although the previous sync read N”	Sympla returned an empty event list for an account that had events. The table was kept.	If the events really were removed, run a full sync of the source. Otherwise run the sync again later.
”Could not reach Sympla” or “Sympla kept failing”	Sympla did not answer, or answered with errors, after several attempts.	Usually temporary; the next sync tries again.
”Sympla answered … in a format this connector does not recognize” or “Sympla pointed back to a … page already read”	The Sympla API changed or answered in an unexpected way.	Contact Nekt support.

Skills for agents

Download Sympla skills file

Sympla connector documentation as plain markdown, for use in AI agent contexts.

Get started

Context

Activate

Organizations

Workspaces

Resources

Sympla as a data source

Configuring Sympla as a Source

1. Add account access

2. Select streams

3. Configure data streams

4. Configure data source

5. Check your new source

Streams and Fields

Available streams

Fields by stream

Implementation Notes

Data Quality Considerations

API Limits & Performance

Troubleshooting

Skills for agents

Download Sympla skills file