Organizations

An organization owns its apps, its members and its bill. Its creator is the Owner, and everyone else joins by invitation or through single sign-on, with one of four roles. Where the plan includes them, its security settings bind every member and every token inside it.

Creating an organizationCopy Anchor Link

Create an organization in the console, with hotcodepush organization create or with POST /v1/organizations from a session. Its creator becomes the Owner, and you can create or join any number.

OwnershipCopy Anchor Link

Every organization has exactly one Owner, whose role changes only through a transfer. The Owner transfers it by setting another member's role to owner, whatever their current role: the Role setting on the Members page, or hotcodepush member update --role owner. The previous Owner becomes an Admin in the same step, and both are mailed.

The Owner cannot leave: leaving answers sole_owner until the ownership is transferred or the organization is deleted.

Deleting an organizationCopy Anchor Link

Only the Owner deletes an organization: Delete under Danger zone on its settings page, hotcodepush organization delete or DELETE /v1/organizations/{organizationId} from a session. It disappears for every member at once, and a Pay-as-you-go subscription ends at once rather than at the period's end.

Devices receive nothing new from that moment, though they keep running what they have, the fail-open guarantee. After 7 days it is hard-deleted with everything under it: apps, bundles and files, members, invitations, the SSO provider, webhooks and audit log rows. Until then, support can restore it, and a mail to the Owner names the date.

Members and invitationsCopy Anchor Link

Invitations are sent under Invitations in the console or with hotcodepush invitation create. The invited person opens the mail's link signed in with that address, or signs up from it, while another address answers forbidden. Accepting mails the inviter.

The Members page lists each member's role, whether they have a password and two-factor authentication, and when they were last seen. Owners and Admins set any role but owner on any member, Admins included, and remove members, while nobody changes or removes the Owner. Every member but the Owner leaves from their own row or with hotcodepush member delete.

Removal deletes the membership alone: the person's sessions and API tokens stay, but no longer reach the organization. A removed member is mailed, one who leaves is not, and a role change mails the member and the Owner.

RolesCopy Anchor Link

The table lists what the API lets each role do, and the console hides the pages a role cannot use.

Single sign-onCopy Anchor Link

Where the plan includes single sign-on, an organization connects one identity provider to one email domain. Until the domain is verified, nobody signs in through it. The hotcodepush sso-provider page lists the fields of each provider type.

Once verified, SSO is enforced on every member whose address is on the domain: password, GitHub and Google sign-ins answer sso_required. Such a member cannot set a password either. Members with an address on another domain keep their usual sign-in.

Anyone on the domain who signs in through the provider without being a member joins as a Member. A pending invitation counts as accepted and lends its role, Admin or Member, while a Billing invitation joins as Member. Joining stops at the members limit, and the new member, the Owner and the Admins are mailed.

Deleting the provider restores password sign-in for its members and forgets the domain. Removing a member is still what ends their access: sessions and tokens outlive the identity provider.

Two-factor requirementCopy Anchor Link

An Owner or Admin switches on Require two-factor authentication under Security on the settings page, or through the organization's update operation of the Swagger reference from a session. Where the plan does not include it, saving answers plan_required, and a setting saved earlier is not enforced.

From then on, every request inside the organization by a member without two-factor authentication answers two_factor_required, from a session or an API token. A CI token of such a member stops working in the organization the moment the switch is saved.

The console sends such a member to their account page to enable it, and they cannot disable it while they belong to the organization.

Network restrictionsCopy Anchor Link

Security also holds two allowlists, by IP address and by country, each behind its own switch, set and enforced where the plan includes them. With a list set, a request inside the organization from outside it answers ip_not_allowed or country_not_allowed, whatever the credential. A request whose address or country is unknown is refused too.

Your own account pages, the organization list and devices receiving updates are never restricted.

A switched-off list is saved as null, and null or an empty list restricts nothing. The API sets them through the organization's update operation of the Swagger reference, from a session. A list that would shut out your own current address or country is refused with validation. The sessions page shows the address and country each session signed in from.

Every change above is a row in the audit log, which Owners and Admins read where the plan includes it.