In short
- What changes: IDs on the payment endpoints can come back as text, for example, "id": "123456" instead of "id": 123456. The value stays the same.
- When: from November 23, 2026. The change rolls out to accounts gradually, so your code must accept both formats and convert them to text.
- Who needs to act: anyone whose own script, app or automation calls the Hostaway Public API.
- Who does not need to act: customers who use the Public API only through a Marketplace partner. The partner updates their integration.
What you need to do
- Find the code that reads IDs from the Hostaway Public API.
- Make sure it keeps IDs as text and never converts them to numbers.
- Test it with a large ID, such as "957144035275968076".
- Deploy the change before November 23, 2026.
What is changing?
The Hostaway Public API can return IDs as text instead of numbers. The value stays the same. Only the type in the JSON response changes.
- Before: "id": 123456
- After: "id": "123456"
I use a Marketplace partner integration. Do I need to do anything?
No. Your partner updates their integration. If you also call the Public API with your own scripts or automations, check those.
Which endpoints change?
We start with the payment endpoints:
- Payment cards: /v1/paymentCards/{reservationId} and its defaultPaymentMethod and addPaymentMethodId routes
- Guest charges: /v1/guestPayments/charges, including create, update, refund, and retry
- Guest invoice charges: /v1/guestInvoices/{guestInvoiceId}/charges
Other endpoints will get the same format later. We will update the Public API documentation before each change.
Which fields change?
IDs only. Amounts, dates, counts, and other numbers stay numbers.
Why are you making this change?
Hostaway is growing, and we keep adding new features. To support that growth, our systems now create IDs in a new format, built for a much larger number of records. This gives us, and your integration, a stable base for the years ahead.
The new IDs are longer than the old ones. Sending them as text makes sure that every system reads them exactly as we send them.
Text also keeps your integration ready for the future. In time, our IDs may contain letters as well as digits. If your integration already treats IDs as text, it will keep working when that happens.
Why can't the IDs stay numbers?
The new IDs are too long for some programming languages and tools, JavaScript in particular. They store every number as a floating-point value, which is exact only up to 9,007,199,254,740,991. A longer ID gets rounded with no error: 957144035275968076 becomes 957144035275968100. A later request with the rounded ID then fails. Text keeps the ID exact in every language.
How do I know if my code is affected?
Your code is probably affected if it does one of these:
- reads our responses in JavaScript or TypeScript and uses the id as a number
- declares the id field as a number in a type, a generated SDK, or a response schema, and rejects text
- converts the id to a number, for example with Number(), parseInt() or a numeric cast
- opens our IDs in a spreadsheet, which keeps only 15 digits of a number
If your code reads the id and sends it back without changing it, and your JSON parser keeps large numbers exact, you are probably not affected. Test with a large ID to be sure.
How should I handle IDs?
Treat every id from the Hostaway Public API as an opaque value:
- Convert every id to text as soon as you receive it. During the rollout, an id can arrive as text or as a number, so accept both, for example with the type string | number in TypeScript, and convert it at once.
- Store and pass the id as text everywhere in your code and your database.
- Send the id back as text.
- Do not use the id in calculations, numeric sorting or numeric comparisons.
IDs do not tell you which record is newer. To put records in order, use a date field from the response, for example, chargeDate on a guest charge. Compare IDs only to check if two IDs are equal.
// Wrong: converts the id to a number, which can change its last digits
const chargeId = Number(charge.id);
// Right: keep the id as text
const chargeId = String(charge.id);
// Wrong: uses the id to find the newest charge
charges.sort((a, b) => b.id - a.id);
const isNewer = charge.id > lastChargeId;
// Right: use a date field for order, and compare IDs only for equality
charges.sort((a, b) => (b.chargeDate ?? '').localeCompare(a.chargeDate ?? ''));
const isSameCharge = String(charge.id) === String(savedChargeId);
Can I use an AI coding assistant to check my code?
Yes. An AI coding assistant can search your code for the places that need a change. Copy the prompt below into your assistant and run it in your project. Review every change it makes and run your tests before you deploy.
The Hostaway Public API will return IDs as JSON strings instead of numbers, for example, "id": "957144035275968076" instead of "id": 957144035275968076. These IDs can be larger than 2^53, so they must never be parsed or stored as JavaScript numbers or floating-point values.
Find every place in this codebase that reads, stores, compares, or sends an id from the Hostaway Public API. This includes any field named id or ending in Id or Ids, such as reservationPaymentCardId, chargeId, or refundIds.
For each place:
- Accept the id as a string or a number, and keep it as a string from then on.
- Remove every conversion of the id to a number, such as Number(), parseInt(), parseFloat(), a unary + or a numeric cast.
- Change id fields in type definitions, generated SDK types, and response schemas to accept a string.
- Check database columns that store these IDs. Store them in a text column, such as VARCHAR(64). A 32-bit integer column is too small.
- Send IDs back to the API exactly as they were received.
Do not change amounts, dates, counts, or other numeric fields.
Add or update tests that use a large id such as "957144035275968076". When you finish, list every change with its file and line, and list every place you were not sure about.
Do I need to change my database?
We recommend that you store our IDs as text, for example in a VARCHAR(64) column. Text holds every ID exactly, including future IDs that may contain letters.
If you store our IDs in a 64-bit integer column, such as BIGINT, it holds the current IDs. Plan to change it to text, because IDs may contain letters later. A 32-bit integer column, such as INT, is too small for the new IDs. Change it now.
Can I send an ID back as text?
Yes. In a URL, the ID is text anyway, so nothing changes. In a request body, for example, reservationPaymentCardId, the API accepts the ID as text or as a number.