Partner service records and access

Partner service records use a dedicated partner identity, separate from DEV/LIVE keys, connector credentials, household sessions, and partner sessions. A connector cannot grant a technician access, approve a visit, impersonate a resident, or delete evidence. The platform checks current customer assignment, customer consent, exact-home scope, and local presence on protected operations. For developers, the useful model is: partner applications use the partner account flow, customer applications use the household session flow, and scopes are explicit {tenantId,clientId,propertyId} values that you must carry through each request rather than recover from cache or a previous screen.

Routes and identity boundaries

The published OpenAPI contract covers the service job, visit, report, and configuration routes. Partner routes are prefixed with /partners/{partnerTenantId}/service-jobs; customer routes use /home-support/service-jobs. Do not place bearer tokens in deep links or PDF URLs. Links carry identifiers, never credentials or visit approval. Receiving or opening a link does not authorize a mutation.

Access boundaries are narrower for households than for staff. DEV credentials act in the developer sandbox. LIVE credentials only act for their own installed connector. A connector credential still does not establish technician authority or resident authority.

Mutations, retries, and conflicts

Every mutation request uses a requestId that is a UUID stable only for retrying the exact submitted body. If the body changes, the retry identity changes too. Version conflicts require a refreshed view and a new user decision. Physical commands with unknown outcomes must not be automatically replayed. The platform keeps Requested, Succeeded, Failed, Denied, and Unknown distinct, so client code must preserve that difference instead of collapsing them into a generic pending or error state.

The platform records service identity; a provider-supplied actor or visit field cannot establish authorization. Report versions preserve the issued bytes, and customer acknowledgment is separate from invoice approval.

Reports, downloads, and files

PDF downloads are authenticated application/pdf responses with no-store and an attachment filename. Client code validates the response type, enforces the download size limit, and discards the file if the signed-in account changes before use. Temporary native files stay private and are deleted when their purpose ends.

If a client shares or prints a PDF, it uses the authenticated download and the same private temporary-file flow. The file is not a durable record unless the application creates one outside that temporary path.

Camera access

Receive-only service camera sessions need separate customer permission on every keepalive. They use the existing bounded camera session rather than a second background stream. A generic household camera transport is not a substitute for partner authorization. If the cloud path is unavailable, cloud-dependent connectors do not work; local functions can keep working during a cloud outage.

Practical client behavior

Native clients keep partner and household authentication separate. Partner job links resolve the intended workspace. Customer links resolve the intended home after sign-in. Cached job and report data should be namespaced by account, tenant, client, and home, and pending results should be discarded on account changes.

Unsupported installed versions must fail visibly or offer the authorized web workflow. TV is usage-only and has no partner commissioning workspace. Native source, simulator captures, or merged commits are not distributed-app or physical-visit acceptance receipts.

One-page checklist for integrations

• Use the correct route prefix for partner versus customer flows.
• Carry explicit {tenantId,clientId,propertyId} scope values on protected operations.
• Treat requestId as stable only for an exact-body retry.
• Refresh after version conflicts and ask the user again.
• Do not auto-replay physical commands with unknown outcomes.
• Keep Requested, Succeeded, Failed, Denied, and Unknown separate.
• Validate authenticated PDF responses and delete temporary files when done.
• Require fresh permission for each receive-only camera keepalive.
• Do not use deep links or PDF URLs for bearer tokens.
• Respect the access boundary: household permissions are narrower than staff, DEV acts in the sandbox, and LIVE only covers the installed connector’s own scope.