A Provider is a specific third-party platform that your customers use, such as Jira, ServiceNow, Okta, Slack, or AWS.
While Connectors represent a business capability such as ticketing, identity, or messaging, Providers are the individual products that implement those capabilities. Each Provider exposes its own APIs, authentication requirements, data models, and operational behavior.
Providers are the systems where work ultimately happens. A ticket is created in Jira or ServiceNow. A user is managed in Okta. A message is sent through Slack.
Although Providers within the same category often offer similar functionality, they differ significantly in how that functionality is exposed:
| What varies | Examples |
|---|---|
| Authentication | OAuth 2.0, API keys, service accounts, SAML |
| API structure | REST, GraphQL, SOAP, or proprietary conventions |
| Rate limits | Throttling policies differ widely across providers |
| Pagination | Cursor-based, offset-based, or token-based |
| Resource schemas | Field names, types, and relationships vary per provider |
Without an abstraction layer, applications would need to understand and accommodate these differences for every supported Provider. Synqly handles this so your application never has to.
The relationship between Connectors and Providers is central to the Synqly model.
A Connector defines a common interface for a category of functionality, while Providers are the underlying implementations of that functionality.
Your application interacts with the Connector, not directly with individual Providers. Synqly translates requests between the Connector's unified model and each Provider's native implementation, insulating your application from provider-specific APIs and changes over time.
When integrating with Synqly, your application integrates with a Connector rather than individual Providers. This allows much of the same integration logic to be reused across Providers within the same Connector category, reducing the amount of provider-specific code you need to maintain.