Developer Apps
Developer Apps provide access to advanced Briq features, particularly OTP services. They act as secure integrations scoped to workspaces with developer access enabled. Each app represents a distinct client integration — your mobile app, web service, or backend.What are Developer Apps?
Developer Apps are client applications that enable access to OTP services and other developer-restricted features in the Briq platform. You bind an API Key to a Developer App so Karibu resolves the app fromX-API-Key on every request. You do not send app_key in request bodies once the key is bound.
Key Characteristics
- OTP Access: Required context for all OTP request and verification operations
- API Key Binding: Bind one API key per app per environment; Karibu resolves the app from
X-API-Key - Workspace Linking: Must be linked to workspaces with developer access enabled
- Secure Integration: Provide controlled, auditable access to advanced features
Requirements for Developer Apps
Workspace Access
- Developer apps can only work with workspaces that have
developer_access = true - You must enable developer access on your workspace before creating apps
API Key Binding
- OTP and other developer-restricted APIs require an API key bound to a Developer App
- Bind at key creation (
POST /api-keys/?developer_app_id={app_id}) or attach an existing key (POST /developer-apps/{app_id}/api-keys/{api_key_id}/attach) - Once bound, only
X-API-Keyis required in request headers — do not sendapp_keyin the body
app_key on the Developer App record
- Each Developer App has an
app_keyreturned in API responses (for dashboard and admin use) app_keyis not a request credential when your API key is bound to the app
Managing Developer Apps
Creating a Developer App
Binding an API Key to a Developer App
Bind at creation time:Listing Developer Apps
Getting Developer App Details
Updating a Developer App
Listing API Keys for a Developer App
Using Developer Apps with OTP
Once your API key is bound to a Developer App, OTP requests require only theX-API-Key header. Do not include app_key in the request body.
Best Practices
Developer App Management
- Descriptive Names: Use clear
app_namevalues that indicate the app’s purpose - Workspace Linking: Ensure apps are linked to workspaces with developer access
- One Key Per App Per Environment: Bind a dedicated API key to each Developer App in each environment (development, staging, production)
- Regular Review: Periodically review and clean up unused apps
Security Considerations
- API Key Rotation: Rotate API keys (not
app_key) when credentials are compromised or on a schedule — create a new key, attach it, migrate traffic, then revoke the old key - Key Confidentiality: Treat bound API keys as secrets; never expose them in client-side code
- Monitoring: Track API key usage and access patterns per Developer App
- Environment Separation: Use separate Developer Apps and bound API keys for development and production
Integration Tips
- Error Handling: Implement robust error handling for app creation, key binding, and OTP calls
- Testing: Test the full flow (create app → bind key → call OTP) in a development environment before production
- Logging: Log OTP and API activity server-side for debugging and monitoring
- Deactivation: Set
is_active = falseon unused apps instead of deleting them