Connecting External Services

If an AI employee needs to read your GitHub repos or write to a Notion page, it needs to log in to that service on your behalf. UpServe is designed so you only do this once. After that, any skill that uses the same service will reuse the connection details automatically: you don’t log in again, and they are forwarded to the skill at runtime.

These connections all live in one place: the Connections sub-tab under Skills (https://upserve.app/skills/integrations ). Web, iOS, and Android all use the same layout: services are grouped by category, and clicking a card lets you connect, disconnect, and manage an organization’s designated account all from one screen.

At a glance

Question	Answer
Which services can I connect?	Ten sign-in services (GitHub, Linear, Notion, Slack, Google Drive, Google Calendar, Google Tasks, Threads, Instagram, YouTube), plus a wider category-organized list including Asana, ClickUp, HubSpot, Stripe, Figma, Canva, and more (see “Connecting more services” below).
Can anyone connect Threads or Instagram?	Not yet. Both are still waiting on the external platform’s (Meta) review: each card shows a `Coming soon` badge and no `Connect` button, and only test accounts UpServe has registered can actually connect. Once review completes, the badge disappears automatically with no app update needed. Anyone who already connected keeps working as before.
A card shows a `Coming soon` badge, or its connect button isn’t showing up	There are two different cases. (1) A `Coming soon` badge on a card means that service hasn’t passed the external platform’s review yet (see Threads/Instagram above), and it unblocks automatically once review completes. (2) If a card doesn’t appear in the list at all, that integration isn’t ready in this environment yet. Either way, anyone already connected keeps working normally, and the card opens up automatically once it’s ready. There’s nothing to do on your end.
A card shows an `Awaiting approval` badge and the connect button is gone	You tried to connect, but the service hasn’t approved your connection yet and turned it down. After a message in the middle of the screen tells you so, the card and its detail view show an `Awaiting approval` badge and the `Connect` button disappears, because pressing it again wouldn’t help. It clears on its own after 24 hours so you can try again, or right away if someone else connects successfully in the meantime. Your employee also stops offering a connection card for that service. See “When a connect entry point doesn’t appear or is blocked” below for details.
What does connecting Slack give me?	Unlike the others, Slack also works inward: you call employees with `@UpServe` in a channel and handle approvals in the thread. It needs the bot invited to a channel after connecting, so read Calling AI Employees from Slack alongside this page.
Where do I connect them?	The fastest path is the Connections sub-tab under Skills (https://upserve.app/skills/integrations ): click a card to connect or disconnect right there. You can also connect from (B) the `Connect Required` prompt on an installed skill card in My Library, (C) the employee’s Settings screen via the Skill Selector (toggle a skill ON and the connection row appears with a `Connect` button), or (D) a Connect card the employee posts in the chat mid-task. See “How to connect” below for details.
What changes after connecting?	Skills that use that service receive the connection details automatically when they run. You don’t log in again.
How do I disconnect?	Open the Connections screen , click the service’s card, and use the `Disconnect` button in the detail panel. If the service’s skill is installed in My Library, you can also disconnect from that skill card.
How many accounts can I connect per service?	One account per service. To switch accounts, disconnect the current one and reconnect with the new account.
Can someone else use my connection details?	For an employee you use alone, no. Connection details are bound to your account and are never shared with other users or other teams. But if you designate your connection as the account an organization-shared employee uses, then from that point on other members’ chats with that employee (and its automatic runs) use the account you designated. See “The account organization-shared employees use” below.
What account does an organization-shared employee use?	By default, whatever account an organization owner has designated. The same account is used no matter who is chatting with the employee or what started the run. An owner can also open a specific service so members can claim an unclaimed slot with their own account. See “The account organization-shared employees use” below.
Can other members see a key I saved on an organization-shared employee?	Only its name and purpose, never the value, which is never shown again on any screen. Only an organization owner can delete it. A key you save on an employee you use alone is never visible to anyone else. See “Saved keys” below for details.
What happens when tokens expire?	UpServe refreshes them automatically. You’ll see a “Reconnect” prompt if the external service has revoked access, or if the connection is still active but a skill now needs a permission that wasn’t part of the original grant.
Does an employee ever call an external API without asking first?	Sometimes. When an employee needs to send a request straight to an external service using stored connection details, it shows an approval card once. After you approve, it won’t ask again within the approved scope. To see what you’ve approved or cancel it, check the Employee direct access list under the Advanced area at the bottom of the Connections screen .
How do I receive email notifications?	Use Agent Mail through the Agent Email skill. Owners of personal employees first verify their email in Settings → Profile . Personal employees can email their verified owner and individually approved contacts; organization employees with external sending enabled can email external recipients. Recipient policies and sending approval rules apply.
Can I send email with Gmail?	Direct Gmail and Google Workspace mailbox access is not available yet. It is planned after CASA certification. For email now, use Agent Mail with the employee’s UpServe-provided address. See Email and Gmail connections.
Can I connect services besides GitHub and Notion?	Yes. Services like Stripe, Figma, and Canva connect from the same Connections screen’s category list. See “Connecting more services” below.
Can I tell what a skill needs before I install it?	Yes. Skill cards and detail pages in Official skills show an `Integration required: [Service]` badge before you install, and clicking it takes you straight to that service on the Connections screen.
How do I delegate Linear issues to an employee?	Separately from the personal connection above, an organization owner can install the UpServe app on the Linear workspace and assign an employee to each team. From then on, issues delegated from that team go straight to the assigned employee. A team with no assignment goes to your only employee if you have just one; with several, Linear asks you to name which one, so mention the employee’s name when delegating the issue and it goes straight to them.

How to connect

There are four places to connect an external service. Any of them produces the same result, so use whichever is more convenient.

Path A: Connect from the Connections screen (fastest)

Go to Skills → Connections (https://upserve.app/skills/integrations ). Services are grouped into cards by category (docs, projects, communication, and so on).
Click the card for the service you want to connect. A detail panel opens.
Click Connect in the panel to open the external service’s login screen. Review the requested permissions and approve. You return to UpServe automatically.
The panel now shows the connected account name. The same panel also holds organization designation (see “The account organization-shared employees use” below), which skills use this service, and any alternate connection method (External tools (MCP)) for the same service.

The Connections screen. External services are grouped into category cards (Docs & knowledge, Communication & calendar, and so on), each card showing its connection status badge and how it connects: account sign-in, MCP, or your own key

[1] Skills tab → Connections sub-tab │ ▼ [2] Click a card → detail panel opens │ ▼ [3] Click “Connect” → sign in + approve permissions (the service’s own consent screen) │ ▼ [4] Auto-redirect back to UpServe Panel shows the connected account name

Path B: Connect from an installed skill card

Go to Skills → My Library . If you’ve already installed a skill that needs a connection (GitHub, Notion, etc.), its card shows a Connect Required prompt.
Click that prompt to open the same sign-in and approval screen as Path A.
The card now shows the connected account name.

Path C: Connect from Employee Settings

You can also connect while adding the skill directly to an employee.

Go to the employee page → Settings tab → open the Skill Selector.
Toggle the skill that needs an account connection ON.
An account connection row appears below the skill card. The button state tells you where things stand:
- Connect: not yet connected. Click to open the external service’s login screen.
- Connecting…: redirect is in progress.
- Reconnect: already connected or re-authentication is needed. Click to reopen the consent screen.
- [Service] connected: active and ready.
Click Connect and approve the permissions on the external service’s screen. When you return, the connection row shows [Service] connected.

[1] Employee Settings → Skill Selector │ ▼ [2] Toggle skill ON │ ▼ [3] Account connection row appears: click “Connect” │ ▼ [4] Sign in + approve permissions │ ▼ [5] Auto-redirect: row shows “[Service] connected”

Path D: Connect from a card in the chat

This is the most common path. When an employee runs into a task that needs a service it isn’t connected to yet, it shows a Connect card right in the conversation.

Mid-task, the employee posts a card in the chat with a Connect [Service] button.
Click that button to open the external service’s login screen (the same consent flow as the other paths).
Approve the permissions and return. The employee picks up the task where it left off.

[1] Employee needs a service it isn’t connected to │ ▼ [2] “Connect [Service]” card appears in the chat │ ▼ [3] Click the button → sign in + approve permissions │ ▼ [4] Auto-redirect: the employee resumes the task

If what the skill needs is one of the External tools (MCP) servers covered under “Connecting more services” below, clicking the button behaves a little differently. If you’ve already registered that server somewhere else, a single confirmation connects it to this employee right away, with no external login screen. If it isn’t registered yet, the button takes you straight to that service on the Connections screen so you can finish registering it there. This card appears on the web, iOS, and Android. Even when you go to the Connections screen to finish registering, the server is attached automatically to the employee that showed the card, so you don’t need to go back and turn it on in the employee’s settings (if it wasn’t attached, turn it on under the employee’s External tools (MCP) settings).

Skill cards and detail pages under Skills → Official skills show an Integration required: [Service] badge even before you install, so you can connect ahead of time from the Connections screen.

You only connect each service once. If a second skill that uses the same provider is toggled on later, it reuses the existing connection without a new sign-in.

Verifying your email for notifications

Besides external services like GitHub or Notion, an employee that wants to email you reports or alerts (the Agent Email skill) needs your email address verified first. This verification doesn’t happen on the Connections screen above. It lives at Settings → Profile : (A) the email card at the top of the Profile page, where you enter a 6-digit code sent to your address; (B) in the employee’s Skill Selector, toggling on Agent Email shows an “Email verification required” row with a Verify button; (C) a verification card the employee posts in the chat the moment it needs to send mail. Verify once and you won’t need to again. The employee can only ever email the address you verified, never a third party. The one exception: an employee that belongs to an enterprise (managed service contract) organization is released from this limit and can email external recipients (customers, partners) on the organization’s behalf. Even then, only replies from people the employee emailed first wake it; mail from unknown senders is stored but never starts a run.

What happens after connecting

Whenever an employee runs a skill that uses the connected service, UpServe fetches a valid access token and hands it to that skill.
The token is cleaned up at the end of the skill’s run. It’s fetched fresh next time.
Refresh happens right when a skill is about to run, not on a background schedule, so work in progress rarely stalls.
The skill card shows Reconnect required in two cases: (1) the external service revoked access (for example, you changed your password or removed the integration from the provider’s settings), or (2) the connection is still active, but a skill needs a permission that was added after you first connected (so the existing connection doesn’t cover it yet). Clicking the prompt reopens the consent flow either way.

The account organization-shared employees use

When an employee is used by an organization (a company or team) rather than just you, the account it uses to reach Notion, Slack, GitHub, and similar services is chosen ahead of time by an organization owner (OWNER) by default. It doesn’t matter who is currently chatting with the employee, or whether it’s running on its own as a scheduled run, it always uses the same account. This keeps a member chatting with the employee during the day and a scheduled run at night from ever seeing two different accounts.

Organization owners can open a service card on the Connections screen and look at the Organization connection section to see which account is currently designated for each service, and to designate their own connection as that account (or remove the designation). To designate one, you need to have connected that service to your own account first. Owners can always designate, replace, or remove a designation.
Members (MEMBER role) can also designate their own account for specific services. When an owner turns on “Let members designate their own account” for a service in that same section, any member can claim that service’s unclaimed slot with their own account. Turning the switch on notifies every member, so anyone interested knows to act.
- Once a slot is filled, members can’t overwrite it. Only an empty slot can be claimed this way, so no one can bump another member’s account. Ask an owner if the account needs to change.
- A member who designated their own account can remove that designation themselves, the same as an owner can. They can’t remove someone else’s.
- Turning the switch off doesn’t remove an account a member already designated. It only blocks new designations going forward, so the organization’s employee doesn’t lose the service without warning.
For a service where this switch is off, members can see the current designation on that screen but can’t change or remove it.
Connecting your own account doesn’t change a service that has no designation yet. Designating is a separate step only an owner (or, where opened up, the account’s own member) can take, so simply connecting your own account doesn’t automatically become the account the shared employee uses. In that case the employee lets people know an owner needs to designate an account, and work that needs that service waits until they do.
This section only appears for users who belong to an organization. An employee you use on your own doesn’t need this step; it simply uses the account you connected, as described everywhere else on this page.

Note: this designation decides which account is used to reach a service. It’s a separate feature from the “Saved keys” access/deletion rules described further down this page.

Disconnect / re-authenticate

To disconnect, open the Connections screen , click the service’s card, and use the Disconnect button in the detail panel. This works regardless of whether you have a skill for that service installed.

If the service’s skill is installed in My Library, that skill card also shows a Disconnect button next to the connected account name, giving you the same action in one more place.

The account connection row inside the employee’s Skill Selector only offers a Reconnect button, which reopens the consent screen to re-authenticate, it does not disconnect.

After disconnecting, any skill that uses that service will ask you to connect again on its next run. To swap to a different account, disconnect and then reconnect with the new one.

Note: Disconnecting removes the connection for all of your employees that use that service. If you only use employees on your own, this has no effect on anyone else. But if this connection was the one designated above under “The account organization-shared employees use,” that organization’s employees lose access to the service too: every member’s chats and its automatic runs alike. The disconnect dialog tells you which organizations rely on the account, and the organization’s owners are notified.

To undo it: reconnect the same account within 14 days and the designation is restored automatically. Connecting a different account, or reconnecting after 14 days, does not restore it; someone with the authority to designate (an owner, or the member themself if that service is still open to members) then has to designate a new account. (This exists for the common case of disconnecting briefly to re-authenticate.)

Connecting more services

The GitHub, Linear, Notion, and Slack connections covered above support both a one-click Connect with account sign-in (account sign-in) and an alternate External tools (MCP) connection method for the same service. MCP (Model Context Protocol) is the standard way an AI employee calls an outside service’s features. Open that service’s card on the Connections screen and you’ll see both, with Connect with account recommended by default since it has less friction. Some services only offer sign-in (Google Calendar, Drive, Tasks); others are External tools (MCP) only: project management (Asana, ClickUp), docs and knowledge bases (Atlassian), sales and payments (HubSpot, Stripe), design and video (Canva, Figma, Higgsfield, OpusClip, VEED), website management (Webflow), and scheduling (Calendly). Even for the same provider, a connection made with an account and one made via External tools (MCP) are treated separately, so you connect each one on its own.

Where: the Connections screen , from the category-grouped cards. No need to look up a service’s address yourself. If a service isn’t listed, use + Register a server not listed here in the Advanced area at the bottom of the screen to add one by address. This manual registration screen works the same way on web, iOS, and Android.
What happens next: most services in the list use sign-in, so picking one takes you straight to that service’s login screen; approve the permissions and the connection is done. (If you enter a server yourself that uses an API key, paste the key and click Test connection to preview the features it makes available. Only then can you register it.)
To use it on an employee: registering a server doesn’t automatically make it available everywhere. Go to the employee page → Settings tab → External tools (MCP) section and turn on the servers you want that employee to use. This section is available on iOS and Android as well as the web, so you can turn servers on, toggle individual features, and choose the approval level right from the app (new server registration still happens on the Connections screen on all three platforms). See Equipping Tools for details.

If you belong to an organization, registering an External tools (MCP) server lets you choose Who owns this connection: yourself, or an organization. Choosing an organization stores a single shared token that anyone in that organization can use and re-authorize, an organization-shared connection. If the person who registered it later leaves the organization or deletes their account, the connection keeps working.

A connection you already registered under your own account can be moved to an organization later. Click Share with organization on the server’s card and pick the target organization.

You can only move a personal connection you registered yourself; a connection already owned by an organization can’t be moved again.
Once moved to an organization, it can’t be moved back. To return it to personal ownership, delete the organization’s connection and register a new one under your own account.
If the target organization already has a connection at the same address, or its name or identifier clashes with an existing one, the move is blocked. When the identifier clashes, renaming won’t help since the identifier itself doesn’t change, so register a fresh connection in the organization instead.
If other employees outside the target organization (your own personal employees, or another organization’s employees) are still using this connection, disconnect them there first before moving it.

An organization-shared connection shows the organization’s name on its card, and anyone in that organization, not just an owner, can turn it on, refresh its feature list, or delete it.

Deciding whether tool calls need approval every time

Expand a server in the employee’s External tools (MCP) section and, alongside the on/off switch for each of its features, you’ll see three choices for “Approval for this server.”

Ask every time (default): every call to that server shows an approval card first, and you have to approve it to run.
Auto-approve read-only tools: calls that only read data run immediately with no approval card, while anything that changes data still asks first. This option is disabled if the server hasn’t marked any of its tools as read-only. The count of eligible tools is shown next to the option’s name.
Auto-approve every tool on this server: every call runs immediately with no approval card. If a call also needs connection details from the “Saved keys” section above, those still require their own approval even with this option selected.

Reference material and preset prompts connect too, not just features

Some services offer more than callable features (tools): reference material (documents, lists) or preset prompt templates you can reuse. When a service offers these, they appear in the External tools (MCP) section alongside its tools and can be turned on or off individually the same way.

Managing servers you’ve registered

Servers outside the catalog (added by address) are managed in the Advanced area at the bottom of the Connections screen. External tools (MCP) connections for a catalog service (Notion or Asana, for example) are managed right in that service’s own detail panel.

See each server’s connection status (Active / Not connected / Error) and when its feature list was last checked. An Error status shows the reason.
Click Refresh tools to check the service again for features that were added or removed. If anything changed, you’ll see what was added, removed, or changed before clicking Apply changes to make it active.
For a server connected with an API key, Replace token swaps in a new value.
Delete removes the server, and every employee that used it loses access to its features.

Skills that connect with an API key (automatic setup card)

Instead of opening a login screen like GitHub or Slack, some skills need an API key you’ve obtained yourself, for example, an SMS-sending skill that needs an API key, a secret, and a registered sender number. When one of these skills is missing a required value, a setup card appears automatically in the chat the moment the employee tries to use it, walking you through what’s needed and where to get it.

The moment the employee needs the skill, a “Set up [Skill]” card appears in the chat.
For each required value, the card shows its name, a short description, and a link straight to the page where you obtain it.
Pick which employee these values are saved to. If exactly one of your employees already uses this integration, it’s picked automatically. If you haven’t hired an employee yet, you’ll need to hire one first before you can continue.
Get the value from that link, paste it into the card’s input field, and click Save. If that employee doesn’t have the integration’s skill yet, saving installs and equips it automatically, so you never need to install the skill ahead of time.
Once every required value is saved, the skill is ready to use. If a feature only needs a subset of the values, that feature is marked “ready” as soon as its subset is complete, even if other values are still missing.
Some values represent a step that takes time outside UpServe, such as an external review process. Mark those done from the card once they’re complete.

Values entered in this card are stored the same secure, per-employee way as the “Saved keys” described below. Open that service’s card on the Connections screen and you’ll find the same form for picking an employee and entering or viewing values (starting from the hub installs and equips the skill on save too, the same as from the chat card).

Saved keys (connection details you store yourself)

Even for services without a prebuilt connection, you can store an API key or token so an employee reuses it across tasks. For example, save a payment-service API key once and the employee uses it without asking again.

How to save (in chat): on the web, use the lock button in the chat box; on the iOS and Android apps, tap the + button in the chat box and choose Secure Input from the menu. Fill in the “What is this for?” field with a short description (e.g. “Stripe live API key”). Adding a description saves it by default, and UpServe names it automatically from that description (e.g. STRIPE_LIVE_API_KEY). To use it once without saving, check “One-time use (don’t save)” instead. If you want to pick the name yourself or overwrite an existing saved key, expand Advanced to choose that. Click Add more connection details to enter several values at once (for example, a username and a password) in a single send, up to 10 items. Each item gets its own description and is saved separately. Team chat is a shared space with multiple team members watching, so there’s no single employee to safely hand connection details to, so the mobile app’s + menu doesn’t show a Secure Input option there. If you need to save something, do it in a one-on-one chat with that employee instead. However, when an employee posts a question card in team chat asking for connection details, a team member who can answer it can send the value straight to that employee with the card’s Answer with secure input button. In team chat, a value sent this way is used for that task only; a saved key is used in one-on-one chats with that employee.
How to save (from the Connections screen directly): you can also click + Add a key in the Saved keys section under the Advanced area at the bottom of the Connections screen and enter the employee, name, and value directly.
Manage: view and delete them per employee in that same section.
Private to the employee: a saved key is used only by that employee when it runs. For an employee you use alone, no one else ever sees it. For a key stored on an organization-shared employee, other members of that organization can see its name and purpose in this same list (never the value), and only an organization owner can delete it.
Never shown again: for security, the stored value is never displayed again. To change it, delete and save a new one.
No auto-refresh: unlike the account connections above, a key you store yourself does not refresh automatically. Replace it when it expires.
Remembered destinations: once you let a tool use this key (by approving it on a card the employee showed you), UpServe remembers that combination so automatic runs (like scheduled runs) won’t ask again. Remembered destinations show up as tags in the same section; click the × on a tag to remove just that one. After removing it, the next use asks for approval again.
Changing the value (overwrite): saving a new value over an existing key shows a confirmation dialog asking whether to keep the destinations remembered above. It defaults to off: even with the same name, the new value might belong to a different service, so the previous value’s auto-approvals aren’t carried over automatically. If you’re just rotating the same secret, check Keep existing approvals in that dialog.

Employee direct access

Sometimes an employee needs to send a request straight to an external service using stored connection details or a connected account, for example calling a service’s API directly from code. Even then, the employee never sees the actual password or token; UpServe passes it along securely in between.

Approval card: the moment an employee needs this kind of access, it shows an approval card in the chat. The card summarizes which connection details, which service, and what kind of request would be allowed. Once you approve, the employee won’t ask again for requests within that same scope.
Review: the Employee direct access section under the Advanced area at the bottom of the Connections screen lists everything you’ve approved so far (the section only appears once you’ve approved at least one). Each entry shows which connection details, which employee, which destination and requests it covers, and how many times it’s been used today (against its limit, if one is set).
Revoke: click Revoke access on any entry to block it immediately. If the employee needs the same access again later, it shows a new approval card.

Note: Revoking only affects that one entry. It doesn’t change any other approval for the same service under different connection details or a different employee.

One-time secrets (values that are not stored)

For values you don’t want kept (a password or a verification code), send them the same way as above (the lock button on web, or + → Secure Input on mobile) but leave the save option off. Your plaintext value is not stored; the encrypted value is automatically deleted a short time later (up to 15 min). Only the label and a masked placeholder remain in the conversation. Here too, Add more connection details lets you enter values like a username and password together, up to 10 items in one send.

Security

Per-user isolation (values only): the actual value of your connection details (a password or token) is stored against your account only, and no other user or organization member can retrieve it. A key stored on an organization-shared employee is the one exception on visibility, not value: its name and purpose can be seen by other members of that organization, but the value stays hidden either way. See “Saved keys” above for details.
Saved keys are per-employee: a key you store yourself is encrypted for that employee only and is never exposed to external visitors of a shared link.
The employee never sees the raw token: tokens are passed to the skill’s execution environment as environment variables only, and cleaned up when the run ends. They are not echoed into chat messages or logs. Employee direct access requests go further: the connection details never enter the employee’s execution environment at all; UpServe’s server attaches them to the request on the employee’s behalf.
Encrypted at rest: both the access token and refresh token are encrypted before being saved to the database.
Standard account sign-in + CSRF-safe: UpServe uses the standard Authorization Code flow and rejects forged callbacks.

Connect external tools from a conversation

When a connection card appears in a web conversation, check the service and choose its approval setting: ask every time, automatically approve read-only tools, or automatically approve all tools for that connection. You can change it later in employee settings.

In the direct-access approval list, each approver can view and revoke their own approvals. Space administrators can manage all approvals for employees in that space.

When connecting fails

If something goes wrong while connecting, the reason is shown right where you land when you return, whichever screen you started from (a chat card, the employee office panel, or the Connections screen).

What happened	What you see
The service hasn’t approved the connection yet and turned it down	A message in the middle of the screen, “Waiting for ○○ approval” (press OK to close), then an `Awaiting approval` badge
You cancelled on the service’s consent screen yourself	Nothing. This is treated as a choice, not a failure
Any other failure	A failure notice such as “Failed to connect ○○” (a toast on web; on mobile it also says to try again in a moment)

Advanced

The rest of this page describes internal behavior, useful if you author skills directly or need to debug an integration. Day-to-day users can skip it.

Permissions requested per service

UpServe asks for the following scopes (user-facing summary; the actual consent screen comes from each service):

Service	Permissions requested (user-facing summary)
GitHub	Read and write code, issues, and pull requests across your public and private repositories; read organization membership, teams, and profile
Linear	Read and write issues, projects, and comments in your workspace; create issues
Notion	Read and write only the pages and databases you select on Notion’s own consent screen. Which pages to share is controlled by the Notion platform; UpServe only accesses what you grant there.
Slack	Read messages from public channels, private channels, and 1:1 DMs you’re a member of; post messages as a bot; read user and team information
Google Drive / Calendar / Tasks	Read and write files, events, and tasks (Google Drive access is limited to files you select via the Picker)
Threads	Read your profile info; publish posts, replies, and reply chains as you; read post and account performance metrics. It hasn’t finished external review yet: its card shows a `Coming soon` badge with no `Connect` button, and only test accounts UpServe has registered can get past the connection’s login/consent screen at all.
Instagram	Read the profile and media of your business or creator account; publish photos, Reels, and carousels; read, write, reply to, hide, and delete comments; read and answer direct messages (within 24 hours of the other person’s last message). If you connected before, reconnect once to use direct messages. For the same reason as Threads, until review finishes it shows a `Coming soon` badge and only test accounts can connect.
YouTube	Read your channel info, videos, and playlists; upload (defaults to private), edit, and delete videos; post comments and replies; manage playlists. Video and channel search and transcript extraction run on the same connection, so YouTube features need a connected account.

The consent screen is always the external service’s official page. The exact scopes granted are stored alongside the connection.

Resolution order for organization designations

Each time an employee runs, which account it uses is decided in this order:

If the organization has a designated connection for that service, it uses that connection. The same rule applies whether an owner or an opened-up member designated it.
If there’s no designation and the employee is owned by a single person (no organization), it uses that owner’s own connection, so nothing changes if you work alone.
If there’s no designation and the employee belongs to a multi-member organization, it uses no account at all. It never falls back to the personal connection of whoever is currently chatting. That fallback is exactly what used to cause different members to see different accounts, so it was deliberately removed.

Managing the designation itself (creating, replacing, or removing it) defaults to organization owners (OWNER). When an owner turns on “allow members to designate” for a given service, a member can claim that service’s empty slot with their own account and later remove their own designation, but an already-filled slot can never be overwritten by another member. Viewing the current designation is open to every member; only an owner can flip the policy switch itself.

How skills receive connection details

Connection details needed by a skill are supplied securely. Use secure input rather than pasting passwords or connection details into ordinary chat.

How the API-key setup card (Enter connection details) works

When a skill’s definition declares setup.fields (values the user enters directly) and setup.external_steps (steps that take time outside UpServe, like an external review), UpServe renders a setup card containing only the values still missing whenever the employee tries to load that skill. Values entered on the card are encrypted and stored the same way as “Saved keys” above, scoped to that employee only; once a value is filled in, its row is marked done on the card. If a skill declares capabilities (named bundles of values), a capability unlocks as soon as all the values it needs are present, even while other values on the card remain outstanding. This inline chat card currently renders in the web app only; it is not yet implemented in the iOS or Android apps. The same value-entry form is available in the Connections screen’s Enter connection details section on all three platforms (web, iOS, Android), though, so on mobile you fill in values from the Connections screen rather than from the chat.

The Connections screen’s Enter connection details section renders this same form even when zero employees have that integration’s skill equipped yet (it used to hide the form and point only to Official skills instead). The moment you save a value, UpServe installs and equips the integration’s system skill on the employee you picked (idempotent: skipped if already there) before writing the value; if that install/equip step fails, the value is not saved either. Only the system skill this catalog entry points to can be installed this way; a user can’t direct it at an arbitrary skill id.

When a connect entry point doesn’t appear or is blocked

A card that isn’t “open” can mean one of three different things. Both the Connections list and the actual connect (authorization) request read the same underlying check, so a card is never open in the list but blocked when you actually click it, or the reverse.

The card doesn’t appear in the list at all: an account sign-in-based integration only works once UpServe’s server has app credentials (a connection settings) configured for it. New integration code and that configuration are deployed separately, so there can be a short window where the code is live but the credentials aren’t set yet. During that window, if no one has connected the service yet, its card doesn’t appear on the Connections screen at all. Rather than show a Connect button that fails when pressed, UpServe hides it. Anyone who already has an active connection keeps seeing their connection row regardless. If the check itself can’t be completed, UpServe defaults to showing the entry point rather than hiding it.
The card appears with a Coming soon badge and no Connect button: the app credentials are configured, but that service hasn’t yet passed an external platform’s app review (Meta, Google, and so on). To signal that the feature is coming rather than absent, the card stays in the list, but the Connect button (which would fail anyway) is replaced with a Coming soon badge. Once review passes, the badge disappears immediately with no app deploy needed. Anyone with an existing active connection never sees this badge, since their connection keeps working regardless of review status. Threads and Instagram in “At a glance” above are the current examples of this state.
The card shows an Awaiting approval badge and no Connect button: you tried to connect, but the external service hasn’t approved your connection yet and turned it down. When you come back from the connect window, a message titled “Waiting for ○○ approval” appears (on web, iOS, and Android alike, and you press OK to close it). The card and its detail view then show an Awaiting approval badge with a note that you can connect again once it’s approved. This state lasts only while all of these are true:
- you received an approval rejection within the last 24 hours,
- no one has connected this service successfully since then, and
- you don’t already have an active connection to it.
After 24 hours, or as soon as someone connects successfully, the badge goes away and you can connect again. If you force a connect attempt in the meantime, you only get a note saying it can’t connect while approval is pending. Your employee also stops offering a new connection card for that service and doesn’t ask you to reconnect. A service you’re already connected to never shows this badge.

Google Drive Picker

When a skill or employee action needs to access Google Drive files, UpServe uses the Google Picker, a file selector that runs inside your browser under your Google account. Only the files you explicitly select through the Picker are accessible; UpServe does not request access to your entire Drive. Access is limited to files you select or create through the app.

Picking a folder (and why a recurring scan cannot work)

The Picker lets you choose folders as well as files, but picking a folder opens only the folder itself. Neither the files already inside it nor files added later become accessible, because access attaches to the exact item you picked.

The catch is that Google does not report this as a permission error. Listing the folder’s contents returns zero files instead of a failure, which is indistinguishable from a genuinely empty folder.

As a result, “watch this folder and check periodically for new files” is not possible on Google Drive. Scheduling it produces a job that quietly finishes with “no new files” every time without ever having been able to see any. If an employee proposes this, the advice is wrong.

What is and is not possible:

What you want	Possible?
Periodically check whether a file you picked has changed	✅ Yes
Automatically discover new files appearing in a folder	❌ No. Each new file has to be picked again by a person
Treat a whole folder as the working scope	❌ No

If you are working with material that keeps arriving as new files, a service that grants access at the folder or database level (Notion, for example) fits better than Drive.

Token expiry and refresh

When an access token is close to expiry (within 5 minutes), UpServe uses the stored refresh token to mint a new one at the moment a skill requests it, right before the skill runs. This is enough for most services, so there’s no separate background job refreshing them ahead of time. The exception is Threads and Instagram: because its refresh window closes before the token itself expires, UpServe proactively refreshes even connections that haven’t been used in a while, so they don’t silently lock out.
Refresh happens just before the skill runs, so the new token is the one handed to the skill.
If refresh fails (the user revoked access externally, or the refresh token was rotated out), the connection is marked inactive and the skill card surfaces a Reconnect required prompt for the user to consent again.

What decides the MCP connect button on a chat card

When an employee runs into an MCP server it needs but isn’t connected yet, it shows a connect button on a card. The server always decides which server that button points to and what happens when it’s pressed. An employee’s own claimed server name or address is never trusted as-is.

The server behind the button must be owned by you (or your organization), Active, and not need re-authentication, the same bar used for the connectable candidates shown in the employee’s External tools (MCP) settings.
If a server registered at the same address already exists (even if it was connected through a different employee), the button connects that one directly. If none exists yet, the button takes you to registration instead.
The button that goes to registration also carries the employee that showed the card. When registration finishes there (for sign-in servers, when sign-in completes), the server attaches it to that employee. The server re-checks your permission to attach; without it, the server is registered but not attached. A failed attach never fails the registration itself.
The button’s label (the server’s name) always comes from the server, never from anything the employee wrote. Long names are truncated.
A single card can carry at most 3 jump buttons.
If a lookup fails or points at an unknown server, that one button is silently dropped and the rest of the card still renders normally.

How MCP server registration works

Whether picked from the list or entered by address, a server goes through the same validation on registration (HTTPS is required, among other checks), so an entry from the curated list isn’t trusted any more than one you type in yourself. UpServe only supports remote servers reachable over HTTPS; a server that only runs on your own machine can’t be connected. Authentication is one of: no authentication, API key (Bearer), custom header, or sign-in (account sign-in).

Registering a server under an organization, or moving a personal connection to one, changes the actual holder of the connection details to that organization’s service account; the person who registered it is kept separately as the registrant. Name and identifier uniqueness is scoped to that service account, so an organization can only hold one connection per service (unlike a personal account, which can register several). Access and delete checks on an organization-shared connection only look at whether you belong to that organization, not whether you’re an owner.

The MCP tool list is pinned at registration/refresh time

The feature list saved and used at runtime is a snapshot taken the moment you register the server or apply a Refresh tools update. If the service quietly changes what a feature does afterward, that change has no effect until you check and apply a refresh yourself. This keeps what you reviewed at registration time in sync with what actually runs.

Item limit on secure input

When you send several items at once through secure input (the lock button on web, or + → Secure Input on mobile), whether saved or one-time, a single send can hold up to 10 items. The screen and the storage step share the same limit.

How “remembered destinations” are removed

The “remembered destinations” tags in the Saved keys section are removed one at a time, by a request scoped to that single item; the whole list is never replaced in one call. This keeps a removal made in one browser tab from accidentally undoing something newly remembered in another.

Scope of an employee direct access approval

An employee direct access approval is valid only within the scope you approved at the time (the target service address and the kind of request). Requests outside that scope are automatically denied, and the employee shows a new approval card if it needs a wider scope. If an entry has a daily call limit, no further requests go through once that limit is reached for the day.