elaichi__connection__share
Grant a person, a team, or the whole organization access to a connection at one of three levels: "view" (see that it exists), "use" (also bind it into their own toolbox entries and run its tools), or "edit" (also rename it and start a reconnect) — even "edit" never lets the grantee transfer or delete the connection; that stays with the owner or connection:manage. grantee_id is required when grantee_type is "user" or "team" and must be omitted for "org" — the schema cannot express that conditional, so check it yourself. Re-sharing to the same grantee updates the level rather than adding a second grant; to take access away use connection.unshare, which identifies the grant the same way. This is the ONLY non-destructive way to give someone else access to your connection — connection.transfer instead REASSIGNS OWNERSHIP, which removes it from your own connection.list the moment it completes, so never reach for transfer when the user asked to "share", "give access to", or "let someone use" a connection. Returns the ACL entry plus { connection_id }; for a "user" share the entry also carries grantee: { id, name, email }, so you can confirm by name who was granted access.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Connection id (`conn_…`) from connection.list. | |
| level | Yes | "view" = see it exists, "use" = also bind it into their own toolbox entries and run its tools, "edit" = also rename it and start a reconnect — never transfer or delete it. | |
| grantee_id | No | A USER id (`usr_…`, from member.list) when grantee_type is "user", or a TEAM id (`team_…`, from team.list) when it is "team". Required for both despite not being listed in `required`; omit it entirely for "org". | |
| grantee_type | Yes | Who is being granted access. |