Your site. Our inventory. One source of truth.
You already have a website you like. GalleryCamp feeds it — available works, artists, exhibitions and events, live from the same records your gallery runs on. Inquiries submitted there post straight back against the right artwork.
No rebuild. No migration of your design. No agency re-engagement.
The reference is public. No account needed to read it.
$ curl https://api.gallerycamp.com/api/public\
/galleries/YOUR_SITE/artworks?status=AVAILABLE
{
"success": true,
"data": [
{
"id": "clx8k2p0004",
"title": "Meridian",
"year": 2024,
"medium": "Oil on linen",
"dimensions": "152 × 122 cm",
"price": 18000,
"currency": "USD",
"status": "AVAILABLE",
"artist": { "name": "Elena Vasquez" },
"images": [{ "url": "https://…/meridian.jpg" }]
}
],
"meta": { "total": 47, "page": 1, "limit": 20 }
}No key, no secret in the browser. The site feed is read-only, CORS-enabled, and returns only what the gallery has published.
Counted from the published specification, generated 2026-09-16.
Two ways in, and they are deliberately different
One is safe to call from a visitor's browser. The other is not, and the difference is enforced rather than documented.
No key required
Addressed by site rather than by secret, so your front end calls it directly from the browser with nothing to leak. It returns only what that site is configured to show — a gallery running a main site, an artist microsite and a fair page gets three different answers from the same inventory.
Internal prices, collector records, costs and notes are not on this surface at all. It cannot leak them because it never loads them.
Scoped keys
Everything the dashboard can do — inventory, consignments, collectors, orders, payouts, reporting. Your team creates and revokes keys themselves in Settings → Access Keys. No sales call, no partner programme, no waiting.
curl https://api.gallerycamp.com/api/artworks \ -H "x-api-key: gc_live_…"
- Every key is scoped to one gallery and cannot see another
- Revoke a key and it stops working immediately
- Actions are attributed in the audit log like any other
The loop that closes
An inquiry form on your own site is usually a mail to an inbox. Somebody reads it, works out which work it is about, and types the collector into whatever system the gallery keeps.
Post it here instead and it arrives as an inquiry against that artwork, attached to that collector, in the same desk your team already works from. It shows up in the pipeline. It counts in the reporting.
Which is the same loop our own viewing rooms close, reaching a site we did not build.
POST /api/public/sites/YOUR_SITE
/artworks/clx8k2p0004/inquiries
{
"name": "Marta Reyes",
"email": "marta@example.com",
"message": "Is Meridian still available?"
}
→ 201 Created
{
"success": true,
"data": {
"id": "inq_9f22a1",
"status": "NEW",
"artwork_id": "clx8k2p0004"
}
}You built the site. You should not have to rebuild it.
Gallery software in this category tends to arrive with its own website attached, sold as a build. That is a reasonable business and a bad fit for a gallery whose site you designed last year.
Here the website is a settings screen if the gallery wants one, and an API if they do not. Both read the same inventory. A gallery can run yours and ours side by side — a fair microsite on ours, the main site on yours — and the reporting still answers which one is selling an artist, because every read is recorded against the site that served it.
The reference is published openly at /docs/api. Read it before you talk to anyone, and decide whether this is worth your client's time.
Included on every plan. Not an add-on, not a tier.
The API is part of the product at every price, because a gallery that keeps its own website is not getting less of GalleryCamp — it is using it the way it was built to be used.