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.
Changing your plan is API-only. There is no plan switcher
anywhere in the web app: the Billing screen shows your current plan and
manages payment, but nothing on it moves an organization between Team
and Business. That is done by calling
POST /api/v1/organizations/{organization_id}/tier, or by
asking support to do it for you. The
call needs the organization Admin role together with a credential
carrying the ALL scope;
an admin's ALL-scoped personal access token is accepted, so a plan
change can be scripted. An upgrade does not always take effect on the
call: an organization without a payment method on file is answered with
a card-capture step and stays on its current plan until that is done.
See
Billing, usage & caps.
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.
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.
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.