Mutation

checkIn

Checks in tickets and reports the outcome of each one separately.

Each entry of the checkins argument bundles the tickets presented at one check-in source. SourceCheckins.scanCode is the code of that source — the same value that Query.checkinTargetSource takes — while each CheckinRequest.code is the code of a ticket, as returned by CheckinTarget.scanCode or Ticket.scanCode. Codes are matched case-insensitively. CheckinRequest.timestamp is the Unix timestamp in seconds at which the ticket was presented, so scans collected while offline can be submitted later with their original times.

The mutation resolves to one CheckinResult per request, in the order the requests were sent, with CheckinResult.code echoing the submitted code. Each request is handled independently: a failing one neither aborts the batch nor affects the others. CheckinResult.success is true when the check-in was recorded; otherwise CheckinResult.failureReason states why it was refused:

• invalid-code — the code belongs to no ticket, or to no ticket of the given source
• already-checked-in — the ticket was checked in before
• ticket-revoked — the ticket is no longer valid
• wrong-time — the ticket was presented outside its validity interval, see CheckinTarget.validityIntervals

Every submitted request is recorded as an attempt regardless of its outcome, and shows up in CheckinTarget.checkinAttempts. A recorded check-in becomes visible in CheckinTarget.checkin and Ticket.checkin.

No authorization is required — knowledge of the source and ticket codes is what permits the check-in. If SourceCheckins.scanCode names no known source, the whole mutation reports an error instead of individual failures.

mutation CheckIn($checkins: [SourceCheckins!]!) {
  checkIn(checkins: $checkins) {
    code
    success
    failureReason
  }
}
mutation CheckIn($checkins: [SourceCheckins!]!) {
  checkIn(checkins: $checkins) {
    code
    success
    failureReason
  }
}