Authentication & Access

Credentials

There are two distinct credential domains in the platform, and it's important not to conflate them:

	Device credentials	Your application's credentials
Who holds them	Each physical CoppelBox unit	Your integration / application
Type	X.509 client certificate (mutual TLS)	Cognito user account → ID token
Used for	The device's own MQTT connection to AWS IoT Core	Signing in to the platform's GraphQL API (AppSync)
Issued by	Fleet provisioning at manufacture / first boot	An administrator, via the Users screen (invite-only — there is no self-registration)

Device certificates are not something you, as an integrator, are issued. They belong to the physical unit and are rotated automatically by the cloud on a schedule. If your integration needs to read device data, the supported path is a platform user account authenticating against the GraphQL API:

1. Sign in to Cognito with your account's email and password (USER_SRP_AUTH or USER_PASSWORD_AUTH).
2. Cognito returns an ID token (valid 1 hour, silently refreshable).
3. Send that ID token in the Authorization header on every AppSync request (HTTPS for queries/mutations, in the connection payload for WebSocket subscriptions).

What that account can see and do is governed by two things, both enforced server-side — supplying different arguments in a request cannot override either:

• Role — viewer (read-only) → editor (+ send commands) → admin (+ device/user/org management) → super-user (unrestricted, cross-org). Set by an administrator.
• Reach — which organisation(s) your account can see data for: a single org, an explicit allocated-orgs list, or (super-user only) everything in the deployment.

IoT policy

Devices are not free to publish or subscribe wherever they like on the broker. Each device's AWS IoT policy is scoped, using policy variables tied to its certificate identity, to only its own topics (/cbox/{its-own-deviceId}/...) — one device cannot see or affect another device's traffic even though they share the same broker.

Your application does not get a comparable direct IoT Core policy. Browser and server-side application code has no direct AWS IoT Core access — all publish and subscribe operations from an application go through the AppSync API, which enforces the role/reach model above before ever touching IoT Core (for example, sending a command goes through the publishDeviceCommand resolver, which authorises the request server-side and then publishes to /cbox/{deviceId}/command on your behalf).

Rate limits

The following limits are explicitly documented for the device/broker side of the platform:

What	Limit
Status packet (heartbeat) cadence	Fixed at 20 seconds — not configurable per-integration
Alert resend	60 seconds (critical priority) / 300 seconds (high, medium, low) while unacknowledged
MQTT commands to a device	No hard rate limit enforced, but the platform's own guidance is to avoid flooding a device with commands
Factory provisioning API (provision-bundle, jig-only)	10 requests/second, 10,000 requests/day — not applicable to data-integration use cases