Portal workflows

Staff access and roles #

Prerequisites: an administrator-provisioned staff account. Customers currently receive application keys but do not sign in. Documentation is public; organization, application, key, usage, audit and security screens require a portal session.

Local email/password authentication works offline. Optional Google Workspace login depends on deployment configuration and connectivity to Google. Optional TOTP works with a local authenticator. A temporary password must be replaced at first login. Sessions expire after eight hours without automatic renewal.

Provision an application #

• Create an organization for the customer/team.
• Create an application under it and choose development or production.
• Issue an API key with a label, optional expiry and required service scopes.
• Save the secret once and deliver it through your organization’s approved channel.
• Test a release request and each enabled service before giving the integration to users.

Expected result: the new key authorizes only its configured services. For offline builds grant packs and maps. Suspension applies to all keys below that organization/application. Rotation can revoke immediately or permit a bounded overlap; revocation prevents new server access but cannot erase maps already downloaded to devices.

Usage and audit history #

Usage shows request counts, transferred bytes, errors and new pack builds in hourly aggregates. Filter by organization, application or key and group by organization/application/key/service. Select a metric, then Apply. Results reflect the collector’s last ingestion; check freshness before concluding traffic is absent.

Usage API time ranges use UTC hour buckets, inclusive from and exclusive to, up to 90 days. Whole-hour boundaries give exact bucket selections. Lists/grouped results are capped at 1,000; audit loads 100 events per page with older-page navigation. These are operational metrics, not a billing ledger. Audit history records actor, action, target and safe metadata; it does not reveal issued secrets.

Passwords, TOTP and team access #

• Open Security to change/set a local password or enable an authenticator. Local security changes require the current password; linked Google-only accounts need recent authentication.
• When TOTP is enabled, security changes also require an unused authenticator/recovery code. Save the ten recovery codes when issued; each works once.
• Security changes can end sessions. Save new credentials/codes before signing in again.
• Administrators use Team access to provision staff, disable accounts, change roles, issue temporary password resets or reset another user’s TOTP.
• Role/access changes invalidate sessions; the last active administrator cannot be removed.

Keep host clocks accurate for TOTP. Password reset does not implicitly reset TOTP. If locked out, contact platform staff for the documented recovery process. Never share portal session cookies or Bearer JWTs with customer applications.

Management automation boundary #

Staff automation uses /admin/api/v1 on the portal origin, not the maps host. Authenticate with the local password/TOTP challenge flow to obtain a session Bearer JWT; there is no unattended refresh. Browser cookie mutations require same-origin JSON and X-CSRF-Token; script Bearer requests require JSON. Application keys cannot authenticate here.

This chapter describes user workflows. Full deployment and staff automation request details remain in the repository’s api-management operations guide; do not copy deployment secrets or recovery credentials into public documentation.