Skip to main content
The tickets_generate function reads the zone configuration from events/{idevent}/setup/zones, iterates every zone and every seat within it, and creates one ticket document per seat. All writes are committed in a single Firestore batch and simultaneously inserted into PostgreSQL.

​
How it works

1

Fetch the event document

The function reads events/{idevent} to obtain event.name, event.description, date_start, and date_end. If the document does not exist, it returns a 400 immediately.
2

Read zone configuration

It reads events/{idevent}/setup/zones. This sub-document must have status: true; if it is false the function returns without generating any tickets.
3

Iterate zones and seats

For each zone in datos.zone, it loops from 1 to zone.seats inclusive. Each iteration generates a new Firestore document reference to mint a unique ID.
4

Build ticket data

Each ticket is assembled with the fields below and staged into a Firestore batch write targeting events/{idevent}/tickets/{ticketDocId}.
5

Commit when all seats are staged

Once tickects_gen reaches datos.seats_allocated, the Firestore batch is committed and the equivalent rows are bulk-inserted into the PostgreSQL tickets table.

​
Request

POST /tickets_generate
Content-Type: application/json

{
  "data": {
    "idevent": "JAOTIiQrtU1fMWZZY2IZ"
  }
}

​
Parameters

​
data.idevent
string
required
The Firestore document ID of the event for which tickets should be generated. Must match a document in the events collection.

​
Zone Configuration (Firestore)

Before calling this endpoint, the document at events/{idevent}/setup/zones must be present and valid. 
{
  "status": true,
  "seats_allocated": 300,
  "zone": [
    {
      "id": "VIP",
      "name": "VIP",
      "color": "#FFD700",
      "seats": 50
    },
    {
      "id": "GEN",
      "name": "General",
      "color": "#4A90D9",
      "seats": 250
    }
  ]
}
seats_allocated must equal the sum of seats across all zones. Generation only commits when tickects_gen reaches this value — a mismatch will leave the batch uncommitted.

​
Generated Ticket Structure

Each ticket written to events/{idevent}/tickets/{ticketDocId} has the following shape: 
{
  "ticket_id": "JAOTIiQrtU1fMWZZY2IZ-nGxHQ00YzCg9PphEwlYb",
  "seat_id": "VIP-1",
  "zone": "VIP",
  "color": "#FFD700",
  "status": true,
  "seat_row": "por asignar",
  "event_id": "JAOTIiQrtU1fMWZZY2IZ",
  "event_name": "Festival de Verano 2024",
  "date_start": "2024-11-15T18:00:00.000Z",
  "date_end": "2024-11-15T23:00:00.000Z",
  "date": {
    "created": "2024-10-01T10:00:00.000Z",
    "updated": ""
  },
  "ledger": [
    {
      "date": "2024-10-01T10:00:00-05:00",
      "action": "generated",
      "metadata": "{}"
    }
  ]
}

​
Ticket Fields

​
ticket_id
string
Composite identifier built as {event_id}-{firestoreDocId}. This is the canonical ID used across all subsequent operations.
​
seat_id
string
Composite seat reference: {zone.id}{seat_number} (e.g. VIP1, GEN42). Built from the zone id field, not the display name.
​
zone
string
Display name of the zone (e.g. "VIP", "General").
​
color
string
Hex color string from the zone definition. Used by client apps to colour-code seat maps.
​
status
boolean
true when the ticket is available for purchase. Set to false after a sale is completed.
​
seat_row
string
Row label. Initialised to "por asignar" (“to be assigned”) at generation time.
​
event_id
string
Firestore document ID of the parent event.
​
event_name
string
Display name copied from event.event.name at generation time.
​
date_start
Timestamp
Event start time, copied from the parent event document.
​
date_end
Timestamp
Event end time, copied from the parent event document.
​
date.created
Timestamp
Server timestamp recorded when the ticket was generated.
​
date.updated
string
Empty string at creation. Updated to a server timestamp on every subsequent mutation.
​
ledger
array
Audit trail. Initialised with a single generated entry. Every subsequent state change appends a new entry.

​
Responses

​
message
string
Human-readable result message, e.g. "Se Generaron: 300".
​
status
number
HTTP-style status code: 200 on success, 400 on failure.
​
data.valido
boolean
true when tickets were generated successfully.
Success (200) 
{
  "message": "Se Generaron: 300",
  "status": 200,
  "data": { "valido": true }
}
Event not found (400) 
{
  "message": "Evento no Encontrado",
  "status": 400,
  "data": { "valido": false }
}
Zone not active (200 / valido: false) 
{
  "message": "El evento no esta activo para generar tickets",
  "status": 200,
  "data": { "valido": false }
}
Ticket generation is idempotent in the sense that calling it a second time will create a second set of tickets. There is no built-in guard against double-generation — ensure the setup/zones document’s status is set to false after a successful run to prevent accidental re-runs.

Build docs developers (and LLMs) love

Get started for freeTalk to us