Complete products on shared integration infrastructure.

Add provider authorization to your product.

OAuth Apps allow developers to create authorization experiences for their applications using Cliodot connectors.

An OAuth App can bring several supported providers into one controlled application.

For example:

For example:

Google GitHub LinkedIn Microsoft HubSpot Slack Custom OAuth providers

Cliodot can handle the provider authorization process, callback flow and token exchange while your application maintains control over the user experience.

Configure the application

Define the application identity, supported providers, callback destinations and authorization behaviour.

Select provider capabilities

Attach connectors that support OAuth and choose the scopes required by each provider.

Control credentials

Use credentials managed by Cliodot, credentials supplied by customers or an appropriate hybrid model.

Receive the authorization result

Your application receives the authorization result through a secure callback and continues its own product flow.

OAuth App example
const authorizationUrl = cliodot.oauth.authorize({
  app: "customer-portal",
  provider: "github",
  redirectUri: "https://app.example.com/oauth/callback",
  state: sessionState,
});

Your application initiates the experience.

Cliodot coordinates the provider flow.

The provider remains the authority that grants access.

Receive, understand and route webhook traffic.

Webhook Apps give teams a dedicated environment for handling incoming events from external systems.

Each Webhook App can provide:

Each Webhook App can provide:

A managed receiving URL Live request inspection Headers Query parameters Request body Content type Source information Signature validation Event history Retry visibility Destination routing Workflow forwarding Custom response behaviour

Instead of treating webhook endpoints as disposable application routes, teams can operate them as managed infrastructure.

Inspect every event

A Webhook App can show:

A Webhook App can show:

Request method Source IP Headers Query values Body Timestamp Signature status Processing result Forwarding destination Response

Developers can understand what arrived before creating the final processing logic.

Route events where they belong

An incoming webhook can be:

An incoming webhook can be:

Sent to a workflow Forwarded to an internal endpoint Routed to a gateway Passed into a Surface capability Stored for later processing Transformed before delivery Replayed after a failure

Webhook Apps separate event ingestion from downstream business logic.

Use capabilities securely across organizations.

Remote allows one Cliodot organization to expose selected capabilities for another organization to request and use.

The publisher remains in control.

A request may include:

A request may include:

The requested connector Requested actions Intended use Required environment Expected usage Requested duration

The publisher can:

The publisher can:

Review the request Approve or decline it Remove requested actions Add restrictions Set an expiration Configure quotas Apply rate limits Revoke access Approved capabilities remain governed

Once approved, the requesting organization can use the capability inside:

Once approved, the requesting organization can use the capability inside:

Workflows Gateways Surface Other supported Cliodot applications

The original permissions and usage policies remain attached to the remote capability.

Remote does not transfer ownership of the connector or credentials.

It provides controlled execution access.