Organizations & members¶

An organization is the boundary for billing, membership, audit, and storage. Everything else lives inside one.

Creating an organization¶

The creation flow walks you through:

Name the organization.
Pick a plan. Team is the self-serve default. Business appears when it's enabled for your account; if you don't see it and you need SSO or BYOSA, contact us.
Choose how to start. On Team you can take a free trial, which needs no card and comes with usage caps and a time limit, or pay now, which activates immediately with a credit bonus.
Add a payment method, if you chose to pay now or when your trial ends.

A developer can belong to up to 5 organizations, and each can hold up to 50 projects.

Payment setup isn't available everywhere

In some environments online payment setup is switched off and the billing screens say so explicitly. That's a deployment property, not an error on your account. See Feature availability.

Roles¶

Canonical page

Authorization is the canonical owner of roles, scopes, and permissions. The table below is the working summary for the member list; if the two ever disagree, Authorization wins.

Role	Can
Read	See the organization, its projects, its members
Editor	The above, plus create and work in projects
Manager	The above, plus operate across every project in the organization, without needing a membership in each one
Admin	Everything, including members and invitations, billing, storage configuration, SSO, spend caps, audit, and deleting the organization

Roles are cumulative. Manager is the "works everywhere" role: a Manager has full project access without per-project memberships, which is what you want for release engineers and platform teams. That reach stops at the organization's own membership — inviting somebody, resending or revoking an invitation, listing the pending ones, changing a role, and removing a member are all Admin. A Manager reads the member list, as every member does, and administers nothing on it. Any member may also leave the organization, which is the one row on that list they can remove themselves. Admin is for the people who should be able to spend money, change how the organization authenticates, and decide who belongs to it.

Organization ownership is the Admin role, not a second thing on top of it, and an organization can have several Admins — see Ownership.

Pick the lowest role that works. See Authorization.

Inviting members¶

From Members → Invite, which is organization Admin work — as is everything else on a pending invitation:

Enter the email address.
Pick the role.
Send.

The invitation is valid for 14 days. The invitee gets an email; if they don't have an AppGantry account they create one first, and the invitation attaches on acceptance.

Pending invitations are listed separately from members, in a Pending invites section on the organization's (or project's) settings screen. The only control on a pending row is Cancel. There is no resend button in the web app: resending is API-only, and it issues a fresh token and a fresh 14-day window, which retires the link in the earlier email.

Over the API, resending one invitation is throttled to about once every 5 minutes, so nobody's inbox can be used as a weapon. Two responses are worth telling apart:

429 means the invitation exists and was sent too recently; the 5-minute window starts at the last send, including the original invitation. Wait and try again; nothing was sent.
404 means there is no pending invitation with that identifier — it never existed, it has already been accepted or revoked, or it expired and was swept. Those causes are deliberately indistinguishable from one another, so that the endpoint cannot be used to probe which invitations exist.

An expired invitation leaves the list before the row leaves the database. Once the 14 days are up it stops appearing in the pending list, because that list only shows invitations that have not expired. The row itself survives until an hourly background sweep deletes it, and until that sweep runs a resend over the API, by an invitation id you already have, still works: it issues a fresh token and a fresh 14-day window, which puts the invitation back in the list. The web app cannot do it — an expired invitation is not on the pending list, so there is no row to act on and no identifier to read off one. Once the sweep has deleted the row the resend answers 404, and "I invited them a month ago and they never clicked" is fixed by inviting them again.

Members are free. AppGantry bills for bytes, not seats, so don't share logins to save money — share logins and you lose the audit trail that tells you who did what.

Changing a role¶

From the member list, change a member's role in place. The change is immediate and applies to everything they hold, including every token they own: scopes intersect with the developer's own permissions, so demoting someone narrows their tokens at the same moment.

Every role change is recorded in the audit feed.

Removing a member¶

Removing a member revokes their access to the organization and every project inside it. Their AppGantry account continues to exist — it's theirs, not yours — and any organizations they belong to elsewhere are untouched.

Before removing someone, check what they owned:

Project access tokens keep working. They belong to the project, which is the point, but review them anyway.
Personal access tokens they created stop carrying authorization for this organization, because a PAT's rights are their owner's rights here. The token itself is not deleted and does not stop working everywhere: it stays listed for its owner, and any PAT they hold in another organization is untouched. Revoke it rather than relying on removal — the developer can, and so can an organization Admin over the API. See Offboarding → Revoke their personal access tokens.
Store connections and webhooks they set up keep working. Make sure someone else knows they exist.

Removal is one step of several, and one of them has to happen before you remove the membership: making sure another Admin remains, which is the same act as handing ownership on. Sessions, tokens, and shared secrets need clearing separately — work through Offboarding a member.

Ownership¶

Admin is the ownership role. There is no separate owner and no single-owner flag anywhere in AppGantry: an organization can hold as many Admins as it needs, and every one of them is a co-owner with the same reach over billing, storage configuration, SSO, spend caps, audit, membership, and deleting the organization.

Transfer ownership — the Ownership tab in organization settings, or POST /api/v1/organizations/{organization_id}/transfer-ownership — therefore grants Admin to somebody who is already a member. It is promote-only, and that is the part worth reading twice:

Your own role does not change. You are still an Admin afterwards. Stepping down is a separate act: change your own role, or leave.
The person must already be a member. Naming a non-member answers 404; invite them first.
Naming somebody who is already an Admin does nothing, and says so quietly: the call succeeds and ownership is unchanged. Naming yourself is refused.
Only an Admin can do it, like every other membership action here.

Because Admin is ownership, "make sure another Admin remains" and "hand ownership over" are the same job, done once.

Nothing can strand an organization without an Admin. The last-admin guard refuses to remove the final Admin, to demote them, and to let them leave, with 400 operation_not_allowed; the same refusal is what stops a sole Admin deleting their AppGantry account. So promote the successor before the leaver goes — not because ownership would otherwise be lost, but because the API will not let the last Admin out of the door until somebody else holds the role.

Projects inside an organization¶

Create a project with a name and a platform. The platform is fixed at creation: every build inherits it, and there is no way to change it afterwards. Pick carefully; if you get it wrong, create a new project.

A project has its own:

Settings: name, description, icon (PNG, JPEG, or WebP, up to 1 MiB).
Members and roles, granting access to this project only. This is how you give a contractor one app without giving them the organization.
Access tokens for CI.
Channels, testers, builds, releases, SDK apps, and store connections.

Project invitations work the same way as organization invitations, with the same 14-day window.

Deleting things¶

Deleting	Removes
A project	Its builds, channels, releases, testers, and tokens
An organization	Every project in it, and everything in those projects

Both are permanent and audit-logged. Export anything you need first — including the audit feed, which goes away with the organization.

Reviewing access¶

Worth doing quarterly:

Members. Does everyone listed still work here? Is anyone's role higher than their job needs?
Pending invitations. Cancel the ones you no longer want. Anything past its 14 days has already left the list on its own, and the hourly sweep deletes the row shortly after.
Project memberships. Contractors especially.
Testers and tester groups. See Managing testers.
Tokens. Project access tokens and personal access tokens, in every project.
Webhooks and store connections. Does each one still have an owner who knows what it does?

Troubleshooting¶

Symptom	Cause	What to do
Resending an invitation is refused with 429	It was sent — first time or re-sent — within the last ~5 minutes	Wait out the window. Nothing was sent, so the earlier email is still the live one
Resending is refused with 404	The invitation has already been accepted or revoked, it expired and was swept, or the identifier is wrong	Check the pending list. A missing, an accepted and a revoked invitation all answer the same 404 on purpose
The invitee says the link is dead, and the invitation is still in the pending list	It was re-sent, which rotates the token and retires the older email	Have them use the newest email
The invitee says the link is dead, and the invitation has gone from the pending list	The 14-day window elapsed, so the invitation dropped off the list	Invite them again. A resend can still revive it over the API if you kept its id and the hourly sweep has not deleted the row yet, but nothing in the web app can reach it
There is no resend button on a pending invitation	The web app offers Cancel only; resending is API-only	Use the API, or cancel and invite again
Business isn't in the plan picker	Self-serve Business signup is switched off for your account or environment	Contact us. See Feature availability
You can't find a plan switcher	There isn't one. The tier change is API-only	See Billing → Changing plans
A new member can see nothing	They have a role, but the screens they want need a higher one	Check the role table above and Authorization
The Ownership tab offers nobody to transfer to	Everybody else has left, or you are the organization's only member	Invite somebody first. The transfer grants Admin to a member who already belongs, so there has to be one
Transferring ownership is refused after you submit it	You are not an Admin	The form is shown to any member who can open settings, and the refusal comes from the API. Ask an Admin to run it
A removed member's personal access token still works elsewhere	Removal withdraws authorization here and does not delete the token	Revoke it — see Offboarding