FAQ¶

Quick developer-focused answers. For sales/pricing-flavored questions, see the marketing FAQ.

Builds & uploads¶

What artifact formats are supported?¶

iOS: signed .ipa. AppGantry generates the install manifest for you.

Android support is on the roadmap.

How big can a build be?¶

The hard cap is 2 GB per artifact. If you're regularly uploading larger binaries, contact us. The limit has historically moved when there's a real use case behind the ask.

Can I retry a failed upload?¶

Yes. Uploads use direct-to-blob with a completion callback. If the callback never lands, the artifact is reaped within 24 hours and you can re-upload with the same metadata. No double-billing on the upload meter for failed attempts.

Do uploads block other API calls?¶

No. Uploads stream through the storage backend, not through our API server. You can read builds, manage testers, or upload to a different project simultaneously.

CI & project access tokens¶

How long does a project access token live?¶

Until you revoke it, or until the expiry you set at creation. We recommend a 90-180 day expiry for CI tokens so a forgotten one auto-dies.

Can one project access token cover multiple projects?¶

No. Each token is bound to one project (and its organization) when created. Create one token per project your CI pushes to. See Authorization → project access tokens for the rationale.

What if I commit a project access token to a repo?¶

Revoke it immediately from the project's Access tokens page, then create a replacement. The revocation lands in your audit feed as auth.project_access_token_revoked.

The ag_prj_ prefix is intentional: it's easy to scan for and easy to spot in logs, and it is distinct from the ag_pat_ prefix on personal tokens.

Where do I find my org ID and project ID?¶

In the web app, Org settings → Identifiers and Project settings → Identifiers. Both are UUIDs and are not secrets. Store them as repository variables, not as secrets.

Authentication¶

How long does a JWT last?¶

10 minutes. Use the refresh token to mint fresh access JWTs from POST /api/v1/login/refresh. Refresh tokens are single-use and the response always replaces your refresh token.

What if I refresh from two clients at once?¶

Each refresh consumes the refresh token. Whichever client refreshes second gets a 401. You'll need to log in again on that client. Server-side stickiness for parallel-tabbed apps is on the roadmap.

What happens when I log out?¶

Logout sets your developer's min-issued-at to now. Every JWT issued before that moment is rejected by every subsequent API call - so a single logout invalidates every outstanding session for your account everywhere.

My CI token works but my browser session keeps logging me out¶

Project access tokens and JWTs are independent. A logout from the web app doesn't affect a project access token. If your browser is being logged out unexpectedly, check whether you (or a teammate sharing the account) is logging out from elsewhere. Every logout invalidates every JWT for that developer.

Idempotency, retries, errors¶

Is it safe to retry a 5xx?¶

Yes if the response carries Retry-After (e.g. 503 storage_backend_unavailable). Those are explicit "transient, retry" signals.

For 500 internal_error, retry once with an Idempotency-Key header to be safe. If you don't set the header, retrying may double-do an action.

What happens if I retry with the same Idempotency-Key?¶

The server returns the original result without re-running the action. Use a fresh UUID per logical operation; reusing a key across logically distinct operations is undefined.

A 402 appeared but I thought I had credit left¶

Each in-flight upload/download briefly reserves its projected cost. A 402 can appear slightly before your displayed balance reaches zero because concurrent requests are counting against it. Reservations auto-release within ~30 minutes if the request never completes; top up or raise the cap to clear immediately.

Regions & residency¶

Where does hosted storage live?¶

Currently Azure East US (geo-redundant to a paired secondary region). If you need data in a specific region for compliance, BYOSA lets you pin the storage account anywhere Azure offers Blob Storage.

Is multi-region active-active supported?¶

Not on hosted. BYOSA puts that decision in your hands; pick whatever storage redundancy class fits your needs.

BYOSA¶

How long does BYOSA setup take?¶

Once you've admin-consented the app and granted the role, the flip itself is operator-mediated and usually happens within one business day. The Azure side takes ~15-30 minutes if it's your first time.

Can I migrate hosted → BYOSA mid-life?¶

Yes, but it's coordinated by support; the public API refuses to flip it directly. Existing builds have storage paths pointing at our container, so you'll either copy them over (support coordinates) or accept that their download URLs 404 after the flip.

Web app¶

Why are there two cookies?¶

dfdeveloper is your access JWT; dfdeveloper_refresh is your refresh token. The refresh cookie is path-scoped to /api/v1/login so it's only sent on refresh + logout, not on every API request, which limits the surface where it can be exfiltrated.

Can I delete my account?¶

Yes. Account settings → Delete account removes your developer record and revokes every PAT you own. If you're the last admin in an organization, you'll need to either transfer ownership or delete the org first; we don't orphan organizations.

I have a question that isn't here¶

Email us and we'll add the answer here.