Skip to main content
SprintHub is a Brazilian all-in-one platform for sales, marketing and customer service: a CRM with Kanban funnels, an omnichannel service desk (SAC 360) that centralizes WhatsApp, Instagram, Messenger and e-mail, contact management with custom fields and custom objects, scheduling calendars, and custom reports. The connector extracts your contact base, the CRM funnels and their opportunities, the service history, and the custom objects and reports built on top of them, so you can analyse the whole commercial operation in your Lakehouse. Every SprintHub customer runs on its own instance, so the connector asks for the instance name in addition to the API key.

​
Configuring SprintHub as a Source

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

​
1. Add account access

SprintHub authenticates with an API key generated inside the platform. Click the gear icon in the top right corner, open Documentação e chave de API, and click Gerar Nova Chave. Give the key a name, choose the user it inherits permissions from, and leave its status enabled. Then set the permissions so the integration can read Contatos, Leads and Negociações, and click Salvar.
Copy the key exactly as it is displayed. Any character lost in the copy makes the connection fail with an authentication error.
The key inherits the permissions of the user it was created for, including that user’s departments and permission groups. Two keys on the same instance can therefore return different amounts of data. Generate it from a user who can see the whole operation.
To extract won and lost opportunities, the key’s user needs the CRM - Oportunidades Ganhas e Perdidas permission on their permission group. Without it, those cards are simply absent from the Opportunities table: the extraction still succeeds, so the gap is easy to miss.
The following configurations are available:
  • API URL: Base URL of your SprintHub API. SprintHub runs more than one API and which one serves your account depends on it, so request this URL from SprintHub support before setting up the source. Required.
  • Instance name: The name of your SprintHub instance, which is the subdomain in your panel URL. For https://mycompany.sprinthub.app the instance name is mycompany. Required.
  • API key: The key copied from Documentação e chave de API. Required.
  • Initial sync date: The earliest date from which meetings will be read, in the Calendar Meetings table. This is the only SprintHub endpoint that accepts a date filter, so it does not affect any other table. Leave it empty to start from January 2020.
  • Page size: How many records are requested per page. SprintHub recommends 25 to 50 and warns that larger pages increase the risk of a timeout. Defaults to 50.
  • Requests per minute: The maximum number of API calls per minute this source makes. Defaults to 90. Lower it if your runs are being rate limited, or raise it to sync faster.
  • Include archived opportunities: Also reads archived opportunities into the Opportunities table, flagged with is_archived. SprintHub has no combined view of archived and active opportunities, so enabling this doubles the number of API calls that table makes. Off by default.
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.
Five streams are read one API call per contact, because SprintHub only exposes them per contact and has no bulk endpoint for them: Lead Details, Lead Custom Objects, Attendances, Lead Files and Lead Tags. On a base of tens of thousands of contacts they make the run considerably longer and consume a large share of your plan’s API call allowance. Select them only if you need what they add, and consider putting them in a separate source with a less frequent trigger.
Lead Custom Objects costs one call per contact even when your instance defines no custom objects; on the base above, it spent an hour to return nothing. If the Custom Object Definitions table comes back empty, leave this one unselected.
Lead Details is the only way to reach the custom fields your instance defines for contacts. They arrive in a single custom_fields column as a JSON object, keyed by the field alias configured in SprintHub; custom fields differ from instance to instance, so they cannot be individual columns.
Report Charts reads the computed result of each custom report. SprintHub does not recalculate these on every request and advises reading each one at most three times a day, so a frequent trigger spends your API call allowance without bringing new numbers.
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: every SprintHub stream is full table. The API exposes no “modified since” filter on contacts, opportunities or conversations, so each run re-reads the collection in full. Read more about Sync Types here.
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). Optionally, you can define some additional settings:
  • 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.
  • Determine when to execute an Additional Full Sync. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
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.

​
Fields by stream

Below you’ll find all available data streams from SprintHub and their corresponding fields. API reference: SprintHub API documentation.
Every contact in the instance, with the fields the listing endpoint exposes (POST /leadsadvanced). This is the base table the per-contact streams below fan out from.Lead scoring, owner, stage, picture, language and the created/updated timestamps are not here: SprintHub’s listing endpoint does not return them. They are in Lead Details.Primary key: id
One row per contact with every field the instance stores, including its custom fields (GET /leads/{id}?allFields=1). Reading it costs one API call per contact.Tags are not here. The API mode that returns all fields does not return tags, and the mode that returns tags cannot be combined with it. The lead-to-tag association is its own stream, Lead Tags.Primary key: id
Custom object records attached to each contact (GET /lead/customobjects/{id}): support tickets, contracts, or whatever object types your instance defines. Reading it costs one API call per contact, whether or not your instance uses custom objects.Primary key: lead_id, id
SAC 360 conversations, one row per conversation across every channel (GET /sac360/lead/{id}). Reading it costs one API call per contact.Primary key: id
Messages that carried a file, across all of a contact’s SAC 360 conversations (GET /sac360/list_file_lead/{id}). Despite the endpoint’s name a row is a message, and the files it carried are inside it, under attachments in the document column. Reading it costs one API call per contact.Primary key: lead_id, id
The CRM funnels defined in the instance (GET /crm).Primary key: id
The Kanban columns of every funnel, with the card total each one reports. Join id against an opportunity’s crm_column to get the stage a card sits in.Primary key: id
CRM opportunities (POST /crm/opportunities/{funnelId}). The connector reads the whole board and then continues through the stages that hold more cards than the board returned, so every stage is read to the total it reports.Primary key: id
The instance’s tag vocabulary (GET /tags).Primary key: id
One row per lead-tag pair: which tags are applied to which lead.This is the association table between leads and tags, and the only place it exists: the lead payload does not carry its tags in any of the API’s modes. A lead with three tags produces three rows; a lead with none produces none. Reading it costs one API call per contact.tag and color are denormalised onto each row as the API returns them, so the table is readable on its own; join tag_id against tags when the tag’s current definition is what matters.Primary key: lead_id, tag_id
The custom object types the instance declares and the fields each one has (GET /customobjects/def).Primary key: id
Scheduling calendars and their public booking links (GET /pcalendar).Primary key: id
Meetings booked on each calendar (GET /calendarmeeting/{calendarId}), from the initial sync date onwards.Primary key: calendar_id, id
The custom reports defined in the instance (GET /advancedreports).Primary key: id
The computed result of each custom report (GET /reportchart/{id}). A report with no computed result yields no row. SprintHub does not recalculate these on every call and advises reading each one at most three times a day.Primary key: report_id

​
Data Model

The diagram below illustrates the relationships between the core data streams extracted from SprintHub.

​
Troubleshooting

​
Implementation Notes

What a full run costs. Measured on an instance with 4,577 contacts, 2,197 opportunities and 7 funnels: about 18,000 rows in three and a half hours with all fifteen tables selected, or about two minutes with the five per-contact tables left out. The difference is entirely the one-call-per-contact tables. Everything is full table. SprintHub exposes no date filter on contacts, opportunities, conversations or any other collection; the meetings endpoint is the only exception. Every table is re-read in full on each run, so the trigger frequency is what controls the API cost. Opportunities are read from the board, then stage by stage. SprintHub’s Kanban endpoint returns the whole board at once with the first batch of cards for every stage, and then requires querying each stage individually for the remaining cards. The connector follows this exact pattern. Because cards can move between stages while the funnel is being read, the offset-based paging might occasionally cause a small drift in card counts. Additionally, because the board request carries every column at once, the connector automatically caps the page size at 100 for this stream to prevent API errors. Rate limits depend on your plan. SprintHub does not publish a numeric limit; your allowance is shown in Configurações > Sistemas > Limites. The connector paces itself with the Requests per minute setting and, if SprintHub throttles a run anyway, waits and retries instead of failing: you’ll see a warning in the run log naming your allowance, the connector slows down to it for the rest of the run, and the extraction simply takes longer. Nested values arrive as JSON. Fields that hold an object or a list of objects (custom fields, UTM tags, attached files, permission lists) are extracted as JSON strings rather than nested columns. A few endpoints do not have their response documented by SprintHub at all; those tables carry a document column with the whole record as JSON, next to the identifiers needed to join it.