Rumatadocs
Browse documentation

Connect external services

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

Step-by-step guidance.

Before you start

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

First choose the direction

NeedChoose
Another service should start my workflowAn incoming event/webhook trigger.
My workflow should call another serviceA connector or HTTP Request step.
Several workflows need the same custom operationA reusable activity.

An outgoing Slack step and an incoming Slack event trigger solve different problems. Choose the direction first, then configure the service and operation.

Explore the available catalog

The live Add step palette includes incoming templates for Webhook, Slack, GitHub, Telegram, Stripe, GitLab, and Shopify. Its connector section includes services such as Slack, GitHub, Notion, SendGrid, Airtable, HubSpot, Google Sheets, and 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.

Add a step 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.

Set up an outgoing step

  1. Open Add step and choose the connector that matches the operation.
  2. Inspect its required fields, endpoint parameters, and authentication mode.
  3. Store the credential in Secrets 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, then run a controlled example.
  6. Inspect the external service as well as the workflow result to verify the intended effect.

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.

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.