---
name: box-oauth-app
description: Creates or signs in to a Box developer account and registers a Box Platform App with User Authentication (OAuth 2.0) to obtain a client ID and client secret — with exact-match redirect URIs, console-selected scopes, the enterprise admin app-authorization gate, single-use rotating refresh tokens, and a safe credential handoff. Use when asked to get Box OAuth credentials, create a Box app or Platform App, set up a Box developer account or sandbox, rotate a Box client secret, add scopes to a Box app, or fix a Box authorization error like `redirect_uri_mismatch`, `redirect_uri_missing`, "Disabled by Administrator", or a customer whose Box connection dies after a quiet month. For any other vendor's developer portal, use that vendor's skill instead.
---

# Box OAuth2 App Registration

Get a working Box OAuth2 client — a developer account, a Platform App configured for **User Authentication
(OAuth 2.0)**, redirect URIs, scopes, client ID and client secret — for a platform that connects many customers' Box
accounts on their behalf.

Three things are expensive to get wrong here, and only one of them is in the app form. First, **the app type is
permanent**: a User app cannot be converted to a Server app, or the reverse, so picking the wrong authentication
method means starting over with a new client ID. Second, **a customer's own Box admin may have to authorize your app
inside their Admin Console before any user in that enterprise can connect** — this is the classic Box trap, it is
customer-side, and no amount of re-registering fixes it (§4). Third, **Box refresh tokens are single-use**: every
refresh returns a *new* refresh token and invalidates the old one, so a client that stores the original will work
exactly once and then break (§8).

## Inputs to collect before you start

Ask in one batch. Never invent.

| Input | Notes |
| --- | --- |
| **App name**, description, contact email | Shown to users on the Box consent screen |
| **Which Box account owns the app** | A free developer account, or an existing Box enterprise (§2) |
| **Is the owning account an enterprise?** | Decides whether you can self-authorize or must ask an admin (§4) |
| **Redirect URIs** | Every callback host your platform serves (§5) |
| **Scope set** | What the connector actually calls (§6) |
| **Does the client store the rotated refresh token on every refresh?** | Blocking — see §8 |
| **New app, or an edit to an existing one?** | Decides §1 |
| **Will this be listed in Box Integrations?** | Separate review path (§9) |

## Quick Start

1. Confirm a **new app** is needed — existing customer connections are bound to the current client ID (§1).
2. Sign in to, or create, the Box account that will own the app (§2).
3. Developer Console → **New App** → app type **User** → **Create** (§3).
4. Understand who must authorize the app in each customer enterprise — do this before you promise a launch date (§4).
5. Add **every** redirect URI, exactly (§5).
6. Select the console scopes the connector actually calls, and no more (§6).
7. Copy the client ID and client secret from the Configuration tab (§7).
8. Confirm the client stores rotated refresh tokens and refreshes inside 60 days (§8).
9. Verify with a real authorize → callback → refresh → refresh-again round trip on a *second* account (§10).
10. Hand the credentials over — never commit them (§11).

## Platform state (verified 2026-09-20 — re-verify before trusting)

- Apps are created in the **Box Developer Console** at `https://app.box.com/developers/console`. The flow is
  **New App → choose app type → Create**. The two app types are **User** (users sign in with their own Box accounts —
  this is OAuth 2.0) and **Server** (backend services — Client Credentials Grant or JWT).
- **A customer-authorizes-us connector needs a User app with OAuth 2.0.** CCG and JWT authenticate the *application*
  against a single enterprise using credentials you hold; they do not produce a per-customer consent flow, and they
  require an explicit Box Admin authorization in every enterprise before they work at all. Do not reach for them
  because the OAuth flow looks like more work.
- **The choice is permanent.** Box's own wording: "You can't convert a User app into a Server app, or a Server app
  into a User app. To move between them, create a new app."
- **Authorization differs by account type.** On a **free developer account**, apps are authorized automatically at
  creation. In an **enterprise**, JWT/CCG apps must be authorized by a Box Admin or Co-Admin, and **unpublished
  OAuth 2.0 apps also require enablement by an admin if the enterprise has "Disable unpublished apps by default"
  turned on**. See §4 — this applies to *your customers' enterprises*, not just yours.
- Redirect URIs have required strict exact matching for OAuth 2.0 apps created since **29 November 2021**, and
  multiple URIs per app are supported.
- Token lifetimes: authorization code **30 seconds**, access token **60 minutes**, refresh token **60 days or one
  use**, whichever comes first.
- An enterprise can authorize up to **10,000** custom apps before it has to ask Box Support for an increase.
- Listing in **Box Integrations** (the directory at `https://app.box.com/services`, formerly called App Center) is a
  separate Box Partner review, submitted from the app's **Publishing** tab, and it only accepts OAuth 2.0 apps (§9).

If the Developer Console does not look like this, stop and report what you actually see rather than clicking on.

## 1. Decide: reuse the existing app, or register a new one

A new app means a **new client ID, and every existing customer connection is bound to the old one** — every customer
would have to re-authorize, and in enterprises that gate apps, every customer's admin would have to authorize the new
client ID too (§4). That is a migration project, not a config change.

Reuse the existing app for: adding a redirect URI, adding a scope, rotating a compromised secret, or diagnosing an
authorization failure. Note that **adding a scope is not free either** — changing an app's scopes requires
re-authorization in every enterprise that authorized it (§4, §6).

Register a **new** app only when the user explicitly wants one: a first-time setup, a replacement for a compromised
app, a separate app for a different product, or a deliberate move off a Server app. Say which path you are taking
before you touch the console.

## 2. Account: sign in or sign up

- **Free developer account** — sign up at `https://account.box.com/signup/n/developer`. This is the simplest home for
  an integration's OAuth app when you do not already have a Box enterprise. Apps created here are authorized
  automatically, which conveniently hides the §4 problem from you and not from your customers.
- **An existing Box enterprise** — normal for an established platform. You need Developer Console access; if you are
  not an Admin or Co-Admin you will have to submit the app for approval rather than self-authorize (§4).
- **Developer sandbox** — a separate Box enterprise with its own Enterprise ID, created by an enterprise **admin or
  co-admin** from the Admin Console; up to ten per customer, no expiry, and it starts empty rather than inheriting
  parent settings. This is the right place to reproduce the enterprise authorization gate before a customer hits it.
  Sandbox API calls count against the normal allocation.

Hand control back to the user for anything only a human can do: signup email verification, 2FA enrollment, accepting
terms, or an admin action inside a Box Admin Console you do not control. Do not retry a blocked step in a loop.

**If this session has no browser automation** (the usual case for a CLI or cloud run), do not pretend to click and do
not describe a screen you have not seen. Hand the user an exact, ordered click path with the literal values to paste
(§5 redirect URIs, §6 scope list), then continue once they report back with the client ID.

## 3. Create the app and pick the authentication method

1. Log in to Box and open the **Developer Console** (`https://app.box.com/developers/console`).
2. Select **New App**.
3. Select **User** as the app type — this is the User Authentication (OAuth 2.0) path. Do **not** select **Server**.
4. Select **Create**.

Box asks server apps to choose between Client Credentials Grant and JWT; a User app has no such choice, because
OAuth 2.0 is the method. Reference of what you are declining:

| Method | App type | What it is | Fits a customer-authorizes-us connector? |
| --- | --- | --- | --- |
| **OAuth 2.0** | User | Customer signs in to Box and grants your app access; token represents that user | **Yes** |
| **Client Credentials Grant** | Server | App authenticates itself with client ID + secret; unattended; Service Account and App Users | No — no per-customer consent, needs admin authorization in every enterprise |
| **JWT** | Server | Same as CCG but the app signs assertions with a keypair | No — same reason, plus key management |

After creation, the settings screen exposes the fields that matter: **App Name**, **Description**, **Contact Email**,
a **Purpose** selector (pick the one that describes an integration and say whether it is built by a customer or a
partner — an admin reading an authorization request sees this), **Authentication Method**, **Application Scopes**
(§6), **CORS Domains**, and **Advanced Features**. CORS domains only matter if browser JavaScript calls the Box API
directly; a server-side connector can skip that section entirely.

A **Developer Token** is generated automatically. It is a short-lived token for your own poking around — it is not
part of the customer flow, and it is a credential. Do not paste it anywhere durable.

## 4. Enterprise app authorization — the thing that blocks customers

This is the section that decides whether customers can actually connect, and almost none of it happens in your
account.

**The shape of it.** Box lets each enterprise decide whether *published* and *unpublished* platform apps are enabled
by default for its users. Your app, until it is listed in Box Integrations (§9), is **unpublished**. If a customer's
enterprise has **"Disable unpublished apps by default"** turned on, then a Box Admin or Co-Admin in *that* enterprise
must explicitly enable your app by **client ID** before any of their users can complete the OAuth flow. Box's own
authorization guide puts it plainly: unpublished OAuth 2.0 apps "may require enablement by a Box Admin or Co-Admin if
they are inactive by default."

**Who does it, and where.** The customer's admin, in *their* Admin Console:

1. Admin Console → **Platform** in the left navigation (`https://app.box.com/master/settings/custom`).
2. **Platform Apps** tab → **User Authentication Apps**.
3. **Add +** in the top-right, and paste **your app's client ID**.
4. Review the scopes the app requests, then enable it. (Or hover the app's row → **...** → authorize and enable.)

So the only thing you can hand a customer is **the client ID and a plain-language justification of each scope**. Box
shows the admin the scope names and nothing about your use case — the developer is expected to justify them. Write
that justification once, keep it with the credentials, and give it to every customer whose admin asks.

**Your own account.** In the Developer Console, the **Configuration** tab prompts an enterprise developer to submit
the app for admin approval, and prompts an enterprise Admin/Co-Admin to authorize it directly. User-authentication
apps also have an **Enablement** tab, which sends an approval request by email to the enterprise's Primary Admin;
both the developer and the admin get an email with the decision. On a free developer account this is automatic — which
is exactly why testing only there proves nothing about customers (§10).

**Re-authorization after changes.** Authorization is a snapshot in time. **When an app's scopes or access level
change, the app must be re-authorized for the change to take effect** — per enterprise. Free developer accounts
re-authorize automatically on save; enterprise developers must re-submit; admins can re-authorize from Admin Console
→ Platform → the app's menu → **Reauthorize App**. Practically: adding a scope to a live connector means going back
to every gated customer. Plan the scope set once (§6) rather than growing it.

**Caps and known errors.** A new enterprise can authorize up to **10,000** custom apps; beyond that the customer
contacts Box Support. Three errors show up on the admin side and are worth naming when you help a customer: *"Unable
to retrieve service of enterprise app authorization"* means the pasted client ID is wrong or carries trailing
characters; *"Something went wrong with adding the app authorization"* means the co-admin has view-but-not-edit rights
on enterprise settings; *"Disabled by Administrator"* means the authorization requirements are not all satisfied.

## 5. Redirect URIs

Set these under **OAuth 2.0 Redirect URI** on the app's **Configuration** tab. Register **every** callback host your
platform serves. For Unified.to these are one per data center; confirm the current list with the platform owner
rather than assuming:

```
https://api.unified.to/oauth/code          # us (default)
https://api-eu.unified.to/oauth/code       # eu
https://api-au.unified.to/oauth/code       # au
https://api-dev.unified.to/oauth/code      # dev
```

The rules, exactly as Box enforces them:

- **Exact match.** No subdirectory matching, no trailing-slash forgiveness. A mismatch shows the user a
  `redirect_uri_mismatch` error page instead of the grant screen.
- **HTTPS required**, except plain HTTP for `localhost` or a loopback address. Localhost and loopback may redirect to
  any port, but scheme, domain, path and query parameters must still match a configured URI.
- **Multiple URIs are allowed**, and duplicates cannot be saved.
- **With more than one URI configured, the authorize URL must carry a `redirect_uri` parameter** matching one of
  them. Omit it and the user sees `redirect_uri_missing` — *after* granting access, so the consent looks like it
  worked and the connection still fails. A single-URI app can omit the parameter; a multi-data-center platform never
  can. Send it always.
- Use the current authorization host, `https://account.box.com/api/oauth2/authorize`. Apps built before March 2016
  used a legacy host that does not redirect Box Verified Enterprise customers to their own subdomain.

## 6. Scopes

Scopes are chosen in the Developer Console under **Application Scopes**, not requested freely at runtime. The
authorize URL's `scope` parameter is space-separated and **defaults to every scope configured for the app**; sending
it can only narrow the set, never widen it. Anything not ticked in the console is unavailable no matter what the
authorize URL asks for.

Scopes cap a token; they never exceed what the authorizing user may do. An app with write scope does not get access
to content the user cannot reach, and a call outside the app's scopes returns **403** even when the user owns the
object.

The self-service console scopes most relevant to a content connector:

| Scope | Grants |
| --- | --- |
| `root_readonly` | Read all files and folders the authenticated user can reach |
| `root_readwrite` | Read *and* write files and folders — upload, download, create folders, update collaborations, comments, tasks |
| `manage_webhook` | Create and manage webhooks (limit 1000 webhooks per application, per user) |
| `manage_enterprise_properties` | Enterprise event streams, enterprise attributes, reports, device pins |
| `manage_managed_users` | Manage managed users — logins, password resets, role assignment |
| `manage_groups` | Create, update, delete groups and memberships |
| `manage_app_users` | Manage App User accounts — Box documents this as **server-side JWT applications only** |

Other scopes exist (`manage_data_retention`, `sign_requests.readwrite`, `ai.readwrite`, `manage_triggers`, and
request-only ones such as `manage_legal_holds` and `enterprise_content`). Do not tick anything the connector does not
call: every scope is something a customer's admin reads before enabling the app, and `root_readwrite` plus user
management is a combination security teams push back on.

**Product fact — confirm before relying on it.** As of 2026-09-20, Unified.to's Box connector requests, by capability:
`root_readwrite` for both reading and writing storage files; `root_readonly`, `root_readwrite`,
`manage_enterprise_properties` and `manage_webhook` for webhook support; and `manage_app_users` for reading HRIS
employees (carrying an open question about whether `manage_managed_users` is also needed). It authorizes against
`https://account.box.com/api/oauth2/authorize` with a space-delimited `scope` parameter plus `client_id`,
`redirect_uri`, `response_type` and `state`; exchanges and refreshes at `https://api.box.com/oauth2/token` as a
form-encoded POST with `client_id` and `client_secret` in the body; calls the API at `https://api.box.com/2.0` with a
bearer token; **does not use PKCE**; treats access tokens as ~60-minute and refresh tokens as just under 60 days; and
ships with Unified.to-owned shared OAuth credentials available as a default. Two of these deserve a question rather
than a copy-paste: requesting `root_readwrite` for read-only use removes the customer's option to grant read-only,
and `manage_app_users` is documented by Box as a JWT-app scope. **Confirm the current scope set and these two points
with the connector's owner before ticking boxes in the console.**

## 7. Capture the credentials

On the app's **Configuration** tab, in the OAuth 2.0 credentials section, copy:

- **Client ID** (the OAuth `client_id`) — also what every customer's admin needs in §4, so it is not a secret, but it
  is worth recording precisely. The Developer Console has a copy button; a hand-typed client ID with a trailing
  character is a real and common failure.
- **Client secret** (`client_secret`).
- Endpoints in play: authorize `https://account.box.com/api/oauth2/authorize`, token and refresh
  `https://api.box.com/oauth2/token`, API base `https://api.box.com/2.0`.
- Whether the owning account is a free developer account, a sandbox, or a production enterprise — a sandbox is a
  *different* enterprise, so its client ID is a different app.

Rotating the client secret invalidates the old one. Existing access tokens live out their hour, but every code
exchange and every refresh fails until the new secret is deployed — and because Box refresh tokens are single-use
(§8), a failed refresh window can burn connections rather than just pausing them. Never rotate without explicit
go-ahead and a cutover plan.

Report the secret once so the user can paste it into their secret store, say plainly that it is now in the transcript
and can be rotated, then move on.

## 8. Token lifetimes and single-use refresh rotation

| Thing | Lifetime |
| --- | --- |
| Authorization code | **30 seconds** — exchange it immediately |
| Access token | **60 minutes** |
| Refresh token | **60 days or one use**, whichever comes first |
| Download URL | 15 minutes |

**The rotation rule, in Box's words:** "Every time an application uses the Refresh Token to get a new Access Token the
Refresh Token is invalidated and a new Refresh Token is returned with the new Access Token. This new Refresh Token is
then again only valid for 1 use within 60 days."

What that means for a connector storing credentials for thousands of customers:

- **The refresh response's `refresh_token` must be persisted every single time.** A client that keeps the original
  refresh token succeeds once and fails forever after. This is the single most common way a Box connector rots.
- **A dropped or un-persisted refresh response kills the connection.** If the new token is issued but the write fails,
  the stored token is already invalid. Persist before you discard the old one, and treat a failed persist as an
  incident, not a retry.
- **Concurrent refreshes race.** Two workers refreshing the same connection at once means one of them holds a token
  that the other just invalidated. Serialize refreshes per connection. Box's docs describe no grace period for reuse.
- **Idle connections die.** No refresh within 60 days and the customer must re-authorize. A connector that only
  refreshes on demand will quietly lose seasonal or low-traffic customers.
- Box's current official SDKs handle renewal automatically. A hand-rolled HTTP client does not.
- Access tokens can be revoked early via the revoke endpoint if you need to invalidate a connection deliberately.

**Ask up front whether the client stores the rotated refresh token.** If the answer is no or unknown, say so plainly —
the app will register fine and then fail in production. That is a finding to report, not a step to work around.

## 9. Rate limits, and publishing to Box Integrations

**Rate limits** (per user unless stated), worth knowing before a backfill design review:

- 1000 API requests per minute, per user
- 240 file upload requests per minute, per user
- 6 searches per second and 60 searches per minute, per user; 12 searches per second, per enterprise
- Box Sign: 100 create/resend per minute, 1000 get per minute, per user

Exceeding a limit returns **429 `rate_limit_exceeded`** with a `retry-after` header in seconds. Honour the header,
then back off exponentially. Current Box SDKs retry 429s for you; direct HTTP clients and community SDKs do not.

**Publishing is a separate path from authorization.** Listing your app in **Box Integrations**
(`https://app.box.com/services`) is a Box Partner review, not a technical gate, and it is optional. It matters here
for one reason: an enterprise that blocks *unpublished* apps by default (§4) may still allow *published* ones, so a
listing can remove the per-customer admin step for some customers. It does not remove it for enterprises that gate
published apps too.

To submit: Developer Console → **My Platform Apps** → the app → **Publishing** tab → read the submission checklist and
tick the confirmation → fill in the listing form → **Preview** → **Submit for Approval**. The Box Partner team is
notified and reviews the request; questions go to `integrate@box.com`. An app can be unpublished from the same tab.
Box's stated prerequisites: the app is finished and production-ready, **it uses OAuth 2.0** (Integrations support no
other authentication method), and you have Developer Console access to it.

Everything the listing form asks about positioning, support commitments, partner status or security posture is a
business decision. Collect the answers from the user; do not compose them.

## 10. Verify end-to-end

Testing in the account that owns the app proves very little, and testing on a free developer account proves less —
apps there are authorized automatically. Test the path a customer takes.

1. Authorize from a **second** Box account, ideally a **developer sandbox** with **"Disable unpublished apps by
   default"** turned on, through your platform's real connect flow. That is the only way to see the §4 gate before a
   customer does.
2. Confirm the authorize URL carries `redirect_uri` explicitly (§5) and that the consent screen lists the scopes you
   expect — not more.
3. Exchange the code within its **30-second** life and confirm the response carries a refresh token.
4. Force a refresh. Then force a **second** refresh using the token returned by the first. That is what catches a
   client ignoring rotation — the failure never appears on the first one.
5. Make one real read call against `https://api.box.com/2.0` with the resulting access token.
6. If the connector creates webhooks, confirm those scopes are actually ticked; webhook failures look like
   permissions bugs.

| Symptom | Cause |
| --- | --- |
| `redirect_uri_mismatch` error page instead of the grant screen | Redirect URI not registered character-for-character (§5) |
| `redirect_uri_missing` *after* the user grants access | Multiple URIs configured, authorize URL omitted `redirect_uri` (§5) |
| "Disabled by Administrator" | App not enabled/authorized in that enterprise, or another authorization requirement unmet (§4) |
| Works for you, fails for one customer's whole enterprise | "Disable unpublished apps by default" is on there; their admin must enable it by client ID (§4) |
| Worked, then stopped after adding a scope | Scope change requires re-authorization per enterprise (§4, §6) |
| Second refresh fails, first succeeded | Client is not storing the rotated refresh token (§8) |
| Connection dies after a quiet month or two | 60-day refresh-token expiry; nothing refreshed it (§8) |
| Intermittent `invalid_grant` under load | Concurrent refreshes racing on one connection (§8) |
| Code exchange fails with a valid-looking code | Authorization code older than 30 seconds (§8) |
| 403 on an object the user owns | App scopes too narrow — scopes cap the token independently of user permission (§6) |
| Admin: "Unable to retrieve service of enterprise app authorization" | Wrong client ID, or trailing characters pasted (§4) |
| Admin: "Something went wrong with adding the app authorization" | Co-admin has view-only rights on enterprise settings (§4) |
| 429 `rate_limit_exceeded` | Over a per-user or per-enterprise limit; honour `retry-after` (§9) |

## 11. Hand off — never commit the secret

- **Do not** write the client secret or a developer token into source control, a test, a fixture, a committed `.env`,
  a ticket, a PR body, or a chat channel. Values go to the user, for their secret store or console.
- If a code change is needed (a redirect host, a scope, refresh-token persistence), keep it secret-free and say what
  the human must set out of band.
- Close with: app name and type (Platform App, User Authentication / OAuth 2.0); the owning account and whether it is
  a free developer account, sandbox, or production enterprise; the **client ID** (customers' admins will need it);
  where the secret was delivered; authorize, token and API base URLs; the exact scope strings and a one-line
  justification for each, ready to forward to a customer's admin; whether the client persists rotated refresh tokens;
  the customer authorization story (§4); and anything left for the user to do.

## Stop and ask

Hand back to a human rather than guessing when: the client does not persist rotated refresh tokens, or nobody can say
whether it does (report it — do not register and hope); someone proposes a Server app (JWT or CCG) for a
customer-authorizes-us connector, or proposes converting an existing app's type; the scope set would need
`root_readwrite`, user management, or enterprise-properties access that nobody has justified; a customer's connection
problem turns out to need *their* admin to enable or re-authorize the app; someone wants to rotate the client secret
on a live app; the Box Integrations listing form asks for partner, support, security or volume claims; or the
Developer Console does not match the **Platform state** section above.

Do not use browser automation to click through the Box Developer Console or a customer's Admin Console on someone's
behalf. Produce the exact click path and the literal values to paste, and let the human drive.

## References

Verified 2026-09-20; every link resolved.

- OAuth 2.0 authentication — https://developer.box.com/guides/authentication/oauth2/
- Setup with OAuth 2.0 — https://developer.box.com/guides/authentication/oauth2/oauth2-setup/
- OAuth 2.0 without SDKs — https://developer.box.com/guides/authentication/oauth2/without-sdk/
- Select an authentication method — https://developer.box.com/guides/authentication/select/
- Create a Platform App — https://developer.box.com/guides/applications/platform-apps/create/
- Authorization overview — https://developer.box.com/guides/authorization/
- Platform App Approval — https://developer.box.com/guides/authorization/platform-app-approval/
- Authorization common errors — https://developer.box.com/guides/authorization/common-errors/
- Security: scopes, application access, enterprise settings — https://developer.box.com/guides/security/
- Scopes — https://developer.box.com/guides/api-calls/permissions-and-errors/scopes/
- Token and code expiration — https://developer.box.com/guides/api-calls/permissions-and-errors/expiration/
- Refresh a token — https://developer.box.com/guides/authentication/tokens/refresh/
- Tokens overview — https://developer.box.com/guides/authentication/tokens/
- Rate limits — https://developer.box.com/guides/api-calls/permissions-and-errors/rate-limits/
- Authorize user (endpoint reference) — https://developer.box.com/reference/get-authorize/
- Request access token (endpoint reference) — https://developer.box.com/reference/post-oauth2-token/
- Revoke token (endpoint reference) — https://developer.box.com/reference/post-oauth2-revoke/
- Integrations: publishing a platform app — https://developer.box.com/guides/applications/integrations/
- Developer Console — https://app.box.com/developers/console
- Developer account signup — https://account.box.com/signup/n/developer
- Box Integrations directory — https://app.box.com/services
- Managing platform apps (admin) — https://support.box.com/hc/en-us/articles/360044196653-Managing-platform-apps
- Authorizing platform applications in sandbox and production — https://support.box.com/hc/en-us/articles/360043697014-Authorizing-Apps-in-the-Box-App-Approval-Process
- Understanding requests to authorize or allow applications — https://support.box.com/hc/en-us/articles/360044193933-Understanding-Requests-to-Authorize-or-Allow-Applications
- Developer sandbox management FAQ — https://support.box.com/hc/en-us/articles/360044196313-Developer-sandbox-management-FAQ
- Box Verified Enterprise & supported apps — https://support.box.com/hc/en-us/articles/360043693554-Box-Verified-Enterprise-Supported-Apps
- Box Partner Programs — https://support.box.com/hc/en-us/sections/21356597387539-Box-Partner-Programs