Skip to content

Glossary

A reference for AppGantry-specific terminology. If a term is used in the API or docs and isn't in here, it should be. Please let us know.

Account, developer, identity

  • Account / Developer: a person with a AppGantry login. One human ≈ one developer. Developers travel between organizations; the account is yours personally.
  • Identity token: the in-memory representation of a resolved authentication. Built from an access JWT, a PAT, a project access token, or an invite token; carries the developer id and email for developer-owned credentials, the scope and bound org for a PAT, or the bound project and capped role for a project access token.

Organization, project

  • Organization (org): the top-level billing and membership boundary. Every build, tester, and project lives inside one. Your invoice is per organization. Most teams have one; a consultancy might have one per client.
  • Project: an app you distribute. Each project belongs to one organization. The project name appears in install links and tester invitations.

Builds and distribution

  • Build: a single uploaded artifact (an .ipa) with metadata: version, platform, notes, upload timestamp. Each build has a unique identifier and a permanent install URL.
  • Channel: a named slot (e.g. Internal, Beta, Production) that holds a sequence of releases. Channels exist on Business.
  • Release: a build promoted to a channel. Testers subscribe to channels, not individual builds, so promoting a new release pushes it to the channel's subscribers automatically.
  • Tester: someone who installs your builds without a AppGantry account. Testers are identified by email; they receive an install link per build (or per channel, on Business).
  • Install link / invite token: a single-purpose URL that authenticates a tester for downloading a specific build or set of builds. The token in the URL path is the entire credential.

Storage

  • Hosted storage: AppGantry's storage account. Default on every plan; metered per-MB across upload, storage, and download.
  • BYOSA: Bring Your Own Storage Account. Available on Business (Enterprise coming soon). Build artifacts live in your Azure storage account and the per-MB meters are disabled for the org. See BYOSA concepts and the setup guide.
  • Container: in BYOSA, the single Azure Blob Storage container inside your storage account that holds all of the org's build artifacts. We don't write anywhere else in your account.

Billing & metering

  • Platform fee: the flat monthly fee per organization. $5 Team, $100 Business. Pre-paid on Team, post-paid on Business. Enterprise is coming soon.
  • Meter: one of the three usage counters: storage (MB-month), upload (MB), download (MB). Disabled for BYOSA orgs.
  • Billing period: a calendar month, UTC. Spend caps and budget alerts evaluate per billing period.
  • Spend cap: a configurable hard ceiling on metered usage for the billing period. Reaching it returns HTTP 402 on new uploads and downloads. See Audit & spend caps.
  • Pre-paid balance: the credit balance on a Team plan. Metered usage draws it down; at $0 the org's uploads and downloads return HTTP 402.
  • Reservation: when an upload or download is admitted, its projected cost is briefly reserved against your balance / cap so concurrent requests don't collectively overspend. Auto-releases within ~30 minutes if unused.

Authentication

  • Access JWT: a 10-minute RS256 token that carries developer identity. Browsers hold it as a cookie; programmatic clients use the Authorization: Bearer header.
  • Refresh token: a longer-lived token used to mint fresh access JWTs at POST /api/v1/login/refresh. Single-use; each refresh returns a new refresh token that replaces it.
  • Project access token: a long-lived, project-scoped credential with no human owner, granted a capped project role. Format ag_prj_<random>. The right credential for CI.
  • Personal access token (PAT): a long-lived credential bound to a developer + organization, with explicit scopes. Format ag_pat_<random>. Suits individual scripting and interactive tooling.
  • Min issued at: the per-developer timestamp before which every access JWT is rejected. A logout sets it to now, instantly invalidating every outstanding session.

Authorization

  • Role: a permission grant. Organization roles (READ, MANAGER, BILLING, ADMIN, etc.) and project roles (DOWNLOAD_BUILD, UPLOAD_BUILD, MANAGE_TESTERS, etc.) compose.
  • Scope: a permission grant on a PAT. Intersection with the underlying developer's roles: the request needs both to succeed.
  • Org-MANAGER fallback: the rule that an org-level MANAGER is treated as having full project access without per-project memberships.

Audit

  • Audit feed: the per-organization append-only log of state-changing actions. Day-paginated, retained per plan, with filters for event type, actor, and IP. See Audit & spend caps.
  • Audit event: a single row in the audit feed: type, actor, time, source IP, event-specific payload.

API mechanics

  • Cursor: opaque pagination token returned in next_cursor. Treat it as a black box; pass it back as ?cursor= to fetch the next page.
  • Idempotency key: a client-generated UUID passed in the Idempotency-Key header. Retrying with the same key returns the original result instead of repeating the action.
  • Cursor reset / first-page fallback: when a cursor is malformed or unparseable, the server returns the first page rather than an error.

Operations

  • Operator: a AppGantry staffer who handles operator-mediated workflows: BYOSA flips, billing overrides, account exports.
  • Diagnose: the on-demand BYOSA validation pipeline. POSTable to /api/v1/organizations/{id}/byosa/diagnose to re-run the setup-time checks against your current config.