Connections

A connection is a saved way to talk to an outside service. It has a name. The service can be an API, like your CRM. It can be an MCP tool server. It can be a place that gets your notifications. Your server talks out to it.

A pack asks to use a connection by its name. You set up the secret key once. Then any pack you grant it to reuses it. The key is never copied into a recipe.

#Enroll a connection

Enroll means "set up and save". Open Settings → Connections and pick a provider. Or let a pack do it. A pack that needs a connection walks you through the setup while it installs.

Each connection is known by its kind and its name. So acme-hubspot and personal-hubspot are two different connections. Each one has its own grants. A grant is a yes you give ahead of time.

#Sign in through Nango

A broker is another server that holds your vendor sign-in and makes API calls for you. Nango is one such broker. You can choose it under How to connect → Managed OAuth. It works with API packs. Mail, Calendar and file sync can also use these saved connections.

Open Connections → Apps & APIs → Manage OAuth brokers to set up a broker first. You can also add one while setting up a connection.

1. Give the broker a name.
2. Enter its Server URL. For Nango Cloud, use https://api.nango.dev. You can use your own Nango server too. It can run on another machine.
3. Paste its Nango API key. Get it from Environment Settings → API Keys in Nango. An environment is a separate place for test or live accounts. The key chooses that place. It does not mean a local machine.
4. If your own Nango server has a separate sign-in page, enter its Connect UI origin. This is the start of that page's address.
5. Click Test and save broker.

To change its key, choose Edit broker key. Use a key from the same Nango environment. With saved accounts, Recued checks that both keys reach the same accounts. Change the key before you revoke the old one. For a different environment, or an old key that no longer works, add a new broker profile and connect its accounts again.

#Choose a vendor app

Choose a vendor integration next. This is the app set up in Nango for that vendor. Recued picks it for a pack when exactly one app matches. With more than one, you choose.

If no app is set up, click Create vendor integration. Choose a Nango shared app, if your server offers one. Or enter your own vendor app's ID, secret and scopes. A scope is a named permission, such as reading mail. Recued sends those app credentials to Nango. It does not save them itself.

#Reuse or reauthorize an account

Recued checks for Nango accounts when you pick a vendor app. If it finds accounts, it starts with Use an existing Nango account. Pick one and click Use selected account. Then save and probe the connection. A probe checks whether Recued can reach it. It does not prove that every needed permission was granted.

If there are no accounts, Recued offers Authorize a new account. You can also choose this when you need another account. Each new sign-in creates another Nango connection. After consent, save and probe before starting again.

Reauthorize keeps the same Nango connection. If Recued has already requested all the needed scopes in completed sign-in flows, it reuses the account without new consent. Granted permissions stay unknown. Save and probe, then check the access needed by your task. No custom Nango function or extra setup is needed.

Choose Sign in again to repair access with new consent. This also keeps the same Nango connection. Recued checks the scope needs of all its saved connections that share that account.

#Keep scope history

Reused accounts can keep scope history from other saved Recued connections. If that history is unknown, manage consent in Nango with the same scope profile. This keeps Recued from dropping prior permissions.

If Nango hides app scopes, Recued may refuse to reauthorize a saved account. Use a key that can read those scopes, or manage its consent in Nango with the same scope profile. Finish or cancel a pending sign-in before starting another for that account.

Cancel stops the Recued sign-in flow. It does not revoke vendor consent. Scope unions cover requests saved in Recued. If you change consent in Nango or another tool, keep its full scope profile there.

Shared apps may have fixed permissions. Vendor rules and requests for an admin's consent still apply. When Nango does not report granted scopes, Recued shows them as unknown.

#Change the scopes you need

Recued saves your scope needs apart from past consent. Asking for the same or less access can reuse a healthy account when its completed scope history covers all current needs. This history records past requests, not granted permissions. A vendor can still refuse access. Use Sign in again to repair access when needed.

Asking for new scopes, or a mix of old and new, keeps the same Nango account. New consent requests the full tracked list, app defaults, and the scopes needed by other saved connections. A smaller request does not remove old vendor permissions. Other tools may still need them. Recued does not offer a scope downgrade.

Before new consent, Recued clears old grant proof for all connections sharing that account. Access stays in Nango. If sign-in fails or is canceled, those grants stay unknown. Recued will not claim the old scopes still apply.

If a saved connection's scope needs change during sign-in, start again. Shared apps with fixed scopes may need an app change first.

Recued keeps scope history from completed consent even if you close the form without saving. This needs Nango to report its internal account ID and creation date. It checks for completed consent when you cancel. A failed scope request is not kept for later sign-ins.

#Keep Nango connection use low

Many packs can share one saved API connection. You can also reuse the same Nango account in other Recued API connections. Mail, Calendar and file sync can use a saved API connection too. These choices need no extra Nango account.

The vendor app and its permissions must fit each task. The same email address in two Nango vendor apps still means two Nango connections. Removing a Recued connection does not free its Nango slot. Use Manage OAuth brokers to remove an unused Nango account.

#Use a saved connection for Mail or Calendar

First save a managed API connection for the service. Then open Connections → Mail or Calendar, add an account, and choose Google or Microsoft. Under How to connect, choose Managed OAuth — saved API connection. Pick your saved connection and give the account a name. When only one saved connection fits, Recued picks it for you. You do not need another app ID, app secret or sign-in.

The API base URL must match the service:

Mail sending, mail changes and Calendar writes start off. Turn on only the write options you need when you add the account. These switches let Recued try a write; they do not grant new vendor access. Add the needed scopes to the API connection and sign in again there first. The vendor still checks each call. If Nango gives no scope list, permissions stay unknown.

To change these write options later, remove and add the Mail or Calendar account again with the saved API connection. This does not delete the remote Nango account. Each account's menu also links back to Apps & APIs for reconnecting its source. Remove the Mail and Calendar accounts before removing the API connection they use.

#Use a saved connection for file sync

File sources and remote file reads can use a managed API connection for Google Drive, OneDrive, SharePoint, Box, Dropbox or Notion. Choose that saved connection in the usual source form. Recued uses the same file readers as with direct credentials. Your packs and recipes need no changes. S3 keeps its access key setup.

#Remove a Nango account

Removing a Recued connection keeps its Nango account. To delete that account too, use Manage OAuth brokers. Choose its integration and existing account. Remove its Recued connections first, then type the account ID to confirm. Every other tool using that Nango account loses access too. The vendor may keep its consent until you revoke it there.

#HubSpot: a key or your own app

HubSpot gives you two ways in. You pick one under How to connect.

A Service Key is the easy way, and it suits most people. You make a key in HubSpot and paste it into the form. It is under Development → Keys → Service keys. You need to be a Super Admin there, or have Developer tools access. There is no app to make and no sign-in. So it works from any address, 127.0.0.1 too. When you save, Recued tries the key. So a wrong key shows at once.

When you make the key, tick the scopes the form lists. They let packs read your records and change them, and every change still goes through Recued's approvals. For a key that only reads, skip the second group. When you save, Recued also reads which scopes the key has. If a pack needs one the key lacks, the pack's page names it under Connections. Add that scope to the key in HubSpot. Then click Probe on the connection, so Recued reads it again. HubSpot suggests a new key every six months. Paste it into the same connection.

Your own app is the hard way. HubSpot makes new apps only with its command-line tool. That needs sandbox access, which only paid HubSpot plans have. So on a free account, use a Service Key. With an app, you sign in through it.

#Apps sign in through a callback

Direct Salesforce OAuth takes your own app, a Connected App. It also has a sandbox switch.

An app sends each sign-in back to a callback address. Recued shows the right one on the form. It depends on where you open Recued:

• On app.recued.com, it is https://app.recued.com/oauth-callback. That page only hands the code on to your server.
• At your server's own HTTPS address, it is /oauth/complete there. The vendor sends the sign-in straight to your server. So under Settings → Server → Exposure, the /oauth/complete row must be Public.
• At localhost on the server, your server's own page takes it. The start-up log prints 127.0.0.1, but HubSpot will not take a callback at a number. So open http://localhost:7717/webclient to connect. Is that address new to your browser? Pair it once, like a new device. You connect once. After that, the connection works from any address.

The first two need an address the internet reaches your server at. A Pro address counts, and so does your own domain once Recued has checked it. Reachability shows how to get one.

For your own OAuth app, your server does the token swap and stores the tokens. A managed OAuth connection uses its chosen broker instead.

After you sign in, Recued checks what the provider really allowed. For a HubSpot app, it checks the granted scopes. For Salesforce, it probes which objects it can see. Is something missing? You see a warning on the capability that needs it. A capability is one thing a pack can do. Nothing is hidden.

#Where credentials live

A credential is a secret, like a key or a token. Direct credentials stay on your server. Only the connection executor uses it, and only at the moment of a call. A recipe can read the non-secret fields of a connection. The secret key never goes into recipe data or step outputs.

With managed OAuth, the broker keeps the vendor credentials and sees the API requests and replies. Its API key stays encrypted on your Recued server. You choose the broker; Recued Cloud does not hold those credentials or route those calls.

#What connections power

• CRM records in the warehouse. Your server checks them against the vendor and fixes differences. Webhooks or streaming make that faster.
• Outgoing notifications. For example, sending email to many people through one named target.
• MCP tool servers that your recipes can call.

#Sending mail

A mail account says whether it can send. A recipe checks that before it tries to send. The server checks again at the moment it sends. A guard also refuses mail sent from an address to that same address, so it cannot loop. Outgoing mail goes from your server straight to your mail provider. It never goes through Recued's cloud.

#Lifecycle

A recipe names no connection. Each pack keeps a list of connections, and its recipes use the one you chose, else the pack's default. Before you delete a connection, Recued says where each pack's runs go next. Grants attach to installed packs. So you can change what a pack may do without setting up the secret key again.

#Related

• Connect Gmail and Google Calendar. Which way keeps working for your kind of Google account.
• Connect Outlook and Microsoft 365. Who makes the sign-in app for your kind of Microsoft account.
• Grants and approvals. How your server checks each granted action when it runs.