Walk through the app testing process
Walk through the steps for QAing your app before submitting it for review.
Ensure your app meets all the requirements listed in our checklist to passing your app review.
Best practices for your app
In addition to the requirements listed above, follow these best practices to make the best version of your app.
Write clear error messages
Write clear error messages for both the OAuth flow and any errors users may encounter when using your app.
For your OAuth flow, make sure to write clear error messages for the following situations:
- User denies authorization
- Authorization code times out
For your app, write clear error messages for any errors a user may encounter. For example, if your app requires uploading an image of a specific size, ensure the error message for an image of the wrong size reflects the issue.
Good error message: "Oops! The image you uploaded is too small. Please upload an image with at least 1080x1080 pixels."
Bad error message: "An error occurred. Please try again."
Clear error messages are required; they make your app easier to use and help fulfill the customer value and ease of use requirements.
Prepare for branded event metrics
With branded event metrics, your app's logo will show up next to each metric from your event. This branding differentiates your app's metrics from API metrics, or metrics sent with a public or private API key. Brading indicates which metrics are associated with your specific app.
Once your OAuth app is approved, your metricsn will automatically be branded with your app's logo.
Be aware of divergent metrics, or 2 metrics with different IDs but the same name. Tthe metric coming from your OAuth app will be branded, but a metric coming authenticated with an API key will not.
To avoid confusion, do not send the same metric via both OAuth and API methods and do not change metric names. Learn more about branding for app metrics.
Use recommended formats for profile properties, event names, event data, and list names
To maintain consistency and ease of use, follow these recommended formats for Klaviyo profile properties, event names, event data, and lists.
Profile properties:
Use the format [app name] [profile property]. Let's consider an example app called LoyaltyApp. A customer profile property containing the number of points each profile has could be titled LoyaltyApp points.
Event names:
Events should be named using the format [past tense verb] [noun]. LoyaltyApp sends an event into Klaviyo when customers join a new loyalty tier. This event should be named Joined loyalty tier.
Event data:
There are 2 main considerations to keep in mind when formatting event data:
1. Ensure all event data inended for segmentation and filtering is top-level, meaning it should not be nested inside other data fields within your event data.
2. Send personal information about a customer as profile properties rather than event data.
Consider the LoyaltyApp Joined loyalty tier event:
Both pieces of event data are top-level, so the team can create segments based on this data. The number of loyalty points is also sent through as part of this event, but it is stored as a profile property instead since it contains information about the customer.
Lists:
Use the format [app name] [list name]. For example, a list of all subscribers from an app called LoyaltyApp could be titled LoyaltyApp subscribers.
Respect rate limits
Rate limits for OAuth apps are determined on a per-app basis. Each app receives a rate limit quota per installed app instance, so each account that installs your app can hit the rate limit for each endpoint.
Be sure to factor these rate limits into your app’s design. Learn more about rate limits for OAuth apps.