service access.

[ invite someone to one service ]

Open service access, choose your team and project service, then create an invitation for one verified email and an explicit access deadline. Check the service ID and project/worktree context before sending its one-time code privately. The deadline is entered in your local time and saved as an absolute instant.

The recipient opens accept a service invitation, signs in, and pastes the code. check invitation shows the exact service and deadline without accepting it. accept service invitation grants visit permission for that service until the original deadline. The issuer must verify a matching email; entering an email or linking another account is not proof of acceptance.

Service invitations create neither team membership nor management permission. They work for services, including publicly reachable HTTP endpoints. Your database, SSH server, or application still checks its normal user/password/key authorization.

[ use the cli ]

tnl share service invite create orders --email sam@example.com --expires-in 4h
tnl share service invite accept SECRET
tnl share service list orders
tnl share service revoke orders ACCESS_ID

Create, list, and revoke select a configured service key or an exact svc_… service ID. Use the key from the correct project/worktree, or select its immutable ID explicitly. Public URL hostnames and similar saved names are not fallback selectors. Outside a project, supply the service ID and appropriate server/team selection.

Invitation creation requires exactly one of --expires-in or --expires-at. For an absolute deadline, use RFC3339, such as --expires-at 2026-11-02T18:00:00Z. Invitations may last at most 30 days. Creation returns the secret once; a list never recovers it. --output json is available for automation and also contains the secret when creating access.

After acceptance, use your normal client through a local connector:

tnl auth login --team shop
tnl connect available
tnl connect start orders --detach --listen 127.0.0.1:15432

Follow tnl's printed native TLS instructions. Private and public managed endpoints use the same local connector workflow, without an application client certificate. See managed service connections.

[ inspect and revoke current access ]

The website's current access lists active team and identity grants for the selected service. Pending invitations grant no access. Expired and revoked records are not current access; the CLI list includes that history too. Control returns pages of at most 100 grants or invitations, with an opaque next_cursor when more remain. The website reads all pages before hiding expired or revoked records. Each page requires a fresh signed human assertion over its exact path and query; a later page failure does not display a partial result.

Management permission and visit permission are separate. A manager needs an applicable visitor grant too. Revoking one grant does not remove a separate team grant or another identity grant. The application may also have its own authorization rules.

Creating an invitation returns 201 with its one-time credential and a secretless invitation record. Retrying the exact Idempotency-Key and input returns 409 credential_delivery_unavailable with details.resource_id after current management checks. If delivery was lost, revoke that invitation and create with a new key. Changed input also returns 409; neither listing nor retrying recovers a secret or extends the original deadline.

Revoke a sgr_… identity/team grant to remove that exact permission. Revoke a sivt_… invitation to cancel it and revoke the identity grant created when it was accepted. The same operations are available beside each website entry. Revocation or expiry can close active traffic; a disconnected control service cannot extend access beyond its bounded authorization deadline.

An invitation does not apply to another service with a similar name, another worktree, or a separate public URL. For public URL invitations, use the public URL sharing workflow.

[ service http tokens and links ]

For an HTTP service, the website also lists secretless token/link summaries and lets current managers create or revoke individual credentials. Each new grant requires an explicit deadline. The website displays the actual token permission expiry or browser-link deadline; these can differ.

tnl share service token create api --expires-in 4h
tnl share service link create api --expires-in 4h
tnl share service list api
tnl share service revoke api SHG_ID

HTTP token/link creation requires exactly one deadline flag and allows at most 7 days. It requires current management and visit access and a publicly reachable HTTP service endpoint. Tokens use the Tnl-Visitor-Token header:

curl -H "Tnl-Visitor-Token: $TNL_SERVICE_TOKEN" https://api.example.com:25443/

Use the exact credential printed by a matching CLI build. It remains usable for the advertised lifetime while its grant and issuer's visit authority remain current. Creating another credential or changing an unrelated policy does not require replacing it. Ordinary credentials are not tied to the creator's short-lived sign-in token. Service credentials cannot visit a separate public URL.

The website currently consumes a contract with both permission.visitor_token and refresh_credential. Its token result shows the permission's actual expiry and is not automatically renewed. A browser link uses control's share_url, containing the grant-bound refresh credential, and shows the grant deadline. Do not construct a link from the visitor token or assume that a website token lasts as long as its parent grant. CLI and website credential formats must be qualified against the same server release before treating them as interchangeable.

Publishers verify possession locally against authenticated policy snapshots, normally refreshed every two seconds and valid for at most ten seconds. Removing a verifier cancels affected requests and streams; a policy outage cannot extend the last accepted deadline. A service can have at most 256 unexpired, unrevoked HTTP credentials. Revoke unused credentials before creating more.

The website shows a new secret or link once. Later lists show only the shg_… ID, kind, deadline, and revocation state.

Company-bound credential creation also needs the creator's existing control session to back later authorization checks. The website reports source_sign_in_required when that backing is unavailable; use the CLI with a current company sign-in. The website can still list and revoke existing credentials. Refreshing a page or linking an account does not renew company source authentication.