This website requires Cookies!

Please enable Cookies in your web browser before you continue.
Click Here for instructions on how to enable Cookies in your browser.

Upgrade your browser!

You''ll enjoy this experience much more in a modern browser.

Plus, we can''t guarantee everything will work correctly for you in this old browser. Check out this list of modern browsers that we think would be a good replacement.

Brushfire Developer Center


Welcome to the Brushfire Developer Center! Here we will outline the guidelines, procedures, and best practices that we encourage you to use when consuming our API.

The Brushfire API attempts to conform to RESTful design principles and HTTP/1.1 specifications. You interact with the API by accessing resource URIs using properly formed HTTP requests. This entails the proper use of headers, formats, and HTTP verbs (GET, POST, PUT, and DELETE) on your requests and Brushfire will return similarly well-formed responses that include HTTP Status Codes and its own set of headers.

Our full, interactive API documentation is available at There you can explore and even interact with our API by forming requests and sending them to our API. All examples below will be using JSON and cURL syntax for simplicity.


The resources exposed by the Brushfire API are all secured by HTTP Basic Authentication. Additionally, authorization for all calls is handled via an Application Key.

To request an Application Key, please fill out this form.

Some resources that require a user context will take a User Access Key as a parameter. To get a User Access Key, you will need to use your Application Key and authenticate a specific Brushfire user account using the accounts/auth resource. One of the properties that is returned from a successful call will be the Access Key for that user which can then be used in subsequent calls requiring a User Access Key. For examples of a request for an Access Key and the response, please see below.


Requests are what you send to the Brushfire API. They are made up of the following components:


NOTE: All requests must be made over HTTPS. All other requests will be rejected.
All API requests should be sent to the following base url: Each resource will have its own path after that, for example, to authenticate a user and retreive an access key:

Request Headers

Every request you make to the Brushfire API must contain all of the following headers:
Every authorization header sent to the Brushfire API will follow the same basic format: Authorization: Basic {Base64 Encoded String} The Base64 Encoded string in the header will be your Application Key followed by a colon: zyxwvuts87654321: ====> enl4d3Z1dHM4NzY1NDMyMTo=
The Content-Type header tells the Brushfire API what type/format of data you are sending. Brushfire will accept requests in JSON or XML: Content-Type: application/json
Content-Type: text/xml
NOTE: XML requests must contain a root element with the appropriate namespace. The root element must match the name of the class exposed in the Schema for each call at The namespace should be set to xmlns="" for all calls.

Because of these constraints, JSON is recommended and XML is unsupported by Brushfire.
The Accept header tells the Brushfire API what type/format of data you would like us to respond with. Brushfire will respond in JSON or XML: Accept: application/json
Accept: text/xml
The Brushfire API versions its resources by means of a header. This means with every request you send, you include a version identifier that lets us know what version of our API you are accessing. This way we can add new features and even make potentially breaking changes without breaking your implementation because you will be accessing a previous version. For more information on versions, click here.

You may include your version in an Api-Version header, OR by adding it as a MIME type qualifier in your Accept header: Api-Version: 2022-07-13
Accept: application/json; version=2022-07-13

Sample Request

Bringing all those elements together, here is an example cURL request to authenticate a user via email/password:
NOTE: cURL allows you to send in the Authorization header unencoded using the -u parameter.
curl \
	-X POST \
	-u zyxwvuts87654321: \
	-H "Api-Version: 2022-07-13" \
	-H "Accept: application/json; version=2022-07-13" \
	-H "Content-Type: application/json" \
	-d '{ "email" : "" , "password" : "securepassword" }'
To find out what happens next, let's dig into Brushfire's responses.


Responses are what Brushfire sends back to you. They are made up of the following components:

Status Codes

Successful requests will return an HTTP status code of 200. You should check for this result and then process the message body.

Unsuccessful requests will return a status code in the 400's or the 500's. 400's mean you did something wrong. 500's mean we did something wrong. Below are a few explanations of common issues. For a complete list, consult this page.

  • 400 - Bad Request: The data you sent was missing, invalid, or malformed
  • 401 - Unauthorized: Your application key was invalid
  • 403 - Forbidden: You do not have access to the requested resource
  • 404 - Not Found: The requested resource or some related component could not be found
  • 412 - Precondition Failed: You did not use HTTPS or you did not include a version header
  • 415 - Unsupported Media Type: You did not include a Content-Type and Accept header
  • 500 - Internal Server Error: An unhandled exception occurred on our end. Please email us about these.


The body of a successful request will contain the data you requested in the format you specified in the Accept header. Below is an example succesful response from the request made above:
HTTP/1.1 200 Success
	"Id": "bz8e5d20-36a3-0000-0000-22t457eb69c0",
	"FirstName": "Joe",
	"LastName": "Schmo",
	"Email": "",
	"AccountNumber": 45,
	"AccessKey": "akebic0fgje5s4d8"
The body of an unsuccessful request will contain information about what went wrong and how you can correct it. Here are a few examples of possible responses for the request above. The Dataproperty may contain varying types of data pertaining to the error in certain circumstances.
HTTP/1.1 400 Bad Request
	"Message" : "Bad Request. Please see Errors property for more information.",
	"Errors" : [
		{ "Key" : "Email", "Value ": "Email is required." },
		{ "Key" : "Password", "Value ": "Password is required." },
	"Data": null
HTTP/1.1 404 Not Found
	"Message" : "Account not found with this address."

Try It Out

Visit our comprehensive list of all API resources where you can select your version, supply your App Key, and even test every endpoint.

  View Interactive Documentation

Current JSON API spec available at


Your server can be notified when certain tasks take place in Brushfire. To subscribe/unsubscribe to our hooks, review the API documentation for /hooks/subscribe and /hooks/unsubscribe. When subscribed, Brushfire will POST a JSON payload to your URL with the following format:
	"Id" : "bz8e5d20-36a3-0000-0000-22t457eb69c0",
	"SentAt" : "2016-04-13T18:39:21Z",
	"Type" : "Webhook_Type",
	"Data" : { .... }

The Type parameter will be a string with one of the following values:

  • Order_Completed available 2016-04-13
  • Order_Updated available 2021-02-18
  • Attendee_Created available 2017-01-25
  • Attendee_Updated available 2017-01-25
  • Attendee_Cancelled available 2017-01-25
  • Event_Created available 2019-10-30
  • Event_Updated available 2021-02-18
  • Group_Created available 2020-07-07
  • Group_Updated available 2020-07-07
  • Group_Deleted available 2020-07-07
The content of the Data paramter will vary by the type of webhook and it will contain data relevant to the specific task that has been triggered. For more information about them, initiate the webhook and record and insepect the request body.

Version History

We will increment versions anytime a backwards-incompatible update is made. You can view a full history of those versions below.
NOTE: We will continue to support old versions for at least 6 months after a newer version has been released. After 6 months, however, the old version may be marked obsolete and the features it supported may be decommissioned if continuing to support those features is preventing us from further enhancements. Please check back frequently to review these changes.
2022-07-13 Latest/Recommended
  • Updated sections endpoints for consistency with new attendee experience
2021-01-04 Support Ending Soon: 2023-01-13
  • Added support for attendee canceling, donating, changing types, gifting, and setting completed state
2020-07-07 Obsolete: 2021-07-04
  • Added support for groups webhooks
2019-10-30 Obsolete: 2021-01-07
  • Add support for remote fetch and remote validate fields types
2019-01-17 Obsolete: 2020-04-30
  • Add attendee and event data/metadata endpoints for consistent access
2018-10-10 Obsolete: 2019-07-17
  • Add Access Code endpoints
2018-05-23 Obsolete: 2019-04-10
  • Change Event lookup endpoint to have email parameter as part of query string instead of path
2018-03-12 Obsolete: 2018-11-23
  • Change FieldInput and FieldOutput to be more consistent when sending/receiving values
2017-08-28 Obsolete: 2018-09-12
  • Complete support for all cart methods and restructure of paths therein for consitency
2017-06-15 Obsolete: 2018-02-01
  • Support for attendee, buyer (in the cart and after an order), and group fields
2017-05-10 Obsolete: 2018-01-01
  • Support for associating external codes with Brushfire attendees.
  • Updated format for linking attendees to match other endpoints.
2017-04-10 Obsolete: 2018-01-01
  • Support for sideloading payment apps like PayPal and Square.
  • Increased promotion functionality.
2017-01-25 Obsolete: 2018-01-01
  • Webhook endpoints for 3rd party integrations and notifications.
2016-08-12 Obsolete: 2018-01-01
  • Helpdesk endpoints for searching via email address.
2016-06-15 Obsolete: 2018-01-01
  • Added endpoints for single/multiple attendee/group/order resource printing
2016-03-22 Obsolete: 2018-01-01
  • Added endpoints for retrieving event report and customized data
  • Added new endpoints for Group and Order Details that do not require a check-in session and moved session-specific requests to /sessions
  • Added new endpoint for getting ticket/e-ticket/namebadge/etc PDF of orders
2016-02-01 Obsolete: 2018-01-01
  • Added endpoints for pre-registering attendees for events that have pre-registration enabled
2015-11-01 Obsolete: 2018-01-01
  • Improvements to Check In and Check Out endpoints to allow for new bulk actions
2015-05-20 Obsolete: 2017-01-01
  • Initial release of "Version 2" with full restructure.
2014-05-01 Obsolete: 2015-08-01
  • Version 1. Initial release of API.

Getting Help

If you have any questions about the information in this document, issues with the API, or other technical questions, please email us at We generally are able to respond within a few hours.