Sharing device data with another account

Your devices belong to your account. Another company sees nothing of them until you say so. This page covers the three sharing shapes people actually ask for, and how to take each one back.

Sharing is managed in ThingHub → Access, and every share is made against a scope — a named selection of things in one of your repositories. If you have not made a scope for the devices you want to share, make that first: it is the boundary the share is written against, and it is what you delete to end the share wholesale.

What a share can say

A share names one account, one scope, and the operations that account may perform:

Operation	What the other account may do
Read telemetry	see the readings your devices report
Read usage counters	see how much your devices ran — counts and active minutes, never the readings themselves
Read attributes	see device settings and reported values
Write attributes	change device settings
Send commands	tell a device to do something

Grant only what the relationship needs. There is no “reader” or “admin” level to pick from — you choose the operations one at a time, and anything you do not choose is refused.

Three shapes

A partner who operates the fleet with you. Share the scope with their account and pick the operating capabilities — read telemetry, read attributes, send commands. They see the devices in that scope and nothing else in your account.

A software publisher who supports one app on your robots. A publisher supporting their own app does not need the whole machine. Name the app when you create the share, and the publisher can read only the records that app produced — the rest of the robot’s telemetry stays yours. If the publisher asks for the scope’s telemetry without naming their app, the request is refused.

An app-scoped share carries telemetry read and nothing else. If you need to give a publisher anything more, that is a separate, ordinary share, and it will not be narrowed to their app.

fgai access grants-create --body '{
  "grantee_account_id": "acc-publisher-01",
  "scope_id": "scp-store-robots",
  "caps": ["telemetry:read"],
  "app_namespace": "clearjanitor" }'

One publisher with two apps on the same fleet gets two shares, one per app.

A license authority that bills you for what you used. A licensor needs to know how much a robot ran, not what it reported. Share usage counters instead of telemetry:

fgai access grants-create --body '{
  "grantee_account_id": "acc-licensor-01",
  "scope_id": "scp-store-robots",
  "caps": ["telemetry:usage-read"] }'

They receive per-robot sample counts and active minutes per hour or per day. There is no reading, no payload, and no device content of any kind on that feed — not as a matter of policy, but because the only thing that share opens is the counter feed.

Only one account may change device settings

A device has one set of settings, so it has one author. By default that is you.

You may hand attribute writing to one other account for a scope — a store that configures the robots it rents from you, for example. While that delegation exists, a second one over the same scope is refused. Take the first one back if you want to name someone else. Everyone else you share with can still read, watch and command; they just cannot reconfigure.

Taking access back

• Remove the share in ThingHub → Access, or fgai access grants-delete --id <grant-id>. Access ends — including an app-scoped publisher’s narrowed view.

• Delete the scope to end every share written against it at once.

• Remove the device from the repository to remove it from every scope, and so from every share, at once.

Revoking is confirmed before it takes effect and is recorded in audit. Access ends shortly after you confirm, not at the same instant, so if you are testing a revoke, re-check a moment later rather than concluding it did not work.

Note

You can only share a scope you own. Cross-account grant revocation for incident handling is a platform-administration function and is not available to tenant users.