Skip to main content

Conventions

HTTP methods​

  • GET: read operations (list, get)
  • POST: write operations (create, update, delete)

All data-modifying requests are handled using the POST method to ensure consistency and allow for more complex request payloads when necessary.

Update semantics​

An update sets only the values you pass. Any field you omit is left unchanged.

So this changes how many times a promo code can be redeemed and nothing else:

curl -X POST -H 'Tessera-Api-Key: tess_sk_...' \
-H 'Content-Type: application/json' \
-d '{"quantity":250}' \
'https://public-api-dev.yourtessera.com/v1/events/{eventId}/promos/{promoId}/update'

Pagination​

Most list endpoints are cursor paginated. Pass limit (default 10, maximum 100) and follow pagination.nextCursor until pagination.hasMore is false.

{
"data": [ { "id": "..." } ],
"pagination": {
"nextCursor": "eyJjcmVhdGVkQXQiOiIyMDI2LTA4LTE5In0=:2",
"hasMore": true
}
}
curl -H 'Tessera-Api-Key: tess_sk_...' \
'https://public-api-dev.yourtessera.com/v1/events?limit=50&nextCursor=eyJjcmVh...'

Cursors are opaque. Do not construct, parse, or store them as meaningful values; their format may change without notice.

Where a list is paginated, this is the only scheme the API uses, and it is the only one it will use.

Formats​

  • Timestamps are ISO 8601. Where you supply one, include the UTC offset.
  • Dates without a time, such as multi-day event dates, are YYYY-MM-DD.
  • Money fields are numbers in the currency named on the same object.
  • Ids are opaque strings. See Identifiers.

Dates and timezones​

An event carries a startDate and an endDate, each an ISO 8601 instant with offset, plus an IANA timezone such as Asia/Singapore. The local time shown on the event page is derived from the two together, so read them as a pair:

{
"startDate": "2026-09-01T19:00:00+08:00",
"endDate": "2026-09-01T23:00:00+08:00",
"timezone": "Asia/Singapore"
}

Identifiers​

Throughout the documentation, You will notice the use of UUIDs with a prefix. Some response payloads contain these IDs which basically serve as unique identifiers for the object being returned.

The prefix makes it easy to identify which API resource it's coming from.

evt_019f6a66-1d0a-7dbc-b626-6a438f6e525b
tkt_019f6a70-8c31-7a4e-9d02-1b5c7e2f4a90
PrefixResource
org_Organization
evt_Event
tkt_Ticket
tcat_Ticket category
promo_Promo code
trk_Tracking link

We accept an id without its prefix. Anywhere a request takes an id, both evt_019f6a66-1d0a-7dbc-b626-6a438f6e525b and 019f6a66-1d0a-7dbc-b626-6a438f6e525b reach the same event.

Versioning​

The major version is in the path, so v1 is https://public-api-dev.yourtessera.com/v1/....

Additive changes ship inside v1 without notice. New fields, new optional query parameters, and new endpoints can appear at any time. Your client must ignore fields it does not recognise rather than failing on them.