Art & Design — entry 015 of 20
Metropolitan Museum of Art
The Met's Collection API exposes all 502,000+ objects in its Open Access collection — the same data behind its own site — fully keyless and free, asking only that callers self-throttle to 80 requests per second. A live GET against the real gateway, collectionapi.metmuseum.org, returned genuine object data carrying Access-Control-Allow-Origin: *, correcting cors no -> yes while reconfirming auth None.
The Met's Collection API exposes all 502,000+ objects in its Open Access collection, fully keyless and free. It's deliberately two-step: `GET /search` never returns object data, only a bare array of matching IDs, so every real lookup is a search followed by one `GET /objects/{objectID}` fetch per result you actually want. A live GET this run against `/search?q=sunflowers` returned 98 matching IDs; a follow-up `GET /objects/{objectID}` on one of them returned the full record.
GreatAPIs Score
Embed this badge
<a href="https://greatapis.com/api/metropolitan-museum-of-art/"><img src="https://greatapis.com/badge/metropolitan-museum-of-art.svg" alt="Scored 74 on greatapis.com"></a>Auth quickstart
- No API key, signup, or credit card required. A live GET this run against a real object record returned genuine data, and an Origin-header probe against the real gateway returned `access-control-allow-origin: *`. There is no token to obtain, but the rate limit is published rather than absent: the Met's own docs state "we do not require API users to register or obtain an API key to use the service. Please limit request rate to 80 requests per second" -- self-throttling guidance, not an enforced quota with headers to read.
Your key is stored only in this browser (localStorage) and sent directly to the API — never to greatapis.
Search for objects, then fetch one full record
GEThttps://collectionapi.metmuseum.org/public/collection/v1/search?q=sunflowers
{"total":98,"objectIDs":[436524,484935,437112,431264,397949,656530,480725,486590,485308,375281,"88 more IDs, same shape"]}The search response carries no titles, images, or artist names -- only IDs. A live follow-up `GET /objects/436524` this run returned the actual object record (title, artist, images, dates); the search step alone is never enough to render a result.
Try it
Developer reference
https://collectionapi.metmuseum.org/public/collection/v180 requests/second (self-throttling guidance, not an enforced quota)
- GET/objects/{objectID}
- GET/search?q={query}
- GET/departments
Gotchas & limits
- A no-match search returns `null`, not `[]`, for `objectIDs` -- a live GET this run against `/search?q=zzzzznomatchxyz123` returned `{"total":0,"objectIDs":null}`. Code that calls `.length` or `.map()` on `objectIDs` unconditionally will throw on a genuinely empty result, not just skip a loop.
- `GET /objects` (no filter) doesn't paginate -- a live GET this run confirmed it returns all ~502,000+ object IDs in one multi-megabyte response with no `limit`/`offset` params to shrink it. Always filter through `/search` or `/objects?departmentIds=` first.
- A nonexistent object ID 404s with a minimal, non-standard body -- a live GET this run against `/objects/999999999` returned HTTP 404 `{"message":"ObjectID not found"}`, a different shape from the search endpoint's error-free `null`.
- CORS is not advertised on a plain request -- a live GET this run with no `Origin` header returned no `access-control-allow-origin` header at all, while the identical request with `Origin: https://example.com` set returned `access-control-allow-origin: *`. Code that checks for the header on a bare curl probe will wrongly conclude CORS is closed.