Skip to main content
GoTo Connect is a cloud-based phone system and unified communications platform for business telephony. This connector extracts call history and call analytics, the organization’s phone-system configuration, and voicemail, fax, and messaging data through the GoTo Connect APIs, landing it all in your Catalog.

Configuring GoTo Connect as a Source

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

1. Add account access

GoTo Connect uses managed OAuth2, so you do not need to create an app in GoTo or copy any credentials. Click the Authorization button and sign in with your GoTo account, then approve the permissions Nekt requests. Nekt requests read-only scopes, so the connector can only read your data — it cannot place calls, send messages, or change any setting in GoTo Connect.
The GoTo user you authorize with must hold Super Admin or View Reports permission in the organization. Without it, GoTo returns no call reports and the corresponding streams stay empty. See how to grant Super Admin permissions.
The permissions Nekt requests, and what each one unlocks: The following configurations are available:
  • Start date: The earliest date from which records will be synced.
Optionally, under advanced settings you can define:
  • Account Key: The GoTo Connect account (organization) key to extract. Leave this empty and the connector resolves it automatically, using the first account the authorized user belongs to.
  • Organization ID: Only needed when the authorized user belongs to more than one organization. Without it, GoTo rejects the call report requests.
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: you can choose between INCREMENTAL and FULL_TABLE.
    • Incremental: every time the extraction happens, we’ll get only the new data - which is good if, for example, you want to keep every record ever fetched.
    • Full table: every time the extraction happens, we’ll get the current state of the data - which is good if, for example, you don’t want to have deleted data in your catalog.
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.

How authentication works

You only ever click Authorization and sign in. Everything below happens on Nekt’s side, and is documented here so you know what to expect when something needs your attention.

The authorization

Nekt operates a single registered GoTo application, shared by all Nekt customers. When you click Authorization, GoTo asks you to sign in and approve the read-only permissions listed above. Approving them issues Nekt a credential scoped to your organization — it grants no access to anyone else’s data, and Nekt never sees your GoTo password. The connection represents the user who authorized it. Everything the connector can read is exactly what that user can read in GoTo Connect, which is why the Super Admin or View Reports permission matters.

Staying connected

GoTo issues short-lived access tokens that expire after one hour. The connector renews them automatically during a run, so a long extraction never fails halfway through for an expired token. Renewal relies on a longer-lived credential that is valid for 30 days. GoTo replaces it periodically — but only once 60% of its lifetime has passed, so most renewals return nothing new and the connector keeps the credential it already has. Whenever GoTo does issue a replacement, the connector stores it immediately and uses it from then on.
The renewal credential expires after 30 days without use. If a source is paused, disabled, or fails continuously for longer than that, the connection lapses and you have to click Authorization again to reconnect. Keeping the source on any regular schedule is enough to prevent this.
If the credential is ever rejected, the run fails with a message telling you to reconnect the source. Re-authorizing restores it; no data is lost, and the next run resumes from where the last successful one stopped.

Revoking access

Removing the source in Nekt stops all extraction. To revoke Nekt’s access from the GoTo side, remove the authorization for the Nekt application in your GoTo account settings.

API Behaviors and Limitations

Call reports are aggregated per day

The user_activity_reports, caller_activity_reports, and phone_number_activity_reports streams are aggregates, not individual events. GoTo returns them as totals over a time window, with no timestamp on each row, so the connector requests one day at a time. Every row therefore represents one full day of activity for one user, caller, or phone number, identified by the report_date column. Because a day is only requested once it is complete, activity for the current day appears in your Catalog on the following run after midnight UTC.
GoTo retains call report data for 13 months. Setting a start date earlier than that returns no data for the missing period, and the connector automatically starts from the oldest date still available.

Two views of the same calls

Two streams describe calls, at different grains:
  • call_history has one record per call leg. A single call involving a transfer produces several rows, tied together by originator_id.
  • call_events_report_summaries has one record per conversation, with every participant, the outcome, and the identifiers of any recordings and transcripts.
Use call_history for raw telephony detail and call_events_report_summaries for call-level analysis. The AI analysis fields in the latter (sentiment, topics, summary) are only populated on accounts licensed for Advanced reporting; on other accounts the field is empty.

Unanswered calls

call_history has no dedicated flag for a missed call. A call was not answered when answer_time is empty, which is how GoTo itself documents the distinction.

Messaging requires per-number access

conversations and messages are scoped to individual phone numbers rather than to the organization. The connector walks the numbers it can see and reads the conversations on each. A user without Super Admin privileges only sees their own numbers, so these streams cover the whole organization only when the authorized user is a Super Admin.

Rate limits

GoTo allows 10 requests per second per API. The connector spaces its requests to stay below that and, if GoTo asks it to slow down anyway, waits and retries automatically. This can make a run take longer but never loses data. Using the GoTo APIs carries no additional charge beyond your GoTo Connect subscription.

Streams your plan or permissions do not cover

Fax, messaging, and voicemail depend on features that not every GoTo Connect plan includes, and on permissions the authorized user may not hold. When GoTo denies access to one of them, the connector skips that stream with a warning and continues, rather than failing the whole run. The stream’s table simply is not updated.
Fields holding nested structures (such as lines, caller, callee, participants, ai_analysis, address, route_to, media, and delivery_statuses) are delivered as JSON-encoded strings rather than native nested objects. To work with their contents, parse the string downstream (for example with JSON_PARSE/JSON_EXTRACT on AWS or JSON_VALUE/JSON_QUERY on GCP).

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 GoTo Connect and their corresponding fields.
Users of the account and the lines assigned to each of them.Primary key: user_key
Sync: Full table
Extensions configured on the account.Primary key: id
Sync: Full table
Desk phones and softphones registered on the account.Primary key: id
Sync: Full table
Phone numbers (DIDs) owned by the organization.Primary key: id
Sync: Full table
Call queues configured on the account.Primary key: id
Sync: Full table
Physical locations registered for the account.Primary key: id
Sync: Full table
Billing groups that phone numbers are charged against.Primary key: id
Sync: Full table
Orders placed for new phone numbers.Primary key: id
Sync: Incremental on order_date
Individual call legs handled by the platform.Primary key: leg_id
Sync: Incremental on start_time
Completed call summaries, one record per conversation.Primary key: conversation_space_id
Sync: Incremental on call_created
Daily call activity aggregated per user.Primary key: report_date, user_id
Sync: Incremental on report_date
Daily call activity aggregated per external caller number.Primary key: report_date, number
Sync: Incremental on report_date
Daily call activity aggregated per organization phone number.Primary key: report_date, phone_number_id
Sync: Incremental on report_date
Voicemail boxes the authorized user has access to.Primary key: voicemailbox_id
Sync: Full table
Voicemails left in each voicemail box.Primary key: voicemail_id
Sync: Incremental on timestamp
Incoming and outgoing faxes stored on the account.Primary key: fax_id
Sync: Full table
SMS and MMS conversations held on the organization’s phone numbers.Primary key: owner_phone_number, contact_phone_numbers
Sync: Incremental on last_message_timestamp
Individual SMS and MMS messages exchanged in each conversation.Primary key: id
Sync: Incremental on timestamp