"Does it have an API?" is a question that should have a yes-or-no answer. In practice, it rarely does. Ask five audio guide vendors and you'll get five different definitions of what an API is, ranging from a documented REST interface to the entire content graph, down to a weekly CSV dump they email you on Mondays.
If you're the developer, solutions architect, or digital lead who has to live with that decision, the definition matters. A real API is the difference between the audio guide being part of your stack and being a silo with your content trapped inside it.
What vendors actually mean by "API"
I've sat through too many vendor demos where the word "API" gets thrown around without anyone clarifying what it means. Three common patterns:
The real API. Documented REST or GraphQL endpoints that cover the same surface area as the vendor's own admin UI. You can list tours, create stops, update translations, publish changes, subscribe to events. Authentication is standard (OAuth, API keys with scopes, service accounts). The docs are on a public URL. Rate limits are published. There's a changelog.
The read-only export. A CSV or JSON download, usually on a schedule. Sometimes a single endpoint that returns the full content tree. You can see your data. You can't do anything to it through the API. Any change has to happen in the vendor's admin UI or via a support ticket. Vendors will still call this an API in a sales deck.
The "contact us." No public API. Integrations are bespoke professional services engagements. Every connection to another system is scoped as a custom project with a statement of work and a five-figure price tag. The vendor may eventually build you a webhook, but it belongs to your contract and nobody else's.
The first is an actual API. The second is a data export with a dressier name. The third is the absence of an API framed as a feature.
The easiest way to tell them apart isn't to ask the vendor. It's to ask for the link to the public API docs. Real APIs have docs at a URL you can bookmark. Fake APIs have a slide deck.
Why this matters past the buzzword
The reason to care isn't purist. It's that museums with real APIs can do things museums with fake ones can't.
The obvious one is CMS sync. Your collection management system already holds object metadata, curatorial text, provenance, conservation notes, images. If the audio guide has write endpoints for objects and translations, you can build a small sync service that pushes CMS changes into the guide automatically. No double data entry, no drift between the wall label and the guide, no curator sending updated copy to a vendor account manager via email.
The less obvious one is content reuse across sites. A national institution with ten regional venues, or a heritage trust with thirty properties, wants to write a piece of content once and have it appear everywhere it's relevant. That's impossible if the audio guide doesn't expose its content graph to you. It's trivial if it does.
And then there's the one nobody wants to say out loud: data portability. If you can read every tour, stop, object, and translation out of the vendor's system programmatically, you're not locked in. The day you decide to switch vendors, your content comes with you. If the only way to get it out is to screenshot the admin panel, you're trapped, and the vendor knows it.
What a real API looks like
The surface area isn't complicated. A competent museum audio guide API exposes roughly this:
GET /tours, POST /tours, PATCH /tours/:id, DELETE /tours/:id — list, create, update, and remove tours.GET /tours/:id/stops, POST /tours/:id/stops — manage the ordered stops within a tour.GET /objects, POST /objects, PATCH /objects/:id — manage the underlying works, artifacts, or points of interest that stops reference.GET /translations, PUT /translations/:objectId/:lang — read and write localized content per object and language.POST /tours/:id/publish and POST /tours/:id/unpublish — control what's live on the visitor-facing guide.GET /events or webhook subscriptions for visit events: tour started, stop opened, question asked, completion. Push, don't poll.GET /analytics/... for aggregate engagement data, with filters by date, tour, language, and site.
None of this is exotic. It's the same shape as any modern SaaS API. The test isn't whether the endpoints are clever. It's whether they exist, whether they're documented, and whether they cover both read and write.
The write side is where most vendors fall apart. A lot of platforms will happily let you read your content. Far fewer let you create or update it programmatically, because that would mean their admin UI isn't the only way in, and their services team isn't the gatekeeper for content work.
Two use cases that justify the whole thing
Two scenarios I've seen repeatedly make the API argument concrete.
A national institution syncing from the collection management system. A large museum has 80,000 objects in TMS or Axiell. They want the audio guide to know about every object, with metadata that stays current when conservation updates a date or curatorial corrects a provenance. Without an API, this is impossible. With one, it's a nightly sync job. One engineer, two weeks, and every guide update flows from the source of truth automatically. The museum never edits content in two places.
A multi-site network propagating a headquarters update. A heritage trust with thirty properties centrally commissions a new piece of content about, say, a restoration technique used across several sites. With an API and a small script, that content gets pushed as a stop into every relevant tour, translated into all supported languages (via whatever translation workflow the trust uses), and published in one batch. Without an API, it's thirty tickets to the vendor's support queue, each taking a week, each one slightly different because different account managers handle them.
These aren't theoretical. They're the reason the API question belongs near the top of an RFP, not buried in the technical appendix.
What to put in the RFP
If you're writing or reviewing a request for proposals, a few things to demand explicitly rather than leaving for the reader to interpret:
- Public API documentation URL. Not "available on request." If they can't link to docs, the API isn't a product, it's a promise.
- Full CRUD on tours, stops, objects, and translations. Named explicitly. Read-only counts as no.
- Webhooks for visit and content events, with a list of supported event types.
- Authentication model. OAuth, API keys with scopes, service accounts. How do you rotate credentials. How do you grant a sync service access without giving it a human's login.
- Rate limits, published. And what happens when you hit them.
- A sandbox or test environment you can hit without affecting production.
- An SLA on the API, separate from the SLA on the visitor app.
If a vendor can't meet all of these, they don't have an API. They have a roadmap item. That's fine as a starting point for a conversation, but it shouldn't pass as a yes in a procurement scorecard.
For the rest of the integration picture beyond raw API access — ticketing, analytics, single sign-on — the museum systems integrations guide covers how the API plumbs into the surrounding stack. And if you're trying to figure out where API capabilities sit in a vendor comparison, the RFP guide has the scoring framework we use.
Questions to ask in a vendor demo
Demo calls drift toward pretty screens. Pull them back to the API with specifics. A few questions that separate real capability from marketing:
- Can you show me the API docs right now, on screen?
- Here's a sample object from our CMS. Can you write it into a tour via the API during this call?
- What's the webhook payload when a visitor completes a tour? Can you paste an example?
- If I need to delete all personally identifiable data for a visitor, is there an endpoint for that? (This one matters for GDPR.)
- How do you version the API? What's your deprecation policy?
- If I want to build a custom staff tool on top of your API, do I need your permission, or is it covered by the standard license?
The last one is the most revealing. Some vendors contractually restrict what you can build against their API, which effectively means you don't have one. If their answer involves a conversation with their legal team, the API isn't for you, it's for their partner ecosystem.
The pricing question
This is where I'll take a position that some vendors won't like.
If an audio guide platform charges extra for API access — as a separate line item, as an enterprise tier, as professional services — that's pricing that belongs to an older business model. Legacy vendors sold museums a fixed platform at a fixed price, recouped the build cost in the first contract, and then treated every additional capability as pure margin. API access, extra languages, analytics dashboards, custom integrations: all upsells on a product that had already paid for itself.
That model assumes the vendor's incentive is to extract more revenue per customer over time. Per-interaction and revenue-share pricing flip that incentive. If the vendor makes money when the guide gets used, they want the guide integrated with your website, your ticketing, your CMS. They want your content to stay fresh. They want you syncing, pushing, automating. Every API call you make to keep your content current is an investment they're happy to underwrite, because it pays back in engagement.
The tell is simple. Ask a vendor: "is API access included in the base price?" If the answer is no, you're looking at a platform where the vendor's margin comes from gating capability. If the answer is yes, their margin comes from the guide performing well. Those are different products with different futures.
What we've built
Musa exposes a documented REST API covering tours, stops, objects, translations, publish controls, and webhooks — the same surface our own Studio uses. It's included in every plan, because our pricing is per-interaction or revenue-share: we make money when your guide gets used, so integrating it with your ticketing, your CMS, and your analytics is in our interest, not a feature we'd price separately.
If you're evaluating vendors and want to see what a real API looks like against whatever you're currently being offered, we're happy to put ours side by side with whatever's in your shortlist. Bring the endpoints. Bring the docs. It's a short conversation either way.