Connect your accounts.

Connectors authorize Kaitoi to use an external account through that service's supported permissions. A service connection is separate from using the same provider to sign in to Kaitoi.

#Follow the permission chain

First identify the connected external account. Then verify its service permissions, its access to the specific resource, and the destination of the intended action. Calendar permission does not imply mail permission. Test a known resource with a read operation before diagnosing a write. Ending access can require removing Kaitoi’s connection record and revoking the provider-side app grant. Signing in to Kaitoi is a separate identity flow.

Alex’s fictional work account has a calendar grant. Selecting the calendar branch still requires checking access to that specific calendar; selecting mail fails the service-scope match. The connection record and provider grant have separate revocation locations.

#Connect a service

Your account needs the Connectors capability. If it is unavailable, Settings shows the account requirement before offering connections.

1. Open Settings → Connectors.
2. Find the provider and service you need.
3. Choose Connect, or the specific service button when several are offered.
4. Sign in at the provider and read the requested permissions.
5. Finish the authorization and return to Kaitoi.
6. Check the connected account name before using it in a workflow.

Only providers configured for the installation can be connected. An Unavailable state is not a request for you to paste an arbitrary provider secret into the graph.

#Select the intended account

Several accounts can be connected to the same provider. Choose the one the operation should use, especially before sending messages, uploading files, or publishing content. A successful authorization does not mean an operation is allowed to access every resource in that account.

Start with a read operation against a known test resource. Then inspect the destination and input data before using a write action.

#Reconnect and disconnect

Kaitoi refreshes supported expiring access as the connector is used. If the provider has revoked the grant, requires consent again, or refuses the current scopes, use Connect again for that provider or service and complete its authorization flow.

Disconnecting removes Kaitoi's stored connection. To remove the provider-side grant too, use that provider account's connected-app permissions. Review both places when access should end completely.

#When a workflow fails

Check the account, service permissions, resource access, and provider error. Connecting a calendar service does not automatically supply permissions for mail or video upload. A connector also does not make an otherwise unsupported node eligible to run in a published Station.

#Inspect identity, permission, and action separately

Connect: grant the intended provider/service permissions to the intended account. Use: choose that account and verify the operation's resource and destination; sign-in identity is a separate connection. Disconnect: remove Kaitoi's record and review provider-side connected-app access separately.

#Checks and next steps

A connected account name helps identify who granted access, but resource permissions still come from the external service. Check both before an operation writes, sends, uploads, or publishes. Start with a known test resource and a read operation when you are diagnosing access.

If a service asks for fresh authorization, complete its supported consent flow and check the resulting account. Do not paste unrelated provider secrets into graph inputs to work around a missing connector capability. Revisit the external account's connected-app permissions when you intend to end its grant as well as removing Kaitoi's local connection record.