Overview
The Constant Contact connector provides read-only access to Constant Contact v3 data, including:
Contacts, lists, tags, and custom fields
Email campaigns and campaign activity
Email sends, opens, clicks, opt-outs, and other engagement reporting
Segments and campaign summary/statistics data
Activity records
The connector does not create, update, or delete Constant Contact records. Each table has predefined unique key fields appropriate to that dataset.
Authentication
The connector uses Constant Contact OAuth and requires:
client_id client_secret access_token refresh_token
The access token is used for API requests against:
https://api.cc.email
The connector automatically refreshes the access token when it detects that the token is expired or when Constant Contact returns HTTP 401. Updated access and refresh tokens are retained for subsequent requests.
According to the operational settings captured in the connector:
Access token lifetime: 1 day Refresh token lifetime: 180 days
If the refresh token itself expires, the Constant Contact connection must be reauthorized.
API Requests
Most data retrieval is performed with GET requests.
There are two important exceptions related to authentication and contact exports:
Operation | Method | Purpose |
Normal data/report retrieval | GET | Retrieves contacts-related metadata, campaigns, reporting, segments, etc. |
| POST | Starts a bulk contact export |
Contact export status/result URLs | GET | Polls the export and downloads the resulting CSV |
OAuth token endpoint | POST | Exchanges an authorization code for access/refresh tokens |
The OAuth token endpoint is:
https://authz.constantcontact.com/oauth2/default/v1/token
There are no PUT, PATCH, or DELETE operations used to modify Constant Contact business data.
Sync Behavior
The connector does not maintain incremental bookmarks. Selected tables are re-read from Constant Contact on each sync.
For normal endpoints, the connector follows Constant Contact pagination until no more records are returned.
Contacts use a bulk export
contacts is handled differently from the other tables.
Instead of paging through the contacts API, the connector:
Starts a contact export using:
POST /v3/activities/contact_exports
Polls the export status every 5 seconds.
Waits until the export reaches
completed.Downloads the exported CSV.
Loads the CSV records into the contacts dataset.
The export can wait for up to:
24 hours
before the connector considers it timed out.
Bulk export is used because a large contact database could otherwise consume a significant portion of Constant Contact's daily API request quota.
Email Reporting Behavior
Email reporting is more API-intensive than most Constant Contact datasets.
Reports such as:
email_links email_sends email_opens email_unique_opens email_did_not_opens email_clicks email_optouts email_campaign_activity_stats
require a campaign_activity_id.
To determine those IDs, the connector first:
GET /emails
and then, for every campaign:
GET /emails/{campaign_id}It extracts the campaign_activity_id values from each campaign's activities and then uses those IDs to retrieve the corresponding reporting data.
This means an email-reporting sync may require substantially more API calls than the number of final records suggests.
For email_campaign_activity_stats, activity IDs are grouped into batches of up to 10 IDs per request.
Schema Behavior
Schemas are predefined by the connector.
For normal API datasets:
Only fields defined in the connector schema are included.
Additional fields returned by Constant Contact are ignored.
If a configured field is missing from an API response, it is written as
NULL.
This means new fields introduced by Constant Contact will not automatically become new columns until the connector schema is updated.
Contacts are sourced through the CSV export. CSV headers are normalized to lowercase snake case before records are loaded.
Deletes
The connector does not explicitly synchronize deletions.
Some Constant Contact responses contain fields such as:
deleted_at
which can indicate deletion-related state for particular objects or email-reporting records. However, the connector does not:
Consume a general deleted-record feed
Compare current and previous snapshots
Generate explicit downstream delete events
Consumers should therefore not assume that a source record disappearing from Constant Contact will automatically cause the existing downstream record to be removed.
Rate Limits & Retries
The connector documents Constant Contact v3 limits as:
10,000 API requests per day per API key 4 API requests per second
The daily quota resets at 00:00 UTC. Exceeding a limit can return HTTP 429.
Failed requests are retried up to 5 times, using exponential backoff:
1 second 2 seconds 4 seconds 8 seconds 16 seconds
with a maximum individual delay of 30 seconds. A 401 triggers an access-token refresh before retrying.
Known Limitations & Notable Behavior
Syncs are not incremental. The connector does not store a last-modified bookmark, so selected datasets are re-read each time.
Large contact databases use asynchronous bulk export. This reduces API request usage but means contact syncs may take longer while Constant Contact prepares the export.
Email reporting can consume many API requests. Campaign activity IDs must first be discovered by paging through campaigns and retrieving each campaign individually before many reporting endpoints can be queried.
The 10,000-request daily quota can affect large reporting syncs. This is particularly relevant for accounts with many campaigns and campaign activities.
Deletes are not explicitly propagated. A record disappearing upstream does not automatically generate a deletion downstream.
Schemas are fixed. New Constant Contact fields are dropped until explicitly added to the connector's schema.
OAuth authorization can eventually need user intervention. Access tokens are refreshed automatically, but once the refresh token is no longer valid, the connection must be authorized again.
Bulk contact exports can run for a long time. The connector allows an export to remain pending for up to 24 hours before treating it as failed.
Unexpected non-200 responses are retried rather than immediately failing. After the retry limit is reached, some normal paged operations return the last response to the calling logic, so unexpectedly low record counts should be investigated rather than automatically assumed to represent all available source data.