> ## Documentation Index > Fetch the complete documentation index at: https://docs.nekt.com/llms.txt > Use this file to discover all available pages before exploring further. # Sympla as a data source > Bring your Sympla events, sessions, orders and participants (with check-in) to Nekt. 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. > [!NOTE] > > 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](https://app.nekt.ai/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. > [!TIP] > > 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](https://docs.nekt.com/runs/scheduling-and-triggers.md), 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](https://docs.nekt.com/get-started/core-concepts/resource-control). Once you are ready, click **Next** to finalize the setup. ### 5. Check your new source You can view your new source on the [Sources](https://app.nekt.ai/sources) page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog. > [!WARNING] > > For you to be able to see it on your [Catalog](https://app.nekt.ai/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. > [accordion] 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. | > [accordion] 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. | > [accordion] 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. | > [accordion] 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 > [card] [Download Sympla skills file](https://docs.nekt.com/sources/sympla.md) > > Sympla connector documentation as plain markdown, for use in AI agent contexts. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.