Start here

Going live

Test mode and live mode are separate worlds. Live mode starts empty: nothing you built in test mode carries over, and ids from one mode don’t work in the other (a test account id sent with a live key gets 403 account_invalid). Going live means running your setup again against the live key, with the same code.

Turn live mode on in the dashboard by adding a card for your Tiempo bill. Your first live key is shown once, straight after; the owner and admins also get an email with this checklist.

What to recreate

Per mode (recreate in live)	Shared by both modes
Businesses (accounts), locations, resources, schedules, overrides and blocks	Your platform, its name and its pinned API version
Bookings, series, sessions and attendees	The team and their roles
API keys, standard and restricted	The longest-hold setting (it applies to both modes)
Webhook endpoints and their signing secrets	Your plan and card
Events, usage and their history

Store every Tiempo id per mode, or derive it at start-up from the mode you’re in. Ids look the same in both modes, so a test id reaching production code is the most common go-live bug.

Live keys

Live keys start tpk_, test keys tpt_. Keep the live key only in production config, never in a repository or a client.

Give each service its own restricted key with only the permissions it needs, and name it after where it runs (“booking-widget prod”), so a leak is easy to trace and revoke. Owners and admins create live keys; each one is announced to them by email. Revoking a key takes effect within seconds, so switch your servers to the new key first.

Live webhooks

Register your live endpoint with the live key. It must be a public https URL (test mode also accepts http), and it gets its own signing secret: verify live deliveries with that, not the test one.

Owners and admins are emailed when a live endpoint has been failing for an hour, again at 24 hours, when Tiempo turns it off after three days, and when it recovers. To catch up after an outage, list what it missed with GET /v1/events?delivery_success=false (see webhooks).

curl https://api.tiempo.one/v1/webhook_endpoints \
  -H "Authorization: Bearer $TIEMPO_LIVE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://yourplatform.com/tiempo/webhooks",
       "enabled_events": ["booking.*", "attendee.*"]}'
# The response's "secret" (tpw_…) is shown once: store it as your live signing secret.

Limits and billing

Live mode allows 100 requests a second per platform (250 on the £49 plan), against 25 in test mode. On 429 rate_limited, wait Retry-After seconds and retry with the same Idempotency-Key.

Live bookings are billed: each counts once, at its first confirmation, against your plan’s included bookings, and owners and admins are emailed when those run out for the month. Imports are free. Usage is invoiced monthly to your card. Test bookings are never billed, and test data is deleted 30 days after it’s over; live data is kept.

Before production traffic

Every business, resource and schedule exists in live, and production config holds live ids only.
Each service has its own restricted live key; no test key is reachable from production.
The live webhook endpoint is https, verifies Tiempo-Signature with its own tpw_ secret, dedupes on event id, and replies 2xx within 10 seconds.
Anything you can’t undo, like a customer message, fetches the booking and acts on its current status, rather than trusting the order webhooks arrive in.
Writes send an Idempotency-Key, and 429s and 5xx responses are retried with the same key after waiting.
You know how you’ll catch up after an outage: delivery_success=false from the last event you handled.
You’ve read Testing your integration and run its race, hold-expiry and webhook checks against test mode.