Feature availability¶
Not everything described in these docs is available to everyone, all the time. This page says plainly what's gated, what's assisted, and what may be missing from the interactive reference.
We'd rather tell you a feature is unavailable than let you find out from a confusing error.
Platforms¶
AppGantry distributes iOS and Android builds. The native in-app update SDK is a separate thing, and it is iOS-specific.
| Status | |
|---|---|
| iOS distribution | Available |
| Android distribution | Available |
| In-app updates SDK (Swift package) | Available, iOS only, early development |
| In-app updates SDK for Android | No library — call the /sdk/v1 HTTP API yourself |
Android is a supported distribution platform. If you find a page in these docs implying otherwise, it's a bug — please report it.
There is no Android (or Kotlin, Flutter, React Native, or Unity)
package for in-app updates. The /sdk/v1 HTTP surface the Swift package
calls is public, documented, and platform-neutral: seven operations you
can call from any HTTP client. See
SDK HTTP API.
The canonical platform-support table, including what each platform's install flow looks like, is SDK versioning & compatibility → Platform support.
Webhooks¶
Subscriptions, deliveries, the delivery log, secret rotation, and test deliveries all work, and every resource event in the catalogue is delivered.
| Status | |
|---|---|
| Creating and managing subscriptions | Available |
release.created, release.deleted, release.rolled_back, build.uploaded, build.deleted |
Delivered |
webhook.test |
Delivery-only — cannot be subscribed to; sent by Send test event |
| Delivery log, retries, dead-lettering | Available |
| Rotating the signing secret | Available |
| Documented signature construction | Available — HMAC-SHA256 recipe |
Fan-out is best-effort: it happens after the action commits and never blocks it, so an action can succeed with nothing delivered. Treat webhooks as a signal and the audit feed as the record.
Full detail is in Webhook events.
Store connections and store publishing¶
These are two different things, and only one of them works today.
| Status | |
|---|---|
| Creating a store connection | Available — credentials are validated against the provider when you save |
| Registering Apple test devices through a connection | Available |
| Publishing a build to App Store Connect | Not operational |
| Publishing a build to Google Play | Not operational |
| Publishing a build to Microsoft Intune | Not operational |
Publishing has not shipped. A publish request is still accepted and
still creates a publish job, but there is no working publisher behind it
for any provider, so every job ends failed and no artifact ever
reaches the provider. This is not a plan gate, an account setting,
or an environment difference — it is the same for everyone.
Because the job is created before it fails, a publish attempt looks superficially like it started working. It didn't. In particular:
- The store never saw your build. A failed job is not a rejection by Apple, Google, or Microsoft.
- Your credentials are not the problem. A connection that saved successfully was validated against the provider at that point. Rotating a working key in response to a failed publish costs you time and changes nothing.
- Publish store releases through the provider's own console directly — App Store Connect, the Google Play Console, or Intune — until this ships. AppGantry channels remain the working path for getting builds to testers.
Full detail, including the job status contract as it will behave once publishing ships, is in Store connections & publishing.
Plans¶
| Feature | Team | Business | Enterprise |
|---|---|---|---|
| Organizations, projects, builds | ✅ | ✅ | Not generally available |
| Channels, releases, testers | ✅ | ✅ | Not generally available |
| In-app updates SDK | ✅ | ✅ | Not generally available |
| Webhook subscriptions and deliveries | ✅ | ✅ | Not generally available |
| Store connections (credentials, Apple device registration) | ✅ | ✅ | Not generally available |
| Publishing builds to App Store Connect, Google Play or Intune | Not operational | Not operational | Not operational |
| Personal & project access tokens | ✅ | ✅ | Not generally available |
| Build retention | 30 days | 365 days | Not generally available |
| Audit retention | 90 days | 365 days | Not generally available |
| SAML SSO | — | ✅ | Not generally available |
| BYOSA | — | ✅ | Not generally available |
Enterprise is not generally available. It is not a plan you can buy or be quoted for today, so every Enterprise column above reads the same way: whatever an Enterprise tier eventually includes, it is not something you can have now. You can register interest and we will get in touch when it is available. Team and Business are the plans that exist.
Channels, SDK apps, webhooks, and store connections have no plan gate. If one of those isn't working for you, it isn't your plan. Store publishing has no plan gate either — it isn't working for anyone, on any plan. See Store connections and store publishing above.
SAML SSO is a Business capability. Configuring a connection,
claiming a domain, or enabling require-SSO on a Team organization is
refused with operation_not_allowed. Disabling SSO is always allowed,
so an organization that downgrades can still turn it off. See
Single sign-on.
See Plans & pricing.
Things that may be unavailable in your environment¶
Business may be marked "coming soon". Self-serve Business signup can be disabled, in which case the plan is shown as coming soon rather than being offered. Contact support if you need Business and can't select it.
Enterprise is not generally available. There is no self-serve signup, and it is not contact-led either: it is not something you can buy or be quoted for today. Register interest and we will let you know when it is available.
Online payment setup may be unavailable. In some environments the payment flow is disabled and you'll see a message saying so. Your organization can still be created and used according to its current state; get in touch to arrange activation.
BYOSA activation is assisted. You submit the request and AppGantry validates it automatically, but final activation involves us. It is not instantaneous, by design. See BYOSA setup.
Organization MFA policy and spend caps are API-level controls. Both exist and both work; neither has a dedicated screen in the web app today. Both are in the checked-in schema, so you can drive them yourself — organization Admin is required:
| Control | Read | Write |
|---|---|---|
| Spend cap | GET /api/v1/organizations/{organization_id}/spend-cap |
PUT /api/v1/organizations/{organization_id}/spend-cap |
| MFA policy | GET /api/v1/organizations/{organization_id}/mfa-policy |
PUT /api/v1/organizations/{organization_id}/mfa-policy |
Organization-wide personal access token cleanup is API-only too. A developer manages their own PATs from Account settings, but there is no admin screen for the organization's full inventory. An organization Admin drives it over the API:
| Control | Route |
|---|---|
| List every PAT in the organization, across all members | GET /api/v1/pats/all?organization_id={organization_id} |
| Revoke any one of them | DELETE /api/v1/pats/{pat_id}?organization_id={organization_id} |
Both are token-management operations, so they need an interactive sign-in: a personal or project access token is refused on them whatever its scope. This is the incident-response and leaver path — see Offboarding a member.
Changing an organization's plan is API-only, and it is the one that catches people out. There is no plan switcher anywhere in the web app: moving between Team and Business happens over the API, or by asking support.
| Control | Route | Who can call it |
|---|---|---|
| Move the organization between Team and Business | POST /api/v1/organizations/{organization_id}/tier |
Organization Admin, with a credential carrying the ALL scope |
Unlike the token-management routes above, this one does not require
an interactive sign-in: an admin's ALL-scoped personal access token is
accepted. The web app cannot mint such a token — its create form offers
one checkbox per named scope and the composite is deliberately not among
them — so that token has to be created over the API too.
An upgrade to Business on an organization with no card on file answers
checkout_required and leaves the tier unchanged, because Business's
higher monthly platform fee is charged in advance. See
Billing → Changing plans.
Request and response shapes are in the interactive reference. See Audit & spend caps and MFA, passkeys & sessions.
The interactive API reference¶
The interactive reference is generated from the service's own schema, which makes it the most reliable description of the operations it contains.
It now covers the areas this page used to list as missing. Organization creation, retrieval and deletion, the audit feeds, BYOSA and storage-backend management, and SAML SSO configuration are all in the checked-in schema. If you read otherwise on an older page, that page is wrong — please report it.
What is still not in the schema:
| Not in the schema | Read instead |
|---|---|
| Internal operator endpoints (approval, provisioning, support tooling) | Nothing — they aren't part of the customer API |
The audit CSV export used to be listed here. It was never an omission: the export is a download the web app generates from the published audit feeds, so there is no wire shape for the schema to describe. Its four columns are documented on that page.
The workflow guides remain the best starting point for each area even where the schema now describes the wire shape:
| Area | Guide |
|---|---|
| Organizations | Organizations & members |
| Audit | Audit events |
| BYOSA | BYOSA setup |
| SSO | Single sign-on |
| In-app updates over HTTP | SDK HTTP API |
We deliberately don't publish copy-pasteable request examples for operations missing from the checked-in schema. An example we can't verify is worse than no example — you'd debug our typo instead of your problem. Ask support and we'll give you a verified one.
Things we haven't published yet¶
Some details are omitted because publishing them would be misleading or would weaken the protection they provide:
- Exact rate-limit thresholds. Edge limits can change, so handle 429 and back off rather than tuning to a number. The application-level limits — invitation and tester-grant resends, data-export generation and download — are published, because knowing them is what stops you building a retry loop against them. See Rate limits.
- Internal operator endpoints. Approval, provisioning, and support tooling aren't part of the customer API and aren't documented.
Deprecations¶
The /api/v1 and /sdk/v1 surfaces are versioned in their paths.
Within a version, changes are additive: new fields may appear, existing
ones don't change meaning. Clients should ignore unknown fields.
Breaking changes will arrive as a new version path, with the previous version supported through a transition period. This matters most for the SDK, where shipped apps can't be patched from the server.
Behaviour you should not depend on¶
Some current behaviour is permissive rather than contractual, and may be tightened without being treated as a breaking change:
- A malformed pagination cursor currently restarts at the first page. Treat cursors as opaque and pass back exactly what you were given. See API conventions.
- Unknown query parameters are generally ignored. Don't rely on that to signal anything.
- Absence of
Retry-After. The schema advertises it on some 503 responses — the audit read timeout, and the transient storage-backend failure on upload initiate and build download — and 429 may carry one too. Don't assume every throttled or unavailable response does; implement a default backoff. The canonical list is Errors.
Reporting a gap¶
If these docs describe something you can't find, or your account can't do something we say it can, that's worth telling us about — the answer is either a bug in the docs, a gate we should have mentioned, or a bug in the product. All three are worth fixing.
Email support@appgantry.com, or use the pencil icon in the header of any page to propose an edit.