as

Settings
Sign out
Notifications
Alexa
Amazon Appstore
Ring
AWS
Documentation
Support
Contact Us
My Cases
Ring

Ring Appstore Permitted Content Policy

Introduction

The Ring Appstore provides a place for developers to create innovative applications that enhance the security, safety, and functionality of Ring devices and services. Our guiding principle is to maintain customer trust while enabling developer innovation in the smart home security space.

Ring customers expect applications that are safe, secure, and respect their privacy. We've designed these guidelines to help you understand our requirements so your app can move through the review process efficiently. These guidelines reflect Ring's unique position in the smart home security space and our commitment to maintaining customer trust.

Before You Submit

To help your app approval go smoothly, ensure you:

  • Test thoroughly for crashes, bugs, and security vulnerabilities
  • Provide complete metadata including accurate descriptions, screenshots, and privacy information
  • Update contact information so Ring App Review can reach you
  • Provide demo access including active demo accounts or fully-featured demo mode
  • Enable backend services so they're live and accessible during review
  • Document non-obvious features in App Review notes with supporting materials
  • Review security requirements and pass automated security scanning
  • Understand heightened scrutiny categories if your app uses biometric recognition, public safety integrations, or advanced analytics

Safety

Ring customers trust us to protect their home security data and prevent misuse of surveillance capabilities. Apps must not contain content that is offensive, harmful, or enables dangerous behavior.

1.1 Objectionable Content

Apps should not include content that is offensive, discriminatory, violent, sexually explicit, or designed to shock or disgust users. This includes:

  • Defamatory or discriminatory content targeting protected groups (race, religion, gender, sexual orientation, national origin)
  • Realistic violence or content glorifying harm to people or animals
  • Sexually explicit material or pornographic content
  • Hate speech or content encouraging harassment, bullying, or threats
  • False information including misleading functionality claims or fake features
  • Harmful concepts that capitalize on violent events, terrorist attacks, or epidemics
  • Promoting or glorifying violent extremism or terrorism, including recruiting for or advising on how to join terrorist organizations

1.2 Prohibited Surveillance and Enforcement Applications

Ring prohibits applications that enable harmful surveillance or vigilante enforcement behaviors.

1.2.1 Stalking & Harassment Tools

Apps designed to monitor, track, or surveil specific individuals for stalking, harassment, or intimidation purposes are strictly prohibited. This includes apps marketed for tracking ex-partners, monitoring spouses without consent, or secretly surveilling roommates or employees.

1.2.2 Covert Third-Party Surveillance

Apps that provide or enable third-party access to a customer's Ring device and related data without the customer's explicit knowledge and consent are prohibited. Apps must provide to Ring customers easy access to monitoring activity or access logs.

1.2.3 Cross-Property Surveillance Networks

Apps that compile data from multiple Ring customers to track specific individuals across locations without explicit user consent are prohibited. Apps cannot create movement profiles showing where people travel across multiple properties or alert when specific individuals enter geographic areas covered by multiple Ring cameras.

1.2.4 Unauthorized Personal Data Collection

Apps collecting, mapping, or deriving personal data about individuals captured on video without explicit consent are prohibited. This includes matching faces against social media profiles, cross-referencing license plates with DMV databases, or collecting biometric data without consent.

1.2.5 Vigilante Enforcement & Community Watchlists

Apps that create community-generated "watchlists" or suspect databases, coordinate community members to confront or pursue individuals, or facilitate "citizen patrols" are prohibited. Apps must not substitute mob justice for legitimate law enforcement.

1.2.6 Public Shaming Without Due Process

Apps facilitating public identification, shaming, or coordinated action against individuals accused of wrongdoing before conviction or proper legal process are prohibited.

1.2.7 Suspect Registries

Apps creating community-generated databases of suspected offenders or "suspicious persons" are prohibited.

1.2.8 Child-Directed Applications

Apps directed toward children or designed to be used by children are not permitted on the Ring Appstore. This prohibition applies to apps that target children as the primary audience, feature child-oriented content, characters, or activities, market themselves to children, or would be classified as "child-directed" under COPPA or similar regulations.

1.3 User-Generated Content

Apps with user-generated content must include:

  • Terms of use that define allowed content in a way that complies with Ring Appstore policies
  • Require that users to agree to terms before creating or uploading content
  • Content filtering to prevent objectionable material from being posted
  • Reporting mechanisms for offensive content with timely responses
  • User blocking capabilities to block abusive users
  • Published contact information so users can reach you

Apps must take action against users or content that violate terms of use or Ring Appstore policies. Actions may include content removal, user warnings, temporary suspensions, or permanent bans. Apps used primarily for pornographic content, anonymous harassment, objectification, physical threats, or bullying will be removed.

1.4 Physical Harm

Apps that risk physical harm may be rejected:

  • Medical apps making inaccurate or misleading health claims or diagnoses will be immediately rejected
  • Apps must disclose data and methodology supporting health measurement accuracy claims
  • Apps should remind users to consult doctors before making medical decisions
  • Drug dosage calculators must come from approved entities (drug manufacturers, hospitals, pharmacies)
  • Apps encouraging substance abuse (tobacco, illegal drugs, excessive alcohol) are prohibited

1.5 Developer Information

Apps must include accurate, up-to-date contact information for customer support. Failure to provide valid contact information may violate laws in some jurisdictions.

1.6 Data Security

Apps must implement appropriate security measures to protect user information from unauthorized use, disclosure, or access by third parties. See Section 4.1 for detailed privacy requirements.

Performance

2.1 App Completeness

Submissions must be final versions with all necessary metadata and fully functional URLs. Apps must be tested on-device for bugs and stability. Include demo account credentials if your app requires login.

2.2 Accurate Metadata

App descriptions, screenshots, and previews must accurately reflect the app's core experience:

  • No hidden features - all functionality must be disclosed and accessible for review
  • Clear in-app purchase disclosure - indicate which features require additional purchases
  • Accurate descriptions - Marketing must match actual functionality
  • Appropriate screenshots - Show the app in use, not just splash screens or stock photos
  • Professional app icons - Clear, recognizable, and representative of app functionality
  • No misleading claims - Especially important for security, privacy, or surveillance capabilities

Apps making health-related claims must include prominent disclaimers that they do not provide medical diagnosis and must direct users to consult licensed healthcare providers.

Apps making claims about security capabilities, surveillance features, or data protection must provide accurate, verifiable information. False or misleading claims about security or privacy features will result in immediate rejection.

2.3 Hardware Compatibility

Apps should use power efficiently and not risk device damage. Apps must not:

  • Rapidly drain battery or generate excessive heat
  • Run unrelated background processes (e.g., cryptocurrency mining)
  • Require device restarts or system setting modifications unrelated to core functionality

2.4 Software Requirements

Apps must:

  • Use only public APIs and run on currently shipping operating systems
  • Be self-contained in their bundles without downloading executable code
  • Not transmit viruses, malware, or code that disrupts normal operation

3.0 Business Requirements

3.1 Copycats

Create original apps. Don't copy popular apps or make minor changes to another app's name or UI. Don't impersonate other apps or services.

3.2 Minimum Functionality

Your app should provide meaningful functionality beyond a repackaged website. Apps must be useful, unique, and "app-like" to belong on the Ring Appstore.

3.3 Spam

Don't create multiple versions of the same app. Avoid saturated categories unless you provide a unique, high-quality experience.

Apps must comply with all legal requirements in locations where you make them available. Ring may refuse to distribute your app in specific regions where the app content would violate:

  • Local laws and regulations
  • Cultural norms and sensitivities
  • Regional content standards

Apps that provide services in highly regulated fields (financial services, healthcare, etc.) or that require sensitive user information should be submitted by a legal entity that provides the services, and not by an individual developer.

4.1 Privacy

Protecting user privacy is paramount. You must comply with privacy best practices, applicable laws, and customer expectations.

4.1.1 Data Collection and Storage

Privacy Policies: All apps must include a privacy policy that clearly discloses:

  • What data the app collects and how it's collected
  • All uses of that data
  • Third parties with whom data is shared
  • Data retention and deletion policies
  • How users can revoke consent and request data deletion

Apps processing video data in workplace settings must comply with applicable employment laws and regulations. Employers using workplace monitoring applications are responsible for providing appropriate notice to employees and obtaining any required consents in accordance with local laws.

Permission: Apps must secure user consent for data collection, use, and sharing. Apps must provide an easily accessible way to withdraw consent.

Data Minimization: Apps must only collect and use the data required to support and improve the features and services the app provides (e.g., the features described on the app's detail page).

Account Sign-In: If your app doesn't include significant account-based features, let people use it without login. Apps must offer account deletion within the app.

4.1.2 Data Use and Sharing

You may not use, transmit, or share personal data without first obtaining consent. Apps may only use or share the data in a way that customers have consented to. Data collected for one purpose may not be repurposed without further consent. Any collection and use of that must comply with the app's privacy policy and all applicable laws. Apps must not:

  • Build user profiles from collected data without consent
  • Use Ring customer data to build databases for sale
  • Compile personal information from any source that is not directly from the user or without the user's explicit consent, including compiling information from public databases, social media platforms, government records, or any other external sources.

If end users would not expect their personal data to be required to support and improve the features and services your app provides, the app's disclosure and consent for such data collection, use and sharing must be more prominent. For example, your app must disclose what data is collected and how it's used, and the disclosure must be part of the normal operation of the app (not behind a menu, policy, or terms of service) and must not be part of disclosures unrelated to personal data collection. Your app must present a clear consent dialogue and get consent through an affirmative user action (e.g., tap or click, not navigating away or from an auto-expiring message) before your app begins collecting such data.

Data gathered from Ring cameras or other integrated devices may not be used for marketing, advertising, or use-based data mining without explicit consent.

4.2 Biometric Recognition & Surveillance Technologies

Ring requires heightened scrutiny for applications using biometric recognition technologies due to the sensitive nature of biometric data and the potential for misuse in surveillance contexts. Apps in this category may be subject to extended review timelines and may require additional documentation, technical demonstrations, or legal attestations at Ring's sole discretion.

4.2.1 Facial Recognition

Facial recognition may only be used to identify individuals that the Ring customer has explicitly enrolled and consented to identify. Apps must not identify strangers, passersby, or any individual the customer has not personally tagged.

Prohibited Practices

Your app must not:

  • Use pre-built face databases: Apps cannot come with pre-loaded databases of faces (celebrities, public figures, known offenders, etc.) to identify individuals captured on Ring cameras who have not consented to such collection
  • Match against external databases: Apps cannot match faces against social media profiles (Facebook, Instagram, LinkedIn), government databases (DMV records, passport photos), marketing databases, or any other external source of facial data
  • Identify non-enrolled individuals: Apps cannot use facial recognition to identify people the customer hasn't explicitly tagged themselves, even if that person's face appears in publicly available sources
  • Compile facial data from external sources: Apps cannot aggregate or compile facial recognition data from any source other than direct customer enrollment within your app

Example Violation: An app that automatically identifies delivery drivers by matching their faces against a database of gig worker profile photos from delivery company websites would violate this policy, even if those photos are publicly accessible.

Required Implementation Standards

Apps using facial recognition must implement all of the following:

  1. Customer-Controlled Enrollment:
    • Customers must manually tag and enroll each individual they want the app to recognize
    • No automatic enrollment based on frequency of appearance or other heuristics
    • Clear enrollment UI showing which individuals are enrolled and when
  2. Explicit Consent Requirement:
    • Obtain clear, affirmative customer consent before enabling any facial recognition functionality
    • Consent must be separate from general app permissions (not bundled with camera access)
    • Customers must be able to review and revoke consent at any time
  3. Encrypted Data Storage:
    • All facial recognition data (facial templates, embeddings, enrollment records) must be encrypted both in transit and at rest
    • Use industry-standard or better encryption
    • Implement secure key management practices
  4. Customer Deletion Rights:
    • Provide customers with immediate ability to delete enrolled faces and all associated facial recognition data
    • Deletion must be permanent and irreversible
    • Confirm deletion to customer within your app UI

Documentation Requirements

During app review, you must provide:

  • Technical documentation of your facial recognition implementation
  • Privacy impact assessment addressing facial recognition risks
  • Data flow diagram showing how facial data is collected, processed, stored, and deleted
  • Attestation that you do not use external face databases

4.2.2 Biometric Data Collection

Any collection of biometric identifiers beyond facial recognition requires explicit customer consent, heightened security measures, and strict purpose limitation.

Covered Biometric Identifiers

This policy applies to:

  • Voiceprints: Voice recognition or voice-based identification
  • Iris scans: Eye or iris-based identification
  • Gait analysis: Identification based on walking patterns or movement characteristics
  • Other biometric identifiers: Any physiological or behavioral characteristic used to identify individuals

Required Implementation Standards

Apps collecting biometric identifiers must:

  1. Obtain Explicit Consent:
    • Present clear, plain-language disclosure of what biometric data is collected and why
    • Obtain affirmative opt-in consent (not pre-checked boxes or implied consent)
    • Allow customers to use your app's core functionality without providing biometric data, where feasible
  2. Implement Heightened Security:
    • Encrypt biometric data in transit and at rest according to industry standards or above
    • Store biometric templates (not raw biometric data) where technically feasible
    • Implement access controls limiting which systems and personnel can access biometric data
    • Conduct regular security audits of biometric data handling
  3. Purpose Limitation:
    • Use biometric data only for the specific purposes disclosed to customers
    • Do not repurpose biometric data for marketing, advertising, or analytics without separate consent
    • Do not sell biometric data to third parties
  4. Provide Deletion Capabilities:
    • Allow customers to delete their biometric data at any time
    • Provide confirmation of deletion

Note: Biometric data collection may be subject to additional legal requirements under state biometric privacy laws. Developers are responsible for ensuring compliance with all applicable laws.

Documentation Requirements

During app review, you must provide:

  • Biometric data inventory: List of all biometric identifiers collected (fingerprints, voiceprints, iris scans, gait analysis, etc.)
  • Purpose statement: Detailed explanation of why each biometric identifier is necessary for your app's functionality
  • Security architecture documentation: Technical documentation of encryption methods, access controls, and security measures protecting biometric data
  • Data flow diagram: Visual representation showing how biometric data is collected, processed, stored, transmitted, and deleted
  • Consent flow screenshots: UI mockups or screenshots showing how customers are informed about biometric collection and how they provide consent
  • Deletion procedure documentation: Technical description of how customers can delete their biometric data and how deletion is implemented
  • Privacy policy: Link to privacy policy with comprehensive biometric data disclosure
  • Legal compliance attestation: Statement confirming compliance with applicable biometric privacy laws (BIPA, state laws, GDPR if applicable)
  • Third-party sharing disclosure: If biometric data is shared with third parties (service providers, analytics platforms), provide list of recipients and purposes

4.2.3 License Plate Recognition (LPR)

License plate recognition is permitted only for specific operational purposes with strict limitations on data retention, geographic scope, and secondary use. LPR for persistent surveillance or tracking across locations is prohibited.

Prohibited - Surveillance Uses

Your app must not use LPR for:

  • Persistent cross-location tracking: Creating databases that track vehicle movements across multiple properties, neighborhoods, or jurisdictions
  • Surveillance databases: Building or contributing to databases of vehicle movements for surveillance purposes
  • Secondary data sharing: Sharing LPR data beyond the stated operational purpose (e.g., selling parking data to advertisers, sharing with data brokers)
  • Profiling or targeting: Using LPR data to build profiles of individuals' movements, habits, or behaviors

Example Violation: An app that tracks vehicles across multiple Ring customer properties to create a "suspicious vehicle database" or map vehicle movement patterns across a neighborhood would violate this policy.

Permitted - Operational Uses

Below are examples of permitted operational uses for LPR:

  • Ticketless Parking: Entry/exit detection and automated payment for parking facilities
  • Toll Collection: Automated toll billing for private roads or facilities
  • Access Control: Granting or denying access to private property based on license plate (e.g., gated communities, private parking lots)
  • Fleet Management: Tracking company-owned vehicles with driver consent
  • Parking Occupancy Detection: Monitoring parking space availability without identifying specific vehicles over time
  • Law Enforcement Coordination: Sharing LPR data with law enforcement agencies in response to specific, lawful requests (see Section 4.3.1 for additional requirements)

Required Implementation Standards

Apps using LPR must comply with all of the following:

  1. Purpose Limitation:
    • Use LPR data only for the specific operational purpose disclosed to customers
    • Do not repurpose LPR data for marketing, analytics, or other secondary uses
    • Do not sell LPR data to third parties
  2. Geographic Scope Limitation:
    • Limit LPR functionality to specific properties or facilities where the customer has authority
    • Do not aggregate LPR data across multiple customer properties without explicit per-property consent
    • Clearly disclose the geographic scope of LPR data collection
  3. No Cross-Location Tracking:
    • Do not link LPR detections across multiple locations to create movement profiles
    • Do not share LPR data between customers or properties for tracking purposes
    • Implement technical controls preventing cross-location correlation
  4. Transparency and Consent:
    • Clearly disclose LPR functionality in your app description and privacy policy
    • Obtain customer consent before enabling LPR
    • Provide customers with access to LPR data collected about their own vehicles

Documentation Requirements

During app review, you must provide:

  • Detailed description of your LPR use case and operational purpose
  • Data retention and deletion policies
  • Technical controls preventing cross-location tracking
  • Privacy policy addressing LPR data handling

4.3 Public Safety Integrations

Ring requires heightened scrutiny for applications that integrate with public safety systems or facilitate law enforcement access to customer data.

4.3.1 Law Enforcement Direct Access

Apps must not provide law enforcement with direct access to customer cameras or recordings without explicit, per-instance customer notification and consent. Customers must retain the ability to immediately revoke access.

Prohibited Practices

Your app must not:

  • Provide law enforcement with direct, standing access to customer cameras or recordings
  • Create "backdoor" access mechanisms that bypass customer knowledge or consent
  • Share customer video with law enforcement without explicit customer authorization for each specific request
  • Aggregate customer video across properties for law enforcement surveillance purposes

Example Violation: An app that gives local police departments a dashboard to view live feeds from participating Ring customers' cameras without per-instance customer notification would violate this policy, even if customers initially consented to participate in the program.

Permitted Practices

Your app may facilitate:

  1. Verified Crime Alert Sharing:
    • Apps that share verified crime alerts from official law enforcement sources (police departments, sheriff's offices)
    • Alerts must come from official, verified law enforcement accounts
    • Must not include unverified community reports or accusations
  2. Customer-Initiated Sharing:
    • Apps that enable customers to voluntarily share their own video with law enforcement through proper channels
    • Customer must initiate each sharing instance
    • Must provide clear confirmation of what was shared and with whom

Required Implementation Standards

Apps facilitating any law enforcement access must implement all of the following:

  1. Explicit Per-Instance Notification:
    • Notify customers each time law enforcement accesses their camera or recordings
    • Notification must occur in real-time or as close to real-time as technically feasible
    • Notification must identify which agency accessed data and when
    • Notification must be prominent (push notification, email, in-app alert)
  2. Immediate Revocation Capability:
    • Provide customers with immediate ability to revoke law enforcement access
    • Revocation must take effect immediately (within seconds, not hours or days)
    • Clearly display revocation controls in your app UI
    • Confirm revocation to customer
  3. Local Agency Limitation:
    • Direct access limited to local law enforcement agencies (city police, county sheriff) with jurisdiction over the customer's property
    • No direct access for federal or state agencies without separate legal process
    • Clearly disclose which agencies may access customer data

Documentation Requirements

During app review, you must provide:

  • Detailed description of law enforcement access mechanisms
  • Customer notification and consent flows
  • Revocation procedures and technical implementation

4.3.2 Community Safety Coordination

Community safety apps must facilitate legitimate safety information sharing while preventing vigilante enforcement, public shaming, and privacy violations. Apps must include robust content moderation and official oversight.

Prohibited Practices

Your app must not:

  • Create community-generated watchlists: Apps cannot enable communities to create databases of "suspicious persons," "known offenders," or other watchlists based on community reports rather than official law enforcement records
  • Coordinate confrontation or pursuit: Apps cannot facilitate community members confronting, pursuing, detaining, or taking action against individuals
  • Enable public shaming before conviction: Apps cannot facilitate public identification or shaming of individuals accused of wrongdoing before conviction or proper legal process
  • Share video across properties without consent: Apps cannot automatically share customer video across multiple properties or with community members without explicit, per-instance customer consent

Example Violation: An app that allows neighborhood residents to post photos of "suspicious individuals" with their license plates and create a shared database accessible to all community members would violate this policy.

Permitted Practices

Your app may facilitate:

  1. Verified Crime Alerts:
    • Sharing verified crime alerts from official law enforcement sources
    • Alerts must be factual, verified, and come from official police accounts
    • Must not include speculation, accusations, or unverified community reports
  2. Emergency Response Coordination:
    • Apps that coordinate emergency response during active emergencies (fires, medical emergencies, natural disasters)
    • Must focus on safety coordination, not surveillance or enforcement
  3. Neighborhood Watch with Official Oversight:
    • Neighborhood watch programs with official police liaison oversight
    • Must have designated law enforcement liaison who monitors program activity
    • Must include content moderation to prevent vigilante behavior
  4. General Safety Information:
    • Sharing general safety information (crime prevention tips, emergency preparedness)
    • Must not identify specific individuals or properties

Required Implementation Standards

Apps facilitating community safety coordination must implement all of the following:

  1. Explicit Per-Instance Consent:
    • Obtain explicit customer consent each time their video or data is shared with community members
    • Consent must be specific to each sharing instance (not blanket consent)
    • Clearly show customers what is being shared and with whom
    • Provide easy opt-out mechanisms
  2. Content Moderation:
    • Implement proactive content moderation to prevent vigilante enforcement, harassment, and privacy violations
    • Remove content that identifies individuals without proper legal basis
    • Remove content that encourages confrontation, pursuit, or public shaming
    • Promptly respond to any user reports
    • Maintain clear community guidelines prohibiting vigilante behavior
  3. Official Police Liaison Oversight (for neighborhood watch programs):
    • Designate official law enforcement liaison who monitors program activity
    • Liaison must have ability to remove inappropriate content
    • Liaison must provide guidance on appropriate vs. inappropriate reporting
    • Clearly identify liaison within app
  4. Separate Certification Required:
    • Apps in this category require separate certification beyond standard Ring Appstore review
    • Certification process includes review of content moderation policies, oversight mechanisms, and privacy protections
    • Certification must be renewed annually
    • Ring reserves the right to revoke certification if app is misused for vigilante enforcement

Documentation Requirements

During app review, you must provide:

  • Detailed description of community safety features
  • Content moderation policies and procedures
  • Designated law enforcement liaison information (for neighborhood watch apps)
  • Customer consent flows for video sharing
  • Examples of community guidelines and terms of service
  • Plan for preventing vigilante enforcement and public shaming

Review Timeline Expectations

Apps in the Biometric Recognition & Surveillance Technologies (Section 4.2) and Public Safety Integrations (Section 4.3) categories should expect:

  • Extended review timelines: Apps in these categories may experience a longer review timeline
  • Additional documentation requests: Ring may request technical demonstrations, privacy impact assessments, legal attestations, or third-party security audits
  • Ongoing monitoring: Apps in these categories are subject to ongoing compliance monitoring and may be re-reviewed periodically
  • Certification requirements: Some use cases require separate certification beyond standard app review

Ring reserves the right to reject apps in these categories at our sole discretion, even if all stated requirements are met, if we determine the app poses unacceptable privacy or safety risks to customers.

4.4 Intellectual Property

Apps must only include content you created or have license to use. Don't use protected third-party material (trademarks, copyrighted works, patented ideas) without the necessary rights or permissions. Your apps, including app metadata, must not infringe on the intellectual property rights (including copyright, trademark and publicity rights) of a third party.

4.5 Developer Code of Conduct

Treat everyone with respect. Do not engage in harassment, discriminatory practices, intimidation, or bullying. Customer trust is paramount - apps must never prey on users, trick them into unwanted purchases, or engage in manipulative practices.