Skip to content

API surface map

This page is the human-readable map of AppGantry's public HTTP surfaces. Use it to find the right resource family; use the interactive API reference for exact parameters, request bodies, responses, and per-operation authorization.

Base URLs

Surface Production base Purpose
Customer API https://api.appgantry.com/api/v1 Authenticated account, organization, project, build, release, and automation operations
Public install API https://api.appgantry.com/public/v1 Unauthenticated or capability-token install and device-enrollment flows
In-app update API https://api.appgantry.com/sdk/v1 SDK enrollment, token refresh, update checks, downloads, and install reports

Internal operator endpoints are not part of the customer API and are not documented.

Before choosing an operation

  1. Pick the surface from the table above.
  2. Pick the resource family below.
  3. Check the operation's authentication and role requirements in the interactive reference.
  4. Follow API conventions for envelopes, pagination, uploads, retries, and parent scoping.

Do not infer a universal URL shape. Some project operations use a project identifier plus an organization_id query parameter; others are nested below an organization. Follow the individual operation.

Resource families

Each heading below matches a tag in the published OpenAPI schema. Most families belong to the customer API; the two that do not are annotated in place — Public covers /public/v1 and SDK covers /sdk/v1.

Audit

Read an organization's audit trail, or the calling developer's own. Both answer a single UTC day by default and accept a date range for export, each with its own event cap; a truncated result is flagged with the X-Audit-Truncated response header. The organization feed is Admin-only and masks operator-sensitive values; the per-developer feed is self-only and needs an interactive sign-in. See Audit events.

Builds

List and read builds, initiate and complete the two-phase upload, download an artifact, edit a build's release notes after upload, revoke a build, or permanently delete it. Release notes are the only editable field: everything else about a build is fixed from initiate time onward. Start with Uploading a build.

Channels

List, create, read, edit, and delete channels; inspect channel analytics; and manage direct channel testers and short-lived channel tester invitations.

Developers

Create and read an account, edit the profile, manage the avatar and email address, verify email, request or complete password reset, request and download a personal data export, and schedule or cancel deletion.

Devices

List and remove enrolled Apple devices and mint a device-enrollment flow. The related public operations serve the enrollment landing page, configuration profile, and callback.

Feature Flags

Read the effective feature-flag set for an organization. This is a diagnostic description of what the deployment and the account enable, not a customer endpoint for changing flags: there is no write operation on this surface. Read it when a screen or capability is missing and you need to tell "off here" from "broken".

The response body has two properties, both always present: organization_id, which echoes the organization you asked about, and flags. flags is a flat {flag_key: boolean} map of the flags that are active, with any organization-specific setting already applied. Two keys are published today:

Flag key Default What it gates
new_org_signups_enabled On Whether new organizations can be created at all. It is a kill switch, so a platform-wide off cannot be re-enabled for one organization.
beta_dashboard Off A dark-launch gate for an in-development dashboard, switched on per organization while it is being rolled out.

Three properties matter when you read flags:

  • Archived flags are omitted. A flag that has been retired stops appearing rather than flipping to false.
  • A key you do not see is off. Treat an absent key as false rather than as an error, so a flag added or retired later does not break your client.
  • The key set is closed and the names are stable. They are declared in code, not invented per organization.

The environment gates these docs describe elsewhere — self-serve Business signup, online payment setup — are deployment configuration rather than entries in this map. See Feature availability.

Login

Sign in with email/password, complete MFA, sign in with a passkey, refresh or revoke a session, and exchange an SSO handoff code.

MFA

Read MFA status; begin and confirm TOTP enrollment; regenerate recovery codes; and disable MFA.

Miscellaneous

Read service metadata and platform version information, obtain a captcha challenge, and preview or accept organization/project invitations.

Organizations

List the organizations you belong to, create one, then read, rename, or delete it. Manage the organization icon, members, invitations, ownership, tier changes, leaving, payment setup, prepaid credit, usage, usage estimates and events, spend caps, MFA policy, organization testers, and tester groups. Organization tester operations include a per-tester read that returns one active tester's direct grant alongside the tester groups they belong to.

SAML SSO configuration and storage-backend (BYOSA) management are also in this family, because both are organization-scoped:

  • SSO — read, create or replace, and delete the SAML connection; enable or disable it; enforce require-SSO; claim and verify email domains; fetch the service-provider metadata; plus the browser-facing login, assertion-consumer, logout and Single Logout endpoints. Configuring SSO is a Business capability. See Single sign-on.
  • BYOSA — read the organization's storage backend, submit or withdraw an onboarding request, read its status, and re-run the storage validation checks on demand. See BYOSA setup.

The configuration operations in both groups require an interactive sign-in: a personal or project access token is refused whatever its scope. Three SSO endpoints are the deliberate exception — the sign-in redirect, the assertion-consumer callback and the Single Logout service the identity provider calls back on carry no AppGantry credential at all, because nothing has signed in by the time they are reached. Beginning SP-initiated Single Logout is a signed-in call and is not one of them.

Passkeys

List passkeys, begin and finish registration, rename a passkey, or delete it. Passwordless and MFA passkey sign-in live under Login.

PATs

Create and list personal access tokens, discover grantable scopes, rotate, revoke, and permanently delete a token. Organization Admins can also list every PAT in an organization and revoke one during offboarding.

Platforms

List the platform identifiers accepted when creating projects and uploading builds. This operation requires no authentication.

Project Access Tokens

Create and list project-bound automation tokens, then rotate, revoke, or permanently delete them. See CI uploads.

Projects

List, create, read, update, and delete projects; manage project icons, members, invitations, and project-level testers, including a per-tester read that returns one active tester's direct project grant alongside the tester groups they belong to. The schema contains both organization-nested and project-addressed forms where the service supports both.

Public

Read the current release of a public channel and obtain public or capability-token downloads and iOS install manifests. These operations live on the /public/v1 surface and do not accept a normal developer session.

Publish

Create and inspect store-publish jobs.

Publishing is not operational

A job can be created, but every provider job fails before an artifact reaches the store. See Store connections & publishing.

Releases

Create, list, and read releases; find current releases; inspect analytics and install status; mark a release mandatory or optional; disable, enable, roll back, or delete it.

SDK

Enroll an app install and mint its update token, rotate that token, fetch app display metadata, check for the latest release, download it, obtain the iOS install manifest, and report install state. Seven operations, all on the /sdk/v1 surface. No developer credential is sent here — not a JWT, not a personal or project access token — but the surface is not open either: every operation except enrollment and the iOS manifest carries the per-install update token that enrollment mints. See the SDK HTTP API for the wire-level flow and the SDK documentation for the Swift package.

SDK Apps

Create, list, and revoke the app credentials that connect a channel to the in-app updates SDK. These are customer API operations; the installs they enroll then talk to /sdk/v1.

Sessions

List active sessions, revoke one session, or revoke all sessions. Long-lived access tokens are refused on this account-security surface.

Store Connections

Create, list, read, update, and delete provider connections and register Apple test devices through a connection. Secret credentials are write-only and are not returned after creation.

Testers

Preview and accept channel tester invitations; list the organizations, projects, channels, and releases available to the signed-in tester; manage per-channel email preferences; and mint platform-specific install links.

Webhooks

Create, list, read, update, and delete subscriptions; list delivery attempts; send a test delivery; and rotate the signing secret. All five resource events are delivered; webhook.test is delivery-only and cannot be subscribed to. See Webhook events.

Operations missing from OpenAPI

The checked-in schema now covers organization creation, retrieval and deletion, the audit feeds, BYOSA and storage-backend management, and SAML SSO configuration. Those are no longer omissions — earlier versions of this page said they were, and that was wrong.

What is not in the schema is the internal operator endpoints (approval, provisioning, and support tooling), which are not part of the customer API at all.

The audit CSV export used to be listed here too, and that was a category error rather than an omission: it is a download the web app generates from the published audit feeds, not a REST operation that was left out. There is no wire shape for it to describe.

Feature availability → The interactive API reference carries the same list. Contact support before building automation that depends on a wire shape no published schema describes.

Credentials by surface

Authentication → Credential types is the canonical table of credentials, what each one is for, and how it is carried.

Some sensitive account, organization and token-management operations require an interactive access JWT and reject PATs and project access tokens with 403. The categories are listed in Authentication → Where long-lived tokens are refused; Authorization explains why each one is drawn where it is.

Rate limiting and 429

No operation in the published schema declares a 429 response, and that is a gap in the schema rather than a promise: throttling is applied both at the edge and inside the application, so any operation can answer 429. Handle it by status class rather than by looking it up per operation. See Rate limits.

Common automation paths

Goal Operations
Upload from CI POST /api/v1/builds/initiate → storage PUTPOST /api/v1/builds/{pending_upload_id}/complete
Promote a build Create a release under Releases, then manage mandatory/enable/rollback state there
Maintain tester access Use organization/project tester operations, channel tester operations, or tester groups
Receive changes Create a Webhook, store the one-time secret, then monitor Webhook deliveries
Run an in-app update client Create an SDK App, enroll through /sdk/v1, then check and report updates — see the SDK HTTP API
Investigate access Read roles and token grants, then read the organization audit feed under Audit

Schema and compatibility

The raw schema is available at /api/openapi.json. The interactive reference is generated from that same committed document.

The /api/v1, /public/v1, and /sdk/v1 version segments are part of the contract. Within a version, clients must tolerate additive fields and ignore fields they do not recognize. Breaking changes use a new versioned path.

See also

  • API conventions: the rules that apply across every operation on every surface.
  • Authentication: the credential each surface accepts, and how long it lasts.
  • Authorization: the roles and scopes an operation checks once it knows who you are.
  • Errors: the envelope and the code catalogue every one of these families answers with.
  • Web app feature guide: the same capabilities as screens, and the handful that exist on only one surface.
  • Interactive API reference: exact parameters, bodies, and responses per operation.