Who is your app for?
Not all apps need to go through all three phases. To determine which phases are relevant for your app, you should first ask yourself who your app is for. Attio apps are generally built for one of the following audiences:- Internal users only - You want to extend Attio with specific functionality for one or only a handful of workspaces. Ideal for internal tools and custom workflows.
- All workspaces - You want your app to be used by any workspace and list it publicly in the Attio App Store. Ideal for public integrations aimed at a wide audience.
Developing your app
How to develop and test your app differs depending on which features of the Attio platform it uses.Development mode
If you are using the App SDK and theattio CLI, you can run your app locally in development mode using the attio dev command. This pushes local changes to a specific Attio workspace in realtime. Updates will be available immediately to all users in the workspace and will persist after the dev command is stopped.
We recommend that development mode is used for development and testing purposes only. For apps you wish to use in production, we recommend building the app in a development workspace and then using private invites (see below) to share with your main production workspace(s).
We recommend that each developer use an isolated development workspace. As app functionality exists globally across the workspace, two instances of attio dev running simultaneously in the same workspace may result in unexpected behavior.
We are happy to provide your team with development workspaces as needed. Please reach out to support@attio.com or use the chat widget in the bottom right of the screen to request a development workspace.
API keys
If your app interacts with Attio’s REST API and only needs access to a single workspace, you can use API keys to authenticate your requests. This is the simplest option for internal apps. During development, generate an API key for an isolated test workspace. When you’re ready to use the app in production, generate a separate API key for your production workspace.External infrastructure
If your app runs on your own infrastructure and makes requests to Attio’s REST API, you may want to configure separate development, staging, and production environments within your service.Sharing your app privately
Private invites
If using the App SDK, you can share an unpublished version of your app with specific workspaces using a private link. Internal apps should use private invites to share finalized versions of their app with specific workspaces. Public apps can use private invites to share preview versions with alpha users before publication. As apps shared via private invite links have not been approved by the Attio team, users will see a warning before installing the app. See private invites for more information.OAuth flows for unpublished apps
If your app uses OAuth, users can install it via the standard OAuth flow even before the app has been published. However, they will see a warning that the app has not yet been approved by the Attio team. To remove these warnings, submit your app for review. See publishing to the App Store for more information.Publishing to the Attio App Store
Publishing makes your app available to all Attio users through the in-product and public App Stores. This works for both OAuth/API apps and App SDK apps. Publishing requires a review from the Attio team, which can take up to 1 week. Before submitting, you’ll need to meet our requirements for listing content, code, logos, and App Store images. See publishing to the App Store to learn more.Summary
| Feature | Audience | Development usage | Private usage | Public usage | Review |
|---|---|---|---|---|---|
| App SDK | Internal | Development mode | Private invites | n/a | No |
| App SDK | Public | Development mode | Private invites | Install from App Store | Yes |
| REST API | Internal | API keys | API keys | n/a | No |
| REST API | Public | OAuth (unapproved) / API keys | OAuth (unapproved) | OAuth (approved) | Yes |