Changing a live app

Once FleetBold approves your app (Go-live), it keeps working while you change it. Some changes apply at once; the others are proposed and wait for a re-review, while your users keep using the approved configuration. A change never creates a new version that goes live by itself.

At once or after a review

• Applied at once: description, support e-mail and support URL; removing a redirect URI (a live app always keeps at least one); adding a redirect URI that matches a registered one (same kind and registrable domain for https, same scheme for a private-use scheme, any registered loopback).
• Proposed, applied when a re-review approves them: name, logo, short description, category, website, privacy policy, terms of service, company details, and redirect URIs on a new domain or scheme.
• Adding a scope: applied at once as a pending scope (below). Removing a scope: applied at once for every user (below).
• Marking a scope as required by the app, or unmarking it: applied at once, never reviewed. Only approved scopes can be required (a pending one would lock your other users out). Existing connections that lack a newly required scope keep their tokens and are asked for it at their next authorization.
• The client type cannot change on a live app (409 client_type_immutable): register a new app.
• Adding a http://localhost redirect URI: refused on a live app (redirect_uri_localhost_live). Create a test app instead (below).
• While a submission is open (submitted or in review), changes are refused (409 submission_open) until FleetBold decides. On a live app this console asks you to confirm every scope change and explains its effects first.

Adding a scope

• A scope you add after Go-live is pending FleetBold review. You and your test users can grant it: the consent page marks it *Pending FleetBold review* (a pending command scope also shows the vehicle-operation warning). Use these connections to test it; the reviewer sees which scopes your app used.
• Every other user: the scope is left out of the authorization, which continues with your approved scopes. Read what was granted from scope in the token response. Only an authorization that asks for nothing but pending scopes is refused (invalid_scope), unless your app has required scopes: it then continues with them. So you can ship code that already asks for the new scope: it starts working for everyone once FleetBold approves it.
• Submit a re-review from Go live. Approved: the scope is grantable to every user, and you can mark it as required. Rejected or changes requested: nothing changes and the scope stays pending.
• First approval of only some scopes: if your first Go-live approval leaves some of your scopes pending, those scopes stop being required (the approval e-mail lists them). Mark them again once a re-review approves them.
• Existing connections keep the scopes they granted. To get the new scope from a user who is already connected, send them through a new authorization (incremental consent); the consent page is prefilled with what they shared before.

Removing a scope

• Takes effect at once, for every user: the scope is removed from your app and from every active connection, and access tokens stop carrying it immediately. Calls that need it answer 403 insufficient_scope; refreshing keeps working with the remaining scopes.
• A connection left without any scope stays connected (every call answers insufficient_scope) until the user or you disconnect it.
• App webhook data that depends on the scope stops being sent.
• A removed scope is also no longer required by your app.
• Adding the scope back later makes it pending again: it needs a new review.

Re-review

• Your app stays live during a re-review; users keep the approved configuration.
• Approved: the proposed changes are applied together and the approved pending scopes become grantable to everyone.
• Changes requested: update what FleetBold asks for and submit again. Rejected: nothing is applied; pending scopes stay pending.
• Scopes already approved for your app need no new evidence on a re-review.

Developing locally after Go-live: test apps

• From the live app's Overview, choose Create test app. FleetBold copies the profile, company details, redirect URIs and scopes once; secrets, webhooks, test users and connections are not copied, and nothing is synced later.
• The test app has its own client ID and secret and stays in development: http://localhost redirect URIs work, and you, its test users and the live app's test users can connect it with every declared scope.
• It starts in development when your contact e-mail is verified; otherwise verify the link we send. It counts toward your team's app limit.
• A test app never goes live (409 test_app_cannot_go_live). Ship through the live app: add new scopes there (they stay pending), make the same changes and submit a re-review.
• From the test app's Go live tab, choose Apply to {live app} & submit: pick the changes, run the checks (the live app's rules, localhost never carried), then apply and submit in one step. Nothing changes on the live app until every check passes.
• Deleting the live app deletes its test apps; removing a test user from the live app disconnects them from its test apps too.