AppReviewFix
Guideline library
Apple App Store — Legal

5.2.2 — Third-party sites and services

Official source: App Store Review GuidelinesTopic overview: Content, user safety and legal rights
What this guideline means

Apps that pull in, embed, or build functionality around another company's site, API, or product beyond a standard public API need to show they have permission from that third party — Apple may ask for a letter or written authorization.

Why apps actually get flagged

Commonly triggered by apps that scrape or wrap another company's website or service without any formal agreement in place.

A real example

"Your app integrates content or services from a third party, but we could not confirm you have appropriate permission to do so, per guideline 5.2.2."

The short version, in more detail

Guideline 5.2.2 covers apps that rely on another company's site, API or product in ways that go beyond a standard public interface. In those cases the developer needs to show that they have permission, and Apple may ask for written authorisation. It commonly appears when an app scrapes or wraps another company's website without any agreement.

Why this rule exists

A service that depends on another company's platform can stop working or cause legal disputes if that company objects. For users, an app that is later cut off becomes useless. For the third party, an unofficial client may violate terms, bypass controls or harm the service. Asking for permission keeps apps built on others' services on solid legal and practical ground.

What this guideline covers

  • Apps that wrap or scrape another company's website or service.
  • Use of private or restricted APIs.
  • Written permission or agreements with the third party.
  • Compliance with the other service's terms.

What usually triggers this rejection

  • A client for a service that has not authorised third-party apps.
  • Scraping a website and presenting its data as the app's own.
  • Using an API outside the terms of its provider.
  • Presenting an unofficial wrapper as an official product.
  • Cutting across another platform's access controls.

How reviewers evaluate it

  • Reviewers identify dependencies on other companies' services.
  • They may ask for documentation of permission.
  • They respond to complaints from the affected company.
  • They check whether the app presents itself as official.

Common misunderstandings

  • Public data is not automatically free to scrape and republish.
  • A popular API still has terms that limit how it may be used.
  • Permission is expected for unofficial clients.

Common questions

Do all API-based apps need permission?

Standard use of a public API under its terms usually does not need special permission.

What counts as written authorisation?

A letter, agreement or other document from the third party.

Can I make an unofficial app?

Only if it respects the third party's terms and does not mislead users.

Platform rules change often. This page is a plain-language explanation written by AppReviewFix, not official guidance. Check the current App Store Review Guidelines for the exact wording.

Got this exact rejection?Paste it in and get a diagnosis specific to your app, free.
Decode my rejection
Related guidelines
Intellectual Property — Intellectual property infringement5.2.1 — Third-party intellectual property5.2.3 — Audio and video downloading5.1.1 — Data Collection and Storage5.1.2 — Data use and sharing
AppReviewFix
ProductDecoderPricingGuideline library
CompanyAboutFAQContact
ResourcesGuidesTopic overviewsCommon rejection reasons
LegalTermsPrivacy
© 2026 AppReviewFixBuilt by a developer, not a committee.