跳到主要内容

Zoho Social

Release status

Zoho Social uses the Daspire Runtime v0 connector as the production default. It keeps the existing Daspire source definition ID so saved sources remain recognizable, while execution uses an independently packaged connector image.

The Runtime v0 implementation is independently packaged and uses the Daspire Connector SDK plus the Python standard library. It does not import the inherited connector runtime or use its base image, test kit, or package dependencies.

If Zoho has not enabled API access for the organization, the connection check tells the customer to request access from Zoho Support. If an older credential lacks the current read scopes, the check tells the customer to reconnect Zoho Social and approve the required permissions. Neither case is a Daspire deployment failure.

Prerequisites

  • A Zoho Social organization for which Zoho has enabled API access. Zoho limits the API to allowed organizations; contact [email protected] with the organization and use case if access has not been enabled.
  • Administrator access to the required Portal, Brands, and Channels.
  • A new Daspire OAuth authorization using these official read scopes:
    • ZohoSocial.Organization.READ
    • ZohoSocial.Integration.READ
    • ZohoSocial.Publish.READ
  • One Portal and at least one Brand selected from the OAuth-backed pickers.
  • Optional Channels when the source should be limited to specific connected channels.

Official provider references:

Configuration

FieldRequiredNotes
credential_handleYesReturned by the Daspire source OAuth callback. Provider secrets are not returned to the browser.
portal_idYesSelect from the OAuth-backed Portal picker.
brand_idsYesSelect one or more Brands under the selected Portal. Daspire stores the provider IDs automatically.
channel_idsNoLeave empty for every accessible channel under the selected Brands, or select specific Channels. Daspire stores the provider IDs automatically.
page_sizeNoPublished-post page size from 1 to 100; default 50.
start_dateCompatibility onlyRetained so saved source forms can be read. The official published-post endpoint does not expose a date filter.
end_dateCompatibility onlyRetained so saved source forms can be read. The official published-post endpoint does not expose a date filter.

The entity picker calls the official /socialportals, /socialbrands, and /channels endpoints. Portal and Brand identifiers are sent in the provider-required request headers. Returned options are limited to safe IDs, names, and bounded metadata; OAuth tokens and internal runtime fields are not exposed.

Daspire determines the Zoho data center from the location and accounts-server values returned by Zoho during OAuth. Customers do not select a data-center region.

Example source configuration:

{
"connector_id": "conn_496e0e5c6669ebe828660f97",
"name": "Zoho Social - Brand A",
"connectionConfiguration": {
"credential_handle": "cred_source_oauth_zoho_social",
"portal_id": "123456789",
"brand_ids": ["987654321"],
"channel_ids": ["456789123"]
}
}

Supported streams

  • portals
  • brands
  • channels
  • posts

posts reads the official published-post endpoint by Brand and network. Provider engagement fields such as likes, comments, shares, reactions, and impressions are retained when Zoho returns them.

The new API does not expose the previous standalone post_metrics or account_metrics report endpoints. A selected catalog containing either old stream fails before reading instead of silently omitting data. Metric fields embedded in published post records remain available in posts.

Portals, Brands, and Channels are full-refresh streams. Published posts use the provider cursor plus a per-scope checkpoint.

Each selected Brand and social network is an independent commit boundary. When Zoho marks one selected channel as token_reconnect, Daspire records that scope as failed, commits data from the other completed scopes, and shows the job as partially successful. The failed scope emits no records and does not receive a successful checkpoint. Daspire never silently drops the channel: reconnect it inside Zoho Social, then retry the failed scope or allow the next scheduled run to read it again. A failure after any record has been emitted for a scope remains a whole-job failure so an incomplete channel cannot be committed.

Troubleshooting and rollback

  • api_access_not_enabled: ask Zoho Support to enable the Zoho Social API for the customer's organization, then retry the connection check.
  • authentication_failed: reconnect Zoho Social in Daspire and approve the Organization, Integration, and Publish read permissions.
  • channel_reconnect_required: reconnect the named social account inside Zoho Social. Other healthy selected channels continue under a visible partial-success result; if every selected channel needs reconnection, the job still fails.
  • For the specific provider reason USER_INACTIVE_IN_PORTAL, the first published-post GET may be rechecked once after two seconds using the same token and page. A persistent rejection stops the read and requires checking the user's Zoho portal membership; it is not automatically treated as revoked OAuth. Other permission errors and OAuth POST behavior are unchanged.
  • unsupported_stream: refresh the source schema and remove the retired post_metrics and account_metrics streams from the selected catalog.
  • Interrupted GET bodies and malformed page JSON use the existing bounded retry budget before that page is emitted. OAuth refresh POST retries are unchanged. In Native execution, a checkpoint is accepted only after the destination commit; failed staging is not proof that data was written.

An emergency rollback restores the prior source definition image tag. The source definition ID, customer source IDs, credentials, schedules, destinations, billing, and warehouse names do not change.

Limitations

  • API availability is controlled by Zoho per organization.
  • The official published-post endpoint requires one social network per request and does not provide a date-range filter.
  • Data and metrics vary by connected social network and the permissions granted to Zoho Social.
  • Existing credentials must be reauthorized because the official scope names differ from the previous consent flow.