# Connect external services

Use workflow connectors and incoming events to connect Rumata with other tools.

Source: https://docs.rumata.dev/guides/connectors
Reviewed: 2026-09-06

## Before you start

- A workflow and access to the external service you intend to connect.
- An appropriately scoped credential, where the service requires one.

<a id="direction"></a>

## First choose the direction

| Need | Choose |
| --- | --- |
| Another service should start my workflow | An incoming event/webhook trigger. |
| My workflow should call another service | A connector or [HTTP Request](https://docs.rumata.dev/guides/controls-workflow-nodes#http) step. |
| Several workflows need the same custom operation | A reusable activity. |

An outgoing [Slack](https://docs.rumata.dev/guides/controls-connectors#slack) step and an incoming [Slack](https://docs.rumata.dev/guides/controls-workflow-palette#webhooks) event trigger solve different problems. Choose the direction first, then configure the service and operation.

<a id="catalog"></a>

## Explore the available catalog

The live [Add step](https://docs.rumata.dev/guides/controls-workflow-palette#catalog) palette includes incoming templates for [Webhook](https://docs.rumata.dev/guides/controls-workflow-palette#webhooks), [Slack](https://docs.rumata.dev/guides/controls-workflow-palette#webhooks), [GitHub](https://docs.rumata.dev/guides/controls-workflow-palette#webhooks), [Telegram](https://docs.rumata.dev/guides/controls-workflow-palette#webhooks), [Stripe](https://docs.rumata.dev/guides/controls-workflow-palette#webhooks), [GitLab](https://docs.rumata.dev/guides/controls-workflow-palette#webhooks), and [Shopify](https://docs.rumata.dev/guides/controls-workflow-palette#webhooks). Its connector section includes services such as [Slack](https://docs.rumata.dev/guides/controls-connectors#slack), [GitHub](https://docs.rumata.dev/guides/controls-connectors#github), [Notion](https://docs.rumata.dev/guides/controls-connectors#notion), [SendGrid](https://docs.rumata.dev/guides/controls-connectors#sendgrid), [Airtable](https://docs.rumata.dev/guides/controls-connectors#airtable), [HubSpot](https://docs.rumata.dev/guides/controls-connectors#hubspot), [Google Sheets](https://docs.rumata.dev/guides/controls-connectors#googlesheets), and [Supabase](https://docs.rumata.dev/guides/controls-connectors#supabase), alongside direct model APIs.

Choose a connector, then review its operation and credential fields in the inspector. A service listed in the catalog still needs to be connected and authorized for your account.

![Rumata Add a step palette beside an existing workflow, listing triggers and service connectors.](https://docs.rumata.dev/media/workflow-palette.jpg)

[Add a step](https://docs.rumata.dev/guides/controls-workflow-palette#catalog) groups triggers, connectors, activities, and control nodes. This reference capture uses a separate example factory. Select a step to review its configuration before adding it.

<a id="outgoing"></a>

## Set up an outgoing step

1. Open [Add step](https://docs.rumata.dev/guides/controls-workflow-palette#catalog) and choose the connector that matches the operation.
2. Inspect its required fields, endpoint parameters, and authentication mode.
3. Store the credential in [Secrets](https://docs.rumata.dev/guides/controls-secrets#browse) and select it using the supported configuration.
4. Choose a harmless test destination, such as a test channel or sample record.
5. Review the graph, publish it with [Save](https://docs.rumata.dev/guides/controls-workflows#toolbar), then run a controlled example.
6. Inspect the external service as well as the workflow result to verify the intended effect.

> **Connection is not blanket permission**
> A working token can have more access than your workflow needs. Use the narrowest service-side permissions and Rumata access that support the operation.

<a id="incoming"></a>

## Set up an incoming event

Configure the trigger’s required service settings, copy the actual published endpoint, and register it through the provider’s normal integration process. Where the provider signs events, configure and verify that signature. Do not assume that a public HTTP address authenticates the sender.

Use the provider’s test delivery and inspect one resulting workflow run. Review duplicate deliveries and retries before using the event to create records or send messages.

<a id="debug"></a>

## When the connector fails

- 401 or 403: check credentials, provider scopes, and Rumata permissions.
- 404: check the actual endpoint and resource identifier, including workspace or repository scope.
- 429: inspect provider rate limits and design bounded retry/backoff.
- Unexpected output: inspect the response shape and update the mapping with a safe example.
- Timeout: check whether the provider already performed the operation before retrying.

## Related guides

- [Connector operations and every input field](https://docs.rumata.dev/guides/controls-connectors)
- [Workflows](https://docs.rumata.dev/guides/system-explorer-workflows)
- [Keys & secrets](https://docs.rumata.dev/guides/system-explorer-secrets)
- [Workflows](https://docs.rumata.dev/guides/system-explorer-workflows)
- [Activities](https://docs.rumata.dev/guides/system-explorer-activities)