Cross-org project sharing

What project sharing is

Project sharing lets you grant someone outside your workspace read-only or operational access to one specific project plus the licences activated on it. It is the right fit for contractors, partner agencies, or a client who needs to install a package on a host you do not control. They do not become a member of your workspace, they do not see anything else you own, and you can revoke the share at any time.

Sharing is one hop. A recipient cannot re-share with a third party, so the access surface stays exactly as wide as the people you invited directly.

How the sender invites someone

1. Open Projects and pick the project you want to share.
2. Click "Share project". A slide-out modal asks for the recipient's email and a role.
3. Pick a role:
   • Viewer - read-only. Sees the project, its package list, install snippets, expiry dates, and QA status. Cannot rotate tokens or attach licences.
   • Developer - read + operational. Same visibility as Viewer, plus the ability to rotate the project access keys. Still cannot attach or detach licences; those remain owner-only.
4. Submit. Packagento emails the recipient a single-use accept link and the pending share appears in the project's "Shares" section.

The invite email goes through the same async pipeline as every other Packagento mailer, so it should arrive within a minute.

How the recipient accepts

1. The invite email contains an accept link. Click it.
2. The recipient must be signed in to a Packagento account. If they do not have one yet, they create one first, then the accept link finishes the share.
3. After accepting, the shared project appears under "Shared with me" on their Projects page, distinct from projects they own outright.

Accept links are single-use and time-bound. A revoked or already-accepted link no longer works.

What the recipient sees

A share grants visibility into one project and the licences activated on it. The recipient sees:

• The Composer install snippet for each licensed package on the project.
• Each licence's package, version, expiry date, and current QA status.
• Project access keys (Developer role only; Viewer cannot rotate or read them).

A share never exposes:

• Billing addresses, payment methods, or invoices.
• Purchase price, refund history, or subscription cost.
• Other projects, other licences, or any member of your workspace.

Licences are inherited read-only. The recipient cannot detach a licence from the project, transfer it, or buy more against it; those actions stay with the workspace owner.

Revoking and leaving

Either side can end a share at any time:

• Sender revokes - from the project's "Shares" section on Projects, click "Revoke" next to any active or pending share. The recipient loses access immediately and receives a revoke email.
• Recipient leaves - from "Shared with me" the recipient can click "Leave" on any share they hold. No reason required.

Revoking does not affect the underlying licences. They stay attached to the project; only the recipient's view of them ends.

Privacy guarantees

• One hop only. A recipient cannot re-share with a third party. If a contractor needs to bring in a teammate, the original sender has to send them their own invite.
• Billing stays private. Prices, invoices, refund requests, and payout settings are scoped to the workspace owner. A share never crosses that boundary.
• Audit trail. Every invite, accept, revoke, and leave is logged on both sides' activity feeds, so there is always a record of who saw what and when.
• Single-use accept links. A link cannot be reused, forwarded to a different account, or replayed once revoked.

When to share versus invite to the workspace

If the person needs access to more than one project, or you want them in your activity feed and member list, invite them to the workspace itself - see Team and roles. Project sharing is for one-off, narrow, time-bound access where workspace membership would be more access than the situation calls for.