Home › Resources

Alexa Skill Privacy Policy: What Amazon Requires and How to Create One

Published August 13, 2026

Every Alexa skill that collects personal information, uses account linking, or includes advertising needs a hosted privacy policy URL before Amazon will approve it for the Alexa Skills Store. The policy must live at a publicly accessible web address, load without authentication, and describe how the skill handles user data. Skip it and the skill fails certification. Submit a vague or boilerplate document and Amazon's review team rejects it just the same -- they read the policy, not just the URL.

This guide covers what Amazon's certification process actually checks, the data categories developers miss, what each section of your policy needs to say, and how to host the finished document and wire it into the Developer Console. If you need a policy fast, you can generate a privacy policy for free and host it at no cost.

Why Amazon Requires a Privacy Policy URL for Skills

Amazon treats the privacy policy as a gatekeeper for the Alexa Skills Store, similar to how Google Play and the Apple App Store require one for mobile apps. The requirement exists for three reasons.

User trust at the point of enablement. When a customer says "Alexa, enable [skill name]," they have no source code to inspect. No APK to decompile, no network tab to watch. The privacy policy is the only document telling them what data flows where and why. Without it, they are enabling a black box.

Regulatory compliance across jurisdictions. Alexa skills are available in multiple countries. A skill published in the US, UK, Germany, and India simultaneously falls under the CCPA, UK GDPR, EU GDPR, and India's DPDP Act. Amazon cannot audit every skill's data practices against every regulation, so it shifts that responsibility to the developer via a mandatory policy disclosure. The skill's privacy policy is the developer's statement of compliance.

Certification as a quality gate. Amazon reviews every skill before it goes live. The privacy policy URL is one of the fields the certification team checks. Amazon's certification requirements for the Alexa Skills Kit are blunt on this point: the policy section of the content guidelines states that any skill collecting personal information or using account linking "must include a link to a privacy policy that is specific to that skill" and that skills without this link "will fail certification." That is not a soft recommendation -- it is a hard gate. Skills that collect no personal data can optionally include one, but if they do, it still has to pass review.

Other non-mobile platforms enforce the same pattern. Google requires a hosted policy before listing a Chrome extension in its Web Store, and Discord blocks bot verification past 100 servers without a working policy URL in the Developer Portal. The requirement specifics differ, but the gating mechanism is identical: no policy, no distribution.

What Certification Checks

Amazon's certification team does not just confirm the URL field is populated. Reviewers open the link and verify several conditions before approving a submission.

• The URL loads directly to the policy text. The link must open to the actual privacy policy content -- not a homepage, not an "about" page, not a landing page that mentions privacy in a sidebar. URLs that redirect to a login wall, return a 404, or require scrolling past unrelated content fail review.
• The language matches the skill's locale. A skill submitted in en-US and de-DE needs a policy in English or German. Third-language policies get rejected.
• The content names the correct skill. A policy referencing a different skill name or developer than the submission is flagged immediately. Recycled templates from another product are a fast path to rejection.
• The page is publicly accessible. The policy must load on iOS, Android, and desktop browsers with no authentication, app install, or account creation required. Amazon's reviewers test across devices.

Why skills get rejected at certification

These are the specific failure reasons Amazon's reviewers cite most often in rejection notices:

• Privacy policy URL missing or broken. The field in Distribution > Skill Preview is blank, returns a non-200 status code, or redirects to a generic page.
• Form answers contradict the policy. The Privacy & Compliance page asks whether the skill collects personal information, targets children under 13, contains advertising, or allows purchases. If a developer checks "No" for personal-data collection but the policy describes storing user emails, the submission is rejected.
• Policy does not mention the skill's actual data practices. A boilerplate document that lists cookies and website analytics but never addresses voice data, account linking, or Alexa permissions fails the relevance check.
• Account linking enabled without corresponding disclosure. Skills that use OAuth to connect a third-party account must explain in the policy what profile data is retrieved and why. Missing this is one of the top rejection triggers.
• Policy hosted on an unstable URL. Google Docs links, Notion pages, and Pastebin URLs are rejected because they can change, require login, or display editing UI.

The Distribution section of the Developer Console also includes a Privacy & Compliance page with yes/no questions about data collection, children's content, advertising, and in-skill purchases. Every answer must match what the privacy policy states. Contradictions between the two are a common -- and avoidable -- cause of rejection.

Data a Skill Collects That Developers Overlook

Most developers disclose the obvious inputs: a name and email from account linking, a home address from the Device Address API. But Alexa skills handle several less obvious data categories that trip up certification.

• Voice utterances. Amazon's cloud processes audio and sends your backend the text transcription. Your interaction model captures every utterance directed at the skill. If your Lambda logs those transcriptions for debugging or analytics, that is personal data collection -- disclose it.
• User IDs and session identifiers. Every request includes a userId string tied to the Amazon account. Store it alongside usage data and you have a profile linked to a real person, even without a name or email. Session IDs track interactions within a single conversation.
• Device location. The Device Address API returns coarse location (country and postal code) or full street-level detail. If your skill uses location for any feature, that data flows through your backend and needs disclosure.
• Account linking data. Login with Amazon or any OAuth 2.0 provider gives your skill access to profile data -- name, email, sometimes phone. Developers sometimes treat this as "Amazon's data." It is not. The moment your backend queries the profile endpoint with that OAuth token, you are collecting personal information.
• Skill permissions data. Alexa offers granular permissions beyond account linking: customer name, email, phone, reminders, lists, location. Each granted permission sends data to your backend. Each one needs a corresponding line in the policy.
• Persistent attributes. The ASK SDK's persistent attributes feature (typically backed by DynamoDB) stores preferences, scores, or conversation history across sessions. Tied to a userId, that is personal data storage.

The rule is simple: if your Lambda function receives, processes, or stores anything that traces back to a specific user or device, disclose it. Not sure which privacy laws apply? A quick compliance check based on your platform and audience can clarify.

What Your Policy Must State

A compliant Alexa skill privacy policy covers the same ground as any app privacy policy, but scoped to voice interaction. Six sections do the heavy lifting.

• What data you collect. List every data type from the section above that applies to your skill. Be specific: "We receive your voice utterances as text transcriptions through Amazon's Alexa service" is useful. "We may collect certain information" is not. Include data collected through account linking, skill permissions, and persistent storage.
• Why you collect it. Map each data type to a purpose. Utterances power core functionality. A userId persists preferences. An email from account linking sends order confirmations. If you cannot name a purpose, drop the collection.
• Who receives the data. Name third-party categories: cloud infrastructure (AWS Lambda, DynamoDB), analytics providers, authentication services (Login with Amazon, third-party OAuth), and any other service your backend calls with user data.
• How long you keep it. Specify retention periods. "We retain persistent attributes while the skill is enabled and delete them within 30 days of disablement" is concrete and verifiable. Open-ended retention ("as long as necessary") invites regulatory scrutiny.
• User rights and how to exercise them. Under the GDPR: access, correction, deletion, portability. Under the CCPA: opt-out of data sales, deletion. List the rights that apply to your audience's geography and provide a contact email for exercising them.
• Children's privacy. If your skill targets users under 13, COPPA (US) and GDPR-K rules apply. The Developer Console asks whether the skill targets children -- the answer must match your policy. Not directed at children? State that explicitly.
• Contact information. A dedicated email for privacy questions. GDPR-covered user bases should also name a Data Protection Officer.
• Change notification. How you communicate policy updates: a bumped "last modified" date, an email to linked accounts, or a card through the Alexa app.

Worked example: a habit-tracker skill with account linking

Consider a skill called "Daily Habits" that lets users log habits by voice and view streaks in a companion web app. The skill uses Login with Amazon for account linking, stores habit entries in DynamoDB keyed to the userId, and requests the customer email permission so it can send a weekly summary.

That skill's privacy policy needs to disclose at least these data types and purposes:

• Voice utterances — transcribed by Amazon and sent to the skill's Lambda function to parse habit names. Logged for 7 days in CloudWatch for debugging, then deleted.
• Amazon userId — stored in DynamoDB alongside habit entries to persist streaks across sessions.
• Account linking profile data — name and email retrieved via Login with Amazon's OAuth token. Email used to send the weekly summary; name used to personalize Alexa responses.
• Customer email permission — separately granted through Alexa permissions, used as a fallback delivery address if the account-linked email is unavailable.

The policy also needs a retention statement ("Habit data is retained while the skill is enabled and deleted within 30 days of disabling"), a children's disclaimer (the skill is not directed at users under 13), GDPR and CCPA rights sections covering deletion and access requests, and a contact email. On the Privacy & Compliance page in the Developer Console, the developer must check "Yes" for personal information collection and "No" for children targeting, advertising, and in-skill purchases -- all matching the policy text.

Writing this from scratch takes time when a skill spans multiple data types and jurisdictions. The process mirrors writing a privacy policy for any app: audit your data flows, map them to purposes, identify third parties, and draft each section. A generator can compress that work into a guided form.

How to Generate an Alexa Skill Privacy Policy

Writing an Alexa skill privacy policy from scratch means auditing every data flow in your Lambda function, mapping each to a legal basis under every jurisdiction your skill reaches, and formatting the result into a document that satisfies Amazon's certification reviewers. For a skill that uses account linking, requests multiple Alexa permissions, and ships to several locales, that process can take hours of legal research and drafting.

A privacy policy generator compresses the work into a guided questionnaire. You select the platforms your skill runs on, the data types it handles (voice utterances, user IDs, account linking data, persistent attributes), the third-party services your backend calls, and the regulations you need to cover. The generator produces a policy with the correct disclosure language for each selection -- no boilerplate guessing, no missed data categories.

The output is typically a hosted document at a permanent HTTPS URL that you paste directly into the Developer Console's Privacy Policy URL field. That eliminates the separate hosting step and avoids the certification rejections caused by unstable URLs like Google Docs, Notion, or Pastebin links.

Generator vs. template vs. manual drafting

• Generator (fastest for complex skills). Best when your skill uses account linking, requests multiple permissions, or stores persistent attributes. A free privacy policy generator walks you through each data category and produces a ready-to-submit policy with hosting included. Use this path when you need to pass certification quickly without hiring a lawyer.
• Template (good for simple skills). If your skill has straightforward data practices -- no account linking, minimal permissions, no external APIs -- the sample policy below works after you replace the bracketed placeholders. Remove sections that do not apply and verify the result against the certification checklist above.
• Manual drafting (for edge cases). Skills that process health data, financial information, biometric identifiers, or children's data under COPPA may need custom legal language that neither a generator nor a template covers. Consult a privacy attorney for these cases, using the required sections list as a starting checklist.

Whichever approach you choose, verify the finished document against Amazon's certification requirements before submitting: correct skill name, every data category disclosed, Privacy & Compliance toggle answers matching the policy text, and a URL that loads on mobile and desktop without authentication.

Sample Alexa Skill Privacy Policy You Can Copy

Below is a complete privacy policy written for a fictional Alexa skill called "[Your Skill Name]." It covers the data categories most skills handle -- voice utterances, Amazon user IDs, account linking, skill permissions, persistent attributes, and children's privacy. Copy the entire block, replace the bracketed placeholders with your skill's details, and remove any sections that do not apply.

This sample covers the most common Alexa skill data flows. If your skill handles additional data -- such as health information, financial data, or biometric identifiers -- add dedicated disclosure sections for those categories. Need to generate a policy tailored to your exact data practices instead of editing a template? You can build one for free with the generator.

Privacy Policies for Private and Beta-Distributed Skills

Not every Alexa skill goes straight to the public Skills Store. Amazon offers two restricted distribution paths -- private skills and beta testing -- and each has its own rules around privacy policies.

Private skills (Alexa for Business)

Private skills are distributed through Alexa for Business to a specific organization rather than listed in the public Skills Store. They are typically internal tools: meeting-room booking, IT helpdesk queries, company directory lookups. Amazon does not subject private skills to the same public certification review that store-listed skills go through. However, a privacy policy is still strongly recommended for two reasons.

• Organizational compliance. The company deploying the skill is the data controller under GDPR or the business under CCPA. Even though Amazon does not enforce a policy URL at publishing time, the deploying organization's legal and compliance teams almost certainly require one. Enterprise procurement reviews routinely ask for a data-handling disclosure before approving any internal tool.
• Future distribution changes. A private skill that later moves to the public Skills Store will need a privacy policy to pass certification. Writing it during initial development, when the data flows are fresh in mind, is faster and more accurate than reverse-engineering them later.

Beta testing

Amazon's beta testing feature lets developers invite up to 500 users to test a skill before public release. Beta skills must still pass a certification review before testers can access them, and that review includes the same privacy policy checks as a public submission. If the beta skill collects personal data or uses account linking, the privacy policy URL field must be populated and the policy must pass the same relevance and accessibility tests described earlier in this guide.

The practical difference is scope, not requirements. Beta certification checks the same boxes -- working URL, content that matches the skill's data practices, consistency with the Privacy & Compliance page answers. The only thing that changes is the audience size. Do not skip the policy for a beta build assuming you will add it later; the certification gate blocks beta distribution just as it blocks public distribution.

What certification checks for unpublished skills

Whether a skill is headed for the public store, a beta group, or a private organization, Amazon's certification review evaluates the same core criteria whenever the skill passes through it:

• The privacy policy URL returns a 200 status and loads directly to the policy text on mobile and desktop.
• The policy names the skill and describes its actual data collection practices.
• The Privacy & Compliance toggle answers (personal data collection, children's content, advertising, in-skill purchases) are consistent with the policy text.
• If account linking is enabled, the policy explains what profile data is retrieved and why.

Private skills distributed solely through Alexa for Business bypass this gate, but every other distribution path -- public, beta, or organization-restricted through the Developer Console -- goes through it. Plan the policy at the start, not at the submission deadline.

Where to Host the URL and Add It in the Developer Console

The privacy policy needs a permanent, publicly accessible URL. Three hosting approaches cover most Alexa skill developers.

Hosting options

• Your own domain. If you have a website, host the policy at a path like yoursite.com/alexa-privacy-policy. This is the most professional option and gives you full control over updates.
• A free hosted policy. If you do not have a website or do not want to manage hosting, you can generate and host a privacy policy for free. The generated URL is permanent and loads without authentication, which satisfies Amazon's certification requirements.
• GitHub Pages or a static site. A free GitHub Pages site with a single HTML page works. The URL is stable and publicly accessible. Just ensure the page renders properly on mobile, since Amazon's review team checks across devices.

Do not use Google Docs, Notion pages, Pastebin links, or any URL that requires login, displays editing UI, or could change without a stable permalink. Amazon's certification team will reject these.

What the Privacy Policy URL field requires

The Privacy Policy URL field under Distribution > Skill Preview accepts a single, fully qualified URL starting with https://. The console validates URL format when you save the page but does not verify that the URL actually loads -- that verification happens during the certification review. Several format requirements catch developers who fill the field correctly but still fail at review.

• HTTPS only. HTTP links are rejected. If your current hosting does not support HTTPS, switch to a provider that does -- most static hosting platforms and free policy hosting tools include SSL certificates by default.
• Direct link to the policy text. The URL must resolve to the privacy policy content itself. A URL pointing to your homepage with a "Privacy" footer link does not count, even if the policy is one click away. Reviewers expect the policy text to appear immediately when they open the link.
• No authentication or interstitials. The page must load on any device, in any browser, without login, cookie-consent walls that block content, age gates, or app-install prompts. Amazon tests on iOS, Android, and desktop.
• Stable permalink. The URL must remain live for as long as the skill is published. If the link breaks during a periodic re-review, Amazon can unpublish the skill until the URL is fixed. Avoid URLs tied to free-tier services that expire or document-editor links that change when sharing settings are modified.

For multi-locale skills, you submit one URL per locale. You can reuse the same URL across all locales if the policy language matches at least one of the skill's supported languages, or provide locale-specific URLs for policies translated into each language.

Adding the URL in the Alexa Developer Console

1. Open the Alexa Developer Console and select your skill.
2. Click the Distribution tab in the left sidebar.
3. Under Skill Preview, find the Privacy Policy URL field near the bottom of the page. Paste your full URL including https://. The console validates that the field contains a properly formatted URL but does not check whether the page actually loads -- that happens during certification review.
4. Click Privacy & Compliance in the left menu under Distribution. This page presents yes/no toggles: "Does this skill collect users' personal information?", "Is this skill directed to or does it target children under the age of 13?", "Does this skill contain advertising?", and "Does this skill allow users to make purchases?" Each answer must match what the privacy policy states. Contradictions between this page and the policy are one of the most common rejection triggers.
5. For multi-locale skills, verify the privacy policy link loads for each locale and that the policy language matches at least one of the skill's supported languages.
6. Save and submit for certification.

After approval, the privacy policy link appears on your skill's detail page in the Alexa Skills Store. Customers can review it before enabling the skill.

Frequently Asked Questions