How do I register an OAuth app?

To build an app that connects to Orshot on behalf of users, you need a client ID and client secret. Register your app in the dashboard to get them. Review happens only when you ask to publish it.

What You'll Need to Provide#

When registering your app, include the following details:

Register Your App#

Sign in to your Orshot account and submit your app through the Developer Program:

Register Your App →

What Happens Next#

1. Submit your app: Fill out the registration form with your app details
2. Start building: Your client_id and client_secret are available immediately in the Developer Program dashboard
3. Test in development mode: Only you (and any test users you added) can authorize the app
4. Submit for review: When ready, submit your app for publishing to make it available to all users

Development Mode#

All new apps start in development mode (private). While in development mode:

• Only the app owner and explicitly added test users can authorize the app
• Other users who try the Authorization Code flow see an access_denied error
• In the Device Flow, other users can approve, but every API call with their token fails
• Render calls made with tokens from unauthorized users return a sandbox_restricted error. Template endpoints currently return a plain 401 instead
• The consent screen shows an "unverified app" warning to test users

This mirrors how platforms like Google and Shopify handle app development — you can build and test safely before going live.

Redirect URI Rules#

When you register redirect URIs, Orshot accepts:

• HTTPS URLs: https://your-app.com/callback (required for production)
• Localhost: http://localhost:3000/callback, 127.0.0.1 or [::1] (any port, for development)
• Custom schemes: vscode://your-extension/callback, cursor://, claude:// (for IDE extensions and desktop apps)

You can register multiple redirect URIs. Register every redirect URI you use, and send one of them as redirect_uri. If a request uses a redirect that is not registered, the consent screen warns the user where their access is going. The token request must use the same redirect_uri as the authorize request.

Keep Your Secret Safe#

• Never expose your client_secret in client-side code (browser JavaScript, mobile apps)
• Store it in environment variables or a secrets manager
• If your secret is compromised, email us immediately for rotation
• Every client uses PKCE (S256). The token endpoint never takes the secret, so SPAs and mobile apps work without it. Only token introspection needs it