If a badge is given via a TTE Friendship and a new User recipeint is created for the Badge, this flags if the user has logged in yet for the first time (activated their account). 1 means yes, 0 means no.

complimentary_event_availability

This include will set several values for the badge.

includes_simple_comp_tickets

includes_group_comp_tickets

includes_comp_tickets

Flags if the Badge's BadgeType includes any complimentary Tickets. 1 means yes, 0 means no. Simple comp tickets are ones for events available generally. Group comp tickets are ones for events available only via EventGroups. The third flag is for either.

unclaimed_simple_comp_tickets

unclaimed_group_comp_tickets

unclaimed_comp_tickets

Counts of any unclaimed complimentary Tickets allowed with the Badge. See above for distinctions between the different comp ticket categories.

unclaimed_comp_tickets_by_group

Count of unclaimed comp tickets by EventGroup ID, a la:

 {
   [id]: [count],
   ..
 }

complimentary_product_availability

This include will set two flags for the badge.

includes_complimentary_products: Flags if the Badge's BadgeType includes any complimentary Products. 1 means yes, 0 means no.
has_unclaimed_complimentary_product [without an -s]: Flags if the Badge has unclaimed complimentary Products. 1 means yes, 0 means no.

days

The ConventionDays covered by the Badge (actually its BadgeType).

has_complimentaries

Sets three flags for the Badge indicating if it has claimed complimentary SoldProducts or Tickets. 1 means yes, 0 means no.

has_comped_soldproducts: Whether the badge has claimed any complimentary merch.
has_simple_comped_tickets: Whether the badge has claimed any tickets complimentary outside of EventGroups.
has_group_comped_tickets: Whether the badge has claimed any tickets complimentary within EventGroups.

has_complimentary_products

Replaced with has_complimentaries, see above.

A flag indicating if the Badge has claimed complimentary Products (actually SoldProducts, merch). 1 means yes, 0 means no.

is_giving_via_email

If the Convention allows permissive gifting, flags if the purchaser is giving the Badge to a user who is not yet the purchaser's TTE friend (Friendship invitation is sent at completion of Badge purchase).

longname

A very descriptive name for this badge. It pulls data from several objects, which is why it is not included by default.

Services

The services used to fetch and manipulate badges.

Search Badges

This will search across all conventions. To search on a single convention see "Relationships" in Convention.

 GET /api/badge

Optional Params

query: Searches a partial name.

Returns:

 {
    "paging" : {...},
    "items" : [
        {
          "id" : "xxx",
          "name_full" : "Joe User",
          ...
        },
        ...
    ]
 }

Create Badge

Generally you don't create badges this way, instead you do it through the ConventionCart API, or for organizers/admins via endpoint /api/badge/verified. This will put a badge in the system, but it will not be marked verified. It will still need to go through a checkout process or some other means of marking itself verified.

 POST /api/badge

Required Params

session_id
firstname
lastname
convention_id
badgetype_id

Returns the same as a normal read.

Administratively Create Badge

This will create a badge that is fully verified. You'll of course need to have the registration ConventionPrivilege to do this.

 POST /api/badge/verified

Required Params: Same as a normal badge creation.

If you specify the email field, the system will try to find a user account with that email, and then one of two things will happen. - If it finds a user account with that email, the badge will be attached to that user account. - If it does not, then TTE will create an account with that email address for the new badge, and TTE will send an email to the address asking the user to set a password for their account.

Note that TTE does not check if the email is in use on another badge. User account emails are unique, but badge emails cannot be. A user does not have to use the same email address on a badge that they have for their user account. So if you are creating a badge with an email address from another badge, because you want the new badge to belong to the same user/attendee, double-check with the user that you are using the email address that will identify their user account.

Returns the same as a normal read.

Read Badge

 GET /api/badge/xxx

Returns:

 {
   "id" : "xxx",
   "name_full" : "Joe User",
   ...
 }

Update Badge

 PUT /api/badge/xxx

Returns the same as a normal read.

Delete Badge

 DELETE /api/badge/xxx

Optional params

cashdrawer_id: You need to specify this to refund if purchased with cash in the point of sale system.

Returns:

 {
   "success" : 1
 }

Check-In Badge

 PUT /api/badge/xxx/check-in

Returns the same as a normal read.

Undo Badge Check-In

 PUT /api/badge/xxx/reverse-check-in

Returns the same as a normal read.

Assign New User To Badge

 POST /api/badge/xxx/user

Required Params

user_id

Returns the same as a normal read.

Convert Badge to Free

This refunds a charge for a badge without deleting it. Use of this endpoint requires the registration privilege.

 POST /api/badge/xxx/convert/free

Returns the same as a normal read.

Convert Badge

Convert a badge purchase to a different BadgeType. This will charge or refund the difference in the costs. This cannot be used for organizer-granted badges.

 POST /api/badge/xxx/convert/type/:badgetype_id

Required Params

badgetype_id: The ID of the BadgeType to convert the badge to.

Returns a normal read of the badge converted to.

Complimentary Tickets

Return a list of complimentary ticket associated with the badge.

 GET  /api/badge/xxx/tickets/complimentary

Returns a list as ../tickets would, but complimentary ones only.

Developer Documentation

Introduction