Connect a third-party service to ModuleX with OAuth or your own key, then call its tool from a workflow. A step-by-step guide for connecting GitHub, Slack, and 175 other integrations.
ModuleX connects to 175 services — GitHub, Slack, Gmail, Notion, Salesforce, and many more — so your workflows can act on them: open an issue, send a message, read a row, create a contact. This guide walks you through it end to end: connect a service once, then call one of its actions from a tool node in a workflow.You connect a service once, for your whole organization. After that, every workflow and the Assistant can use it. For the bigger picture of what integrations are, start with the integrations overview.
Integrations are connected per organization, not per person. Make sure you are working in the right one — the organization switcher is in the app header.
The owner or admin role
Only an owner or an admin can connect and manage credentials for an organization. If you do not see the connect controls, ask an owner or admin to connect the service. See roles & permissions.
An account on the service
For most services you sign in with your existing account during the connect step. Some services need an API key instead — you can paste one in.
You do not have to connect everything yourself. ModuleX offers managed keys for many services — see Three ways to connect below — so you can try a tool before bringing your own account.
Connecting a service stores a credential: an encrypted record that links your organization to that service. You create it once; ModuleX encrypts it, and uses it automatically every time a workflow or the Assistant calls one of that service’s tools. You never paste a secret into a workflow.Behind the scenes there are a few canonical terms worth knowing.
Integration vs. tool
An integration is the connection to one service, for example GitHub. Each integration exposes many tools — the individual actions you can call, such as github.create_issue or github.list_repositories. ModuleX has 175 integrations and 600+ tools in total. Browse them in the catalog.
Credential
A credential is the encrypted, organization-scoped record that proves your identity to a service. One integration can hold more than one credential — for example a production GitHub and a test GitHub — and you mark one as the default.
Default credential
When a tool runs and you have not picked a specific credential, ModuleX uses the one you marked as default for that integration. Set or change the default any time from managing credentials.
A service tells ModuleX which methods it supports. Most integrations offer one or more of these three. The connect screen shows you only the options that apply.
OAuth (recommended)
Sign in to the service and grant access — no copying secrets. This is the smoothest path and is covered step by step below. The technical details live in integration authentication.
Your own key (BYOK)
Paste an API key or token you already have from the service. Usage is billed directly by the provider, with no ModuleX markup.
ModuleX-managed key
For supported services, use a key ModuleX provides — nothing to set up. Managed usage is metered in credits.
OAuth lets you connect by signing in to the service, instead of handling secrets yourself. The example below uses GitHub; the steps are the same for any service that offers OAuth.
1
Open the integrations catalog
In the app, go to your organization settings and open Browse integrations. Find the service — search by name or filter by category — and open it. See the integrations overview for a tour of the catalog.
2
Start the connection
Choose Add credential, then pick OAuth as the method. Give the credential a clear name — for example Production GitHub — so you can tell it apart later if you connect more than one account. Turning on Make default lets workflows use it automatically.
3
Sign in and grant access
ModuleX sends you to the service’s own sign-in and consent screen. Review the access it asks for, then approve. This grant uses OAuth2 with PKCE, an industry-standard secure flow — you stay on the service’s site to sign in, and ModuleX never sees your password.
4
Return to ModuleX
After you approve, the service sends you back to ModuleX and the credential is saved automatically. You will see a success message, and the integration now shows as connected. That is it — the service is ready to use across your workflows and the Assistant.
The integration appears under your connected credentials with a name, the OAuth method, and a default badge if you set one. You are ready to use the tool in a workflow.
If a service does not offer OAuth, or you would rather bring your own account, choose API key (or bearer token) on the same connect screen and paste the value from the service. ModuleX checks the key before saving so you catch a typo early. The secret is encrypted at rest and never shown again in full — only a masked preview.For the full list of methods a service can offer and how each is stored and resolved, see integration authentication.
With the service connected, you can call its actions from a workflow. The unit that does this is the tool node — it runs one action, with parameters you control, and writes the result into your run so later steps can use it.
1
Add a tool node
Open a workflow in the workflow builder and add a tool node to the canvas.
2
Pick the integration and action
In the node’s detail panel, pick the connected integration (for example GitHub) and then the action you want (for example create_issue). ModuleX shows the credential it will use — the default for that integration unless you choose another.
3
Fill in the parameters
Enter the action’s inputs — for create_issue, that is the repository, the title, and the body. You can type fixed values, or pull a value from an earlier step using a {{node_id.field}} reference. See variables & references for the reference syntax.
4
Run and check the result
Run the workflow. The tool node calls the service, and the action’s result is written into run state under the node’s own id, ready for the next step. For how runs stream and how failures surface, see running workflows.
Want a step where the AI decides which tools to call, rather than a fixed action? Use the agent node, or let the Assistant use your connected tools directly in chat — no workflow required.
You can also create a credential through the API. Authenticate every request with your API key as Authorization: Bearer mx_live_… plus the X-Organization-ID header for your organization. The example below creates an API-key credential for a service; the response masks the secret.
OAuth connections involve a browser sign-in step, so they are made in the app, not from a single API call. Use the app’s connect flow for OAuth, and the API for key-based credentials.
Creating and managing credentials requires the owner or admin role. A request from a non-admin member is rejected. ModuleX never reads the organization from the request body — it always comes from the X-Organization-ID header.
For the full credential API — listing, setting a default, testing, and deleting — see managing credentials.
A connection lasts until the service’s access expires or is revoked. For OAuth connections, ModuleX refreshes access automatically in the background as tokens near expiry, so most connections keep working without any action from you.
If an OAuth connection stops working — for example because access was revoked on the service — reconnect it rather than looking for a manual “refresh” button. Connect the service again with OAuth, and set the new credential as the default. A manual one-click OAuth refresh in the app is a known limitation and should not be relied on.
To rotate a key-based credential, connect the service again with the new key, mark it as the default, and delete the old one. See managing credentials.
How a connected service is billed depends on which method you used to connect it.
Your own key (BYOK)
Usage is billed directly by the service provider, with no ModuleX markup. It is not metered in ModuleX credits.
ModuleX-managed key
Tool calls made through a ModuleX-managed key are metered in credits. When your plan’s allowance runs out, calls are subject to the usage gate — see usage gating & limits.
I do not see the connect or Add credential controls
Connecting integrations requires the owner or admin role for the organization. Switch to the correct organization in the header, or ask an owner or admin to connect the service. See roles & permissions.
The OAuth window returned an error
Start the connection again from the catalog. The sign-in step is time-limited, so if you waited too long on the consent screen, the attempt expires and you simply retry. If the service reports that access was denied, approve the requested permissions when prompted.
My API key was rejected
Double-check you copied the full key from the service, with no extra spaces, and that it has the permissions the action needs. ModuleX tests a key before saving, so a rejection here means the service did not accept it.
The tool node does not list my integration
Confirm the credential was saved in the same organization you are building the workflow in, and that the integration shows as connected. If you connected more than one account, check which credential is set as the default.