Parental Control SDK Category Data
Your SDK ends up inside other companies' products: a carrier's family app, a tablet maker's kids mode, a router's companion app. Each of them expects the same thing from you: a filter that blocks the right sites on day one and stays current.
This guide covers what category data an SDK needs, how to package it, how to keep it fresh with regular refreshes, and how licensing works when your customers ship your code.
What a parental control SDK needs from category data
An app team can tune its own filter by hand. An SDK team cannot, because the same code runs for dozens of partners and millions of families it never talks to. The data has to carry more of the load.
Breadth from the first install
120 million categorized domains, with the 20 million most visited covering 99.99% of web traffic. Partners judge your SDK on the sites children actually open, not on a test list.
A small device footprint
Partners care about app size and memory. You need a data layout you can cut down to the most visited domains on the device, with the rest resolved in the cloud.
Several labels per domain
A domain can carry several categories, ranked by how much of the site they describe. That lets a strict profile block a site for its second label while a teen profile allows it.
Fresh new domains
Children find new game mirrors, proxy sites and AI chat tools quickly. Daily delta files keep newly registered domains flowing into every partner build.
A stable category set
Your partners build settings screens on your category names. A fixed set of 59 categories means their UI does not break when the data updates.
Licensing that fits embedding
An OEM licence lets the data run inside your SDK and your partners' products, while the raw file stays protected from resale or publication.
Which categories matter in a child safety SDK
Most SDKs expose a short list of parent-facing switches and map them to the underlying categories. The table shows a common starting point. Your partners can then make it stricter or looser per market. Browse the full web filtering category list for definitions.
| Category | Why SDK partners care | Typical under-13 default | Typical teen default |
|---|---|---|---|
| Adult | The core promise of any family product. A miss here becomes a support ticket and a store review. | Block, locked | Block, locked |
| VPN / Proxy / Anonymizers | The most common way a child gets around the filter. Blocking it protects every other rule. | Block | Block |
| Gambling | Includes betting and casino sites that look like games to younger users. | Block | Block |
| Dating | Often an age-restricted service by its own terms; parents expect it off. | Block | Block |
| Social Networking | The most requested parent switch, often tied to time limits rather than a hard block. | Block | Parent choice |
| AI / LLM Tools | Parents ask about chatbots, AI companions and image generators. Separate AI tool categories allow fine control. | Block | Parent choice |
| Gaming | Usually allowed with time rules. Separating it from Gambling avoids blocking harmless games. | Time limited | Allow |
| Streaming Media | A bandwidth and screen time topic for many families, rarely a safety one. | Time limited | Allow |
| Weapons, Violence, Hate/Discrimination | Content parents rarely want young children to see, and a common market requirement. | Block | Parent choice |
| Alcohol, Tobacco, Illegal Drugs | Age-gated products in many countries. Often grouped as one parent switch. | Block | Block |
| Education/Reference | The allow side matters too. A good SDK keeps homework sites open even on strict profiles. | Allow | Allow |
| Malware / Phishing / Suspicious | Children click everything. Security blocking is a quiet feature parents value. | Block, locked | Block, locked |
Offline database, lookup API, or both
Where the category data lives decides your SDK's speed, size and privacy story. There are three common layouts, and most mature SDKs end up on the third.
Offline database only
You ship a compact index with the SDK and refresh it through your own update channel.
- Works with no connection
- No browsing data leaves the device
- Lookups take microseconds
- Size grows with coverage, so the long tail is cut
Cloud lookup only
The SDK sends each new domain to your backend, which holds the full database or calls the lookup API.
- Tiny SDK, full coverage
- Category changes apply at once
- Adds a network round trip
- Needs a clear privacy notice for partners
Both, in tiers
Most visited domains on the device, everything else from your cloud, with a short cache in between.
- Most lookups never leave the device
- Full coverage for rare domains
- Graceful offline fallback
- One update pipeline feeds both tiers
Packaging category data inside an SDK
The licensed file arrives as CSV, Parquet or JSON. Nobody ships that straight to a phone. SDK teams convert it into a compact index sized for the device class each partner targets.
Smallest index. Ship the most visited domains in the blocked and always-allowed categories only, and resolve the rest in the cloud. Store category IDs as small integers.
Mid-sized index of the most visited domains across all 59 categories, with the top two or three ranked labels per domain. Cloud lookup handles anything not found locally.
Large index, because routers serve the whole household and often have flash to spare. Many router partners prefer a DNS-level list in one of the blocklist formats.
The full 120 million domain set in your own database, loaded from the files, updated by daily deltas, and queried by every device that misses locally.
Protect the file on device
Encrypt or obfuscate the local index so a curious user cannot pull a full category list out of the app package. This is also part of keeping to the licence terms.
Match on parent domains
Look up the full host first, then walk up to the registered domain. That way subdomains inherit a category unless they carry their own.
Decide the unknown rule
Pick a default for domains with no answer yet: allow and log, ask the cloud, or block on strict profiles. Make it a setting partners can change.
Update cadence: regular refreshes through your own channel
Your SDK probably cannot force partners to ship a new app version every week. So the category data needs its own update path, separate from code releases.
Delta files
About 300,000 newly registered domains are categorized daily. Push them to your cloud at once and to device indexes in a small daily patch.
First recheck
New domains are checked again after a week, because many sites only add real content after launch. Changed labels arrive in the deltas.
Second recheck
A further check after a month catches parked domains that turned into real sites, and sites that changed purpose.
Full refresh
All other domains are refreshed monthly. Rebuild device indexes from the refreshed file and roll them out in stages.
Integration steps for SDK teams
A typical integration takes the data from a licensed file to a working SDK feature in eight steps. The order matters: lock the category mapping before you build any partner UI.
- Map categories to parent switches
Group the 59 categories into the handful of switches parents see. Keep the mapping in config, not code, so you can change it without a release.
- Load the full file into your cloud store
Import the CSV or Parquet file into the database your backend already uses. Index on domain and keep the ranked category list per row.
- Wire the delta job
Schedule a daily job that applies delta files to the cloud store and produces a device patch. Log counts so you notice a missed day.
- Build the device index
Cut the full set down per device class, convert to your compact format, sign it, and publish it to your update channel.
- Add the lookup path
On a local miss, the SDK asks your backend. The backend checks its store, then the included lookup API for anything still missing.
- Apply the policy
Combine the ranked categories with the active age profile and any parent overrides. Overrides always win over category defaults.
- Expose partner settings
Give partners an API to set default profiles per market, lock certain categories, and add their own allow and block entries.
- Test before every rollout
Run a fixed domain test set through each build, check the decisions against expected results, and only then release the new index.
Multi-partner policy design
An SDK serves several partners, each with its own brand, market and legal advice. Good policy design keeps one dataset and many policies, so you never fork the data per partner.
Layer 1: locked categories
Categories no partner can switch off, such as Adult and Malware / Phishing / Suspicious. This protects your own brand when a partner ships a careless default.
Layer 2: partner defaults
Each partner sets age profiles for its market. A carrier in one country may block Social Networking for under-13s, another may only time-limit it.
Layer 3: family settings
Parents adjust within what the partner allows. Keep this to switches, not raw category lists, so the UI stays simple.
Layer 4: per-domain overrides
A parent allows one school portal or blocks one game. Store overrides by domain, apply them first, and keep them on the device for offline use.
For more on structuring rules, see custom policy management and the broader guide to parental controls filtering.
Quality checks before a partner release
Partners will test your SDK with their own lists before launch. Run the same kind of checks first, on every data update, so nothing surprises them.
- Top children's sites resolve to the expected categories
- Homework and school portals stay allowed on strict profiles
- Known proxy and VPN sites are blocked on every profile
- Search engines are not blocked by mistake
- Subdomains inherit from the parent domain where expected
- The device index loads within your memory budget
- Lookups on a local miss return within your latency target
- Offline mode applies the right unknown-domain rule
- Parent overrides beat category defaults in every case
- The delta job ran on each of the last seven days
Privacy design partners will ask about
Children's data rules are strict in most markets, and partners will ask how your SDK handles browsing data before they sign. The data layout gives you most of the answers.
Local first
With a device index, most lookups happen on the device and no domain leaves it. Say this plainly in the partner documentation, with the share of lookups that stay local.
Minimal cloud requests
On a local miss, send only the domain, never the full URL, path or search terms. Strip user IDs from the lookup and keep it separate from account data.
Short cache, short logs
Cache cloud answers on the device so repeat visits stay local. Keep server lookup logs short and aggregate them for quality work.
Air-gapped option
The files run fully inside your own systems, so partners with strict rules can host the full set themselves and send no lookups outside their network.
How the SDK question differs from building one app
If you ship a single family app, the guide on a parental control app category database covers your case. The SDK case adds a few constraints.
| Topic | Single family app | Parental control SDK |
|---|---|---|
| Who sets defaults | Your product team | Each partner, within your locked rules |
| Device range | Your supported phones | Phones, tablets, watches, routers, TVs |
| Update path | Your app release cycle | Separate data channel, independent of partner releases |
| Privacy notice | Your own policy | Text your partners can adopt for cloud lookups |
| Licence | OEM for one product | OEM covering your SDK and its partner deployments |
| Support load | Parents contact you | Partners forward edge cases to you in bulk |
Licensing category data for an SDK
Because your code runs inside other companies' products, an internal-use licence is not enough. The OEM licensing page explains the model in detail.
OEM / embedded
The data runs inside your SDK, your cloud and your partners' deployments. Partners get decisions and categories for single lookups, not the raw file.
Group-wide
For companies with several products, such as an SDK plus a direct consumer app and a router line. One licence covers the group.
What is not allowed
Resale or publication of the raw data, for example offering partners a downloadable category file of their own.
Parental control SDK questions
Can we embed the category data inside an SDK that other companies ship?
Yes, under an OEM licence. The data runs inside your SDK and service. Your SDK customers get filtering decisions, not a copy of the raw data, and resale or publication of the raw data is not allowed.
How large is an on-device category file?
It depends on how many domains you ship. Most SDK teams put a compact index of the most visited domains on the device and send the long tail to a cloud lookup. The 20 million most visited domains cover 99.99% of web traffic, so even a subset of them covers most real browsing.
How often does the data change?
About 300,000 newly registered domains are categorized every day and delivered as daily delta files. New domains are checked again after a week and after a month, and all other domains get regular monthly refreshes.
Do you supply age profiles for the SDK?
We supply 59 web filtering categories plus the IAB Content Taxonomy in one file. SDK teams define their own default age profiles on top and let each partner adjust them.
Is a lookup API included?
Yes. A lookup API is included with licences, so your SDK backend can resolve domains that your local index does not hold.
Can the SDK work with no network connection?
Yes, if you ship an on-device index. Lookups against the local index work offline, and the SDK can apply a default rule for unknown domains until the device reconnects.
Put dependable category data inside your SDK
Tell us which device classes and how many partners your SDK serves. We will suggest a layout and an OEM licence that fits.
License the database Read about OEM licensing