Catalog API

Build with ChasteGPT Data

ChasteGPT runs the largest structured catalog of male chastity devices anywhere — deduplicated, normalized, and continuously updated. The Catalog API v1 hands your app clean product records with brands, images, canonical links and community ratings, over a versioned, key-authed REST endpoint.

7,091 Devices
73 Brands
19,981 Reviews analyzed

The data

Every record is a real device from our public catalog — the same junk-filtered, deduplicated set that powers our product pages and sitemap. Fabricated failed-scrape rows and accessories are excluded, so you get roughly 7,091 genuine devices across 73 brands. Each record carries the product name, brand slug, category, image URL and provenance, a canonical link back to our page, and — where we have one — a community rating.

The ratings

Ratings are distilled from 19,981 human-verified community reviews — real wearer experience, sentiment-scored and rolled up to a 0–100 score per device. You get the number and the mention count; the underlying reviews stay with us.

The review corpus stays internal — partners get the scores; we keep the receipts.

How it works

Versioned & key-authed

Read-only REST under /api/v1. Send your key in the X-API-Key header on every request.

Cursor pagination

Walk the whole catalog by following meta.next_cursor until it comes back null.

Delta sync

Pass updated_since to pull only what changed — nightly syncs stay small and cheap.

Cacheable

ETag + Last-Modified on every response, with 304 support and sensible rate limits.

Attribution & images

Two requirements keep the data honest. Attribution: show the per-record “Data from ChasteGPT” credit, linked back to the canonical page, next to each device you display. Images: mirror image_url to your own storage rather than hotlinking ours — the image_source field tells you provenance so you always know what you're rendering.

Who's building on it

Launch partnerships in progress — check back soon.

Get access

Keys are issued to vetted integrations. Email us and tell us:

  • What you're building — the app or feature the data will power.
  • Expected volume — rough request rate and how often you'll sync.
  • Where the data renders — the site, app or surface it will appear on.
Request API access