The ThinkReservations API lets you automatically pull some of your property's data from ThinkReservations, so developers can build custom reports or connect ThinkReservations to external tools.

It is available on every plan at no additional cost, and you can set it up yourself. This article explains what the API can do so you can decide whether it's the right fit. If you've already decided to move forward, see Creating and Managing API Keys for step-by-step setup.

Custom reporting. If you want a metric, a breakdown, or a format our built-in reports don't produce, you can pull the underlying data and build exactly the report you want.

Feeding your own systems. Send your reservation data into your own database, spreadsheet, accounting workflow, or a business intelligence tool such as Power BI, Tableau, Looker, or Google Data Studio.

One-way data feeds to other tools. Pull your data from ThinkReservations and deliver it elsewhere for your own use.

Work with a developer you already have. Many properties already work with a web developer or agency, or have a technically-minded owner or manager. The API puts the work in their hands rather than yours.

The API is a connection point for software, not a feature with a user interface. There is nothing to click, nothing to configure beyond creating a key, and no report waiting on the other side. Someone has to build something.

That person needs to be comfortable writing code and reading technical documentation. If you don't have someone in-house, a web developer, a contractor, or an agency you already work with can usually do this. Our full technical documentation is public at developers.thinkreservations.com, so you can send it to a developer before committing to anything and let them tell you whether what you want is possible.

ThinkReservations does not build reports or integrations for you, nor do we write or maintain your code. See Getting help below for what we do support.

It's read-only, with one exception. Data flows out of ThinkReservations. The only thing the API can change in your account is your daily rate configuration — pricing and availability rules. Everything else is read-only.

It can't create, modify, or cancel reservations. This isn't something we expect to change in the near or medium term. If your goal depends on another system creating or updating reservations in ThinkReservations, the API won't get you there.

It can't push data into ThinkReservations. Apart from daily rates, nothing can be written in. Before you invest development time, it's worth asking which direction your data needs to flow — if the answer is "into ThinkReservations," the API likely isn't the right tool.

There's no single export of everything. Reservation requests require a date or timestamp range, and results come back in pages. A developer expecting one request to return your entire reservation history will need to page through the results instead.

It doesn't cover everything in the PMS. The API covers the areas listed above, not every feature of the system.

It isn't a live sync. See below for more on that.

Your integration requests data whenever it's built to ask — this is called polling. The data you get is accurate as of the time of the request.

There are no webhooks or push notifications, so ThinkReservations does not send your integration an alert when something changes. If you need data to stay reasonably current, your developer will set up requests on a schedule that makes sense for your use.

Webhook support is something we'd like to add in the future, but we don't have a timeline to share.

Guest contact details require their own permission. Reading reservations does not automatically include the guest's name, email, phone, or address. That's a separate permission you choose when creating your key. Without it, reservations still come through and still carry a customer ID — so an integration can tell which reservations belong to the same guest — but that ID carries no personal details on its own.

We recommend only granting it if your integration actually needs it. If you're building an occupancy or revenue report, it almost certainly doesn't need guest email addresses. Granting less is a good practice.

Withholding that permission reduces what's exposed, but it does not make your data anonymous. Some guest-related information is part of the reservation itself rather than the contact record — including additional guest names, dietary restrictions, special accommodations, custom fields, and line-item customer names. Any key that can read reservations can read those. We can tell you exactly what data each permission exposes; whether a given configuration satisfies your obligations is a question for your own legal advisor.

No payment card data is available through the API. Reservations include financial totals — deposits, taxes, processing fees, balances, and itemized taxes — but no card numbers, tokens, or payment instruments of any kind.

Once data leaves ThinkReservations, it's yours to look after. When you issue a key and data flows into your own system or your developer's, how it's stored, secured, and used is your responsibility. This is worth discussing with whoever is doing the building.

No. "Public" describes our documentation, not your data. Anyone can read our technical documentation, just as anyone can read a product manual, but nothing in your account is accessible without an API key. You create that key yourself, it only ever reaches your own property's data, and you can delete it whenever you like.

There are currently no published limits on how much data you can request. We do expect to introduce limits in the future to prevent abuse and protect performance for everyone. It's worth asking your developer to build with that in mind.

If your developer encounters unexpected behavior with a high volume of requests, they can email product@thinkreservations.com.

We work to make improvements without breaking existing integrations. If a change can't be made without breaking something, our approach is to version the API, notify affected customers that an upgrade is needed, and allow time to make it, rather than changing something existing integrations depend on without notice.

If you or your developer believes they have found a bug, have them email product@thinkreservations.com to create a ticket with the team that can help you.

What we support: the API and its documentation. If something is wrong on our end, we'll fix it.

What we don't support: the code you or your developer writes. We can't debug your integration, build your reports, or maintain what you've built.

If you're a technology company looking to build an integration that works across ThinkReservations properties rather than a single one, that's a different path with a different type of access, and it involves a conversation with our Product team.

Our developer documentation is public, and you're welcome to read it at any time. To discuss a partnership or a Marketplace listing, please contact us at product@thinkreservations.com, and we'll route you to the right person.

Does it cost anything? No. API access is included on every plan, with no additional charge and no usage-based fees at this time. The only cost is the development time on your side.

Do I need to have anything enabled? No. It's available on every plan, and there's nothing for us to switch on. You create keys yourself at Settings → API Keys. If you can't see that page, see Creating and Managing API Keys; it's usually a user permission.

Can I try it without a developer? Realistically, no. There's no interface, so something has to be built before you see any results.

Do you offer guidance or help with technical questions? Our support team will not be able to assist with implementing your API key, troubleshooting your project, or supporting your development partners. The API Documentation created by our development team is very robust and will be your go-to resource for any additional questions.

Our support is limited to the documentation resources below:

Can my developer test without affecting live data? Not with a Restricted API Key. There's no separate test environment for self-service keys, so everything runs against your live account.

Reading data is harmless. Updating daily rates is not: those changes are real and take effect in your account. Ask your developer to be careful with that part and to test.

Why don't the availability numbers from the API match my calendar? Availability results depend on both the dates and the occupancy in the request. A request for a different occupancy will return different results, so this is usually the explanation — it's worth comparing the occupancy in your developer's request against what you're seeing on your calendar.

Can I get my entire reservation history in a single request? No. A date or timestamp range is required, and results are paginated, so your developer will need to "page" through them.

Is this the same as the integrations in your Marketplace? No. Marketplace integrations are built and maintained together with ThinkReservations and work across our customer base. The API is for your own property's data, built by you or your developer.