Integrations
Hierarch connects with external tools to bring design project management into a single workspace. Each integration follows the same pattern: authenticate with the external service via OAuth, sync relevant data into the Hierarch UI, and push updates back when changes happen inside Hierarch.
Supported Integrations
| Service | Capabilities |
|---|---|
| Linear | Full issue sync, status management, design metadata, Figma attachment linking |
| Figma | File embedding, oEmbed thumbnails, design token access, dev resource linking |
| Jira | Issue sync via serverless proxy, JQL search, status transitions |
| Slack | Phase change notifications, feedback request routing, project updates |
Authentication
All integrations authenticate via OAuth 2.0. When a user connects a service, Hierarch redirects to the service's authorization page with the required scopes and a state parameter. After the user authorizes, the service redirects back to Hierarch's callback URL. A Vercel serverless function exchanges the authorization code for access tokens, which are stored server-side in Supabase and associated with the user.
OAuth Flow
1. User clicks "Connect [Service]" in Hierarch settings 2. Hierarch redirects to the service's OAuth authorization URL with the required scopes and a state parameter 3. User authorizes the Hierarch application 4. Service redirects back to Hierarch's callback URL: https://hierarch.vercel.app/api/auth/callback/[service] 5. Hierarch's serverless function exchanges the code for tokens 6. Tokens are stored server-side (Supabase) and associated with the user 7. Hierarch loads the integration view with the authenticated connection
Redirect URIs
When registering Hierarch as an OAuth application with any external service, use these redirect URIs:
Production: https://hierarch.vercel.app/api/auth/callback/[service] Development: http://localhost:3000/api/auth/callback/[service]
Replace [service] with the lowercase service name (e.g. linear, jira, slack, figma).
Data Access Principles
Every integration page documents exactly what data Hierarch accesses. As a general principle, Hierarch requests the minimum scopes necessary and only reads data that the user explicitly views. Write operations are limited to actions the user initiates inside the Hierarch UI (updating an issue status, creating an attachment, posting a notification).