Sharing Pet Device Access With Family, Pet Sitters, and Caregivers

Why access architecture comes first

“Shared access” can mean three different things: a separate invited account, reuse of the owner’s credentials, or a narrow link controlled by the owner. Those designs affect attribution, role scope, billing exposure, notification behavior, and how one person is removed.

Table: Access architectures. Swipe horizontally to see all columns.

Prefer a separate identity or owner-ended narrow link when available; shared credentials make attribution and individual revocation harder.

Current access matrix

The matrix below records only what the retained public documentation establishes for the exact ecosystem. It uses the current sharing records for Fi, Tractive, Petcube, Furbo, Wyze, PETLIBRO, and PetSafe. “Unknown” is not converted to “no,” and a role label is not treated as proof of enforcement.

Table: Current product access matrix. Swipe horizontally to see all columns.

A documented invite path is not enough: verify role scope, owner removal, temporary sharing, notifications, and the fields that remain unknown.

Family and co-owner access

A co-owner may need broad authority, but broad access should still use a separate identity when the platform supports one. Fi Full Access includes location, health, and billing. Tractive family members get tracking and monitoring tools while the owner retains zones, subscription, tracker assignment, and membership controls. Petcube Family access is described as almost full control. Wyze uses a separate shared-user account with product-specific restrictions.

Table: Household scenarios. Swipe horizontally to see all columns.

Choose the narrowest documented identity and role that can do the caregiver’s job, then record how the owner will remove it.

Sitter and walker access

A routine sitter usually needs less authority than a co-owner. Fi documents View-only and Restricted roles for walkers and caretakers. Petcube Friend access can be scheduled and can limit selected controls. Tractive’s family member role keeps settings and billing with the owner but remains broad for location and history. Feeder documentation is less complete, so schedule edits and alert ownership need live verification before the handoff.

Temporary and emergency sharing

For a short location handoff, a narrow owner-ended link can avoid permanent membership. Fi documents an accountless location link and a separate Search Party workflow for a missing pet. Tractive Public Sharing creates a Premium-gated link for people without an account. A public link should still be treated as a bearer link: send it only to intended recipients and end it when the task is over.

Tracker sharing patterns

The table uses the current Fi role, Fi location-link, Tractive family-sharing, and Tractive public-link records.

Table: Tracker sharing patterns. Swipe horizontally to see all columns.

Use a role for recurring access and an owner-ended narrow link for a temporary location task; neither path should require reusing the owner login.

Tracker access can affect location visibility, alerts, battery behavior, health data, settings, and billing. Do not reuse the owner login merely because multiple phones can sign in.

Camera sharing patterns

Current records document Petcube Family/Friend accounts, Furbo shared credentials, and Wyze Pan-family sharing.

Table: Camera sharing patterns. Swipe horizontally to see all columns.

For a camera, verify live view, audio, history, controls, scheduling, notifications, and individual revocation separately before granting access.

Camera sharing can expose live video, event history, audio, device controls, schedules, and household routines. The difference between “can watch” and “can change settings” belongs in the handoff.

Feeder sharing patterns

The reviewed records show a registered-email path for PETLIBRO sharing and a nickname-and-email path for PetSafe household members.

Table: Feeder sharing patterns. Swipe horizontally to see all columns.

An invitation path does not establish schedule, dispense, alert, or revocation permissions; verify them in the current app and retain a non-app feeding backup.

An invitation alone does not establish whether a helper can edit schedules, dispense food, change pet profiles, receive low-food alerts, or remove another user. Verify those fields in the current app and retain a non-app feeding backup.

Notifications and attribution

Separate identities matter when alerts depend on who has the pet or which phone is present. Fi explicitly warns that shared credentials can produce inaccurate attribution and alerts. Wyze documents independent notification controls for shared users on Cam Pan v3. For other products, notification ownership or delivery was not established here.

Revocation and offboarding

Revocation is a workflow, not a promise. Use the documented owner-side removal control where it exists, end public links, rotate a shared password when credentials were reused, and verify the person no longer sees the device or receives alerts.

Table: Offboarding checklist. Swipe horizontally to see all columns.

Removal is complete only after the owner ends links or accounts, rotates reused credentials, and verifies that visibility and notifications have stopped.

Privacy and account controls

Use multifactor authentication where the exact platform supports it, but do not send an unexpected verification code to someone who asks for it. Review trusted devices, recovery email access, cloud history, public links, and any shared credentials. Use the pet tech privacy and security checklist for the broader account review and the pet camera account-security workflow when a shared device includes household video or audio. Petcube’s retained policy has a 2021 effective date, and Furbo’s full policy text was not established in this bounded session, so neither record supports a broad privacy verdict.

Common failure modes

Before relying on remote access or alerts, use the pet tech connectivity matrix to identify the phone, account, network, cloud, subscription, and power dependencies that the intended job requires.

• The invite goes to the wrong email or phone number.
• A caregiver receives broader access than intended.
• A shared password remains known after the job ends.
• A public link is forwarded or left active.
• App, OS, permission, network, or subscription state prevents expected features.
• Removal appears complete but notifications, trusted devices, or another shared device remain.

Checklist before sharing

1. Choose the exact product and account owner.
2. Define the caregiver’s job and end date.
3. Use a separate account or narrow link when documented.
4. Review every visible role permission before accepting the invite.
5. Verify billing, profile, location, video, schedule, and history exposure.
6. Test notification preferences without relying on an emergency.
7. Record how the owner will remove access.
8. After removal, verify the device, history, alerts, and trusted-device list again.

What we could not verify

We did not establish every current app permission, invitation expiry, maximum member count, notification behavior, removal consequence, or caregiver self-exit path. We also did not test role enforcement, stream concurrency, link forwarding, billing exposure, or whether a removed account retained cached data. Keep those fields conditional until verified in the current app.

Method

We normalized seven current product ecosystems into separate fields for identity, shared credentials, roles, revocation, notification control, temporary links, visibility, settings, billing, and material unknowns. Five synthetic household scenarios produced thirty-five frozen outputs. The method returns documentation fit, conditional, stop, or not applicable. It has no score, rank, winner, price, or recommendation output.