Skip to main content
Settings → Team manages the developer accounts that can sign in to the developer portal.

​
Inviting a developer

Click Invite Member and enter an email address. Open Wearables creates the invitation and queues an email with a link to create the account. Invitation links expire after the number of days set in INVITATION_EXPIRE_DAYS (default 7).

​
Email delivery

Invitation emails are sent either through any SMTP server or through Resend. Without one of them, invitations are still created but no email goes out. If SMTP_HOST is set, SMTP is used; otherwise Resend. These variables apply to both:
  • EMAIL_FROM_ADDRESS - sender address. Your email provider has to accept it as a sender (for Resend, it must belong to a verified domain).
  • EMAIL_FROM_NAME - display name of the sender.
  • FRONTEND_URL - public URL of the developer portal. It is used to build the acceptance link inside the email, so with the default http://localhost:3000 the link only works on your machine.

​
SMTP

Works with any provider that offers SMTP: Google Workspace, Microsoft 365, Amazon SES, Mailgun, Postmark, SendGrid, your own relay, and so on.
  • SMTP_HOST - SMTP server hostname. Setting it switches delivery to SMTP.
  • SMTP_PORT - default 587.
  • SMTP_USERNAME, SMTP_PASSWORD - credentials. Leave both empty for a server that doesn’t require authentication, e.g. a relay that allows your server by IP address (a Postfix container next to the backend, a Microsoft 365 connector, Google Workspace SMTP relay).
  • SMTP_SECURITY - starttls (default, usually port 587), ssl for implicit TLS (usually port 465), or none for an unencrypted connection, e.g. a local Mailpit on port 1025. With none, SMTP_USERNAME and SMTP_PASSWORD must be empty: Open Wearables won’t send credentials over an unencrypted connection and skips sending with a warning instead. With starttls and ssl, the server certificate is verified.
Cloud email services:
Some hosting platforms block outbound SMTP ports, for example Railway on Free, Trial and Hobby plans and DigitalOcean Droplets by default. There, use Resend, which sends over HTTPS.

​
Resend

  • RESEND_API_KEY - API key from the Resend dashboard. For local testing you can set EMAIL_FROM_ADDRESS=onboarding@resend.dev, which Resend allows only for sending to your own account email.

​
Delivery and retries

Delivery is handled by a Celery task, so the worker must be running. Failed sends are retried up to EMAIL_MAX_RETRIES times (default 5), after which the invitation is marked failed and can be re-sent from the developer portal.
If neither SMTP_HOST nor RESEND_API_KEY is set, or EMAIL_FROM_ADDRESS or EMAIL_FROM_NAME is missing, the invitation stays pending and the backend logs a warning instead of sending. EMAIL_FROM_NAME defaults to “Open Wearables”. Use Copy invite link on the pending invitation and share the link manually.

​
Pending Invitations

Invitations that have not been accepted yet appear in a table with the email, sent date, expiry date, and delivery status. For each one you can:
  • Copy invite link - copy the acceptance URL to share it manually.
  • Resend invitation - generates a new link, extends the expiry, and sends the email again. The previous link stops working.
  • Revoke invitation - invalidate the link. The invitee can no longer join with it.

​
Developers

The Developers table lists every account with access to the deployment, with name, email, ID, and creation date. Copy ID copies the developer UUID, which is useful when reading audit fields such as the creator of an API key. Remove team member deletes the account. This cannot be undone.

​
Access model

Open Wearables has a single permission level for developer accounts.
  • Every developer account is an administrator of the deployment. There are no roles. All developers see the same settings and can perform the same actions.
  • There is no self-registration. The first account is seeded from ADMIN_EMAIL and ADMIN_PASSWORD on first startup. Every further account can only be created through an invitation sent by an existing developer.
  • Any developer can invite new team members, revoke pending invitations, and remove other developers.
  • API keys and SDK application credentials belong to the deployment, not to the developer who created them. See Credentials.
One developer managing keys, invitations, or team members created by another developer is the intended behavior of this model, not a vulnerability.