Talk with Guest developer docs.

These pages describe how the Guest Talk platform exposes hotel and guest data to the outside world. If you are building an internal integration for a single property, a marketplace add-on that will be listed to every Talkguest customer, or a data pipeline that pushes reservations into a data warehouse, this is where you start. The documentation assumes basic familiarity with REST, JSON and HMAC signatures; it does not assume familiarity with the Portuguese hospitality regulatory context, which is covered in-line where relevant.

Talkguest treats the API as a first-class product surface. Every feature that ships in the operator UI ships with an API endpoint behind it, and every endpoint is versioned so that a change we make to the platform does not silently change the shape of a payload you already parse. The current version is v1; when we introduce breaking changes we ship v2 alongside v1 and give integrators at least twelve months to migrate.

The four sub-documents below are the ones every integrator eventually reads. Start with the API reference to understand the resources and their shapes, then wire up webhooks so you do not have to poll, then read the rate limits section so you know how much you can push through the write endpoints during check-in peak, then keep the error codes tab open in a second window while you build. Each page cross-links to the others where it makes sense.

Environments

Talk with Guest exposes two environments. The production environment sits at api.talk.mindbery.org and holds real reservations, real guests and real folio movements. The sandbox environment sits at sandbox.talk.mindbery.org and is a full-fidelity clone of the production platform with test rates, synthetic guest profiles and a fake OTA that emits events on the same cadence a real OTA would. Both environments use the same code paths, the same rate limits and the same error codes; the only differences are the data set and the fact that sandbox tokens can never be used to move real money.

Integration work should always start in sandbox. When you are ready to promote a build to production, ask the customer to issue a production token from their own operator UI and swap the base URL. There is no code-level difference between the two environments; if your integration works in sandbox it works in production.

Conventions

Every timestamp is ISO-8601 with an explicit Z for UTC or an explicit offset for tenant-local. Every currency amount is a decimal string with two decimal places, never a float, to avoid rounding surprises. Every identifier is a URL-safe base64 string prefixed with the resource type — res_ for reservations, gst_ for guests, fol_ for folios — so that IDs are self-describing when you see them in a log line. Every list endpoint paginates with cursor pagination; no offset-based pagination anywhere on the platform.

Support

Every code sample in the four documents below has been run against the sandbox environment before publication. If a snippet fails on you, the first thing to check is that your User-Agent is set — the platform rejects requests without one — and the second is that you are on v1, not a stale earlier path. If the snippet still fails, the integrations team reads every ticket that quotes a request_id from the error envelope; that identifier lets us jump straight to the underlying log line without a reproduction.