On September 1, 2026, we're shipping a set of breaking changes to the Brushfire API. These will impact all integrations using the affected endpoints, regardless of the API version sent in the header. Below is exactly what's changing, where, and what to do about it.
If you have questions or need help planning your migration, reach out to us — we're glad to work through it with you.
1. Full support for multiple payment methods
We're removing the deprecated flat payment fields that were replaced by the Payments[] array earlier this year. If your integration isn't yet reading from those arrays, this is the point to switch.
Removed:
GET /orders/{orderId}—PaymentMethod,TransactionId,TransactionTotal,ExternalInvoiceId, same properties inRelatedOrders[]GET /orders,GET /events/{eventId}/orders—PaymentMethodId,PaymentMethod,PaymentNumber,TransactionId,ExternalInvoiceIdGET /sessions/{sessionId}/orders/{orderId}—PaymentMethod
What to do: Read payment method, transaction, and invoice details from the order's Payments[] array instead.
2. Phone numbers must be E.164 format
All phone number fields — Phone, ContactPhone, PhoneNumber, and any other phone fields — will require E.164 format (e.g. +14155552671) on input, and will be returned in that format on output. This applies wherever phone numbers appear across the API: orders, attendees, accounts, events, and SMS-related endpoints.
What to do: Update any code that sends or parses phone numbers to use E.164 formatting.
3. Order-level fees are going away
OrderFee and DeliveryFee are being removed from order- and cart-level responses. Fee data will only be available at the item (attendee) level going forward.
Removed:
GET /orders/{orderId}—OrderFee,DeliveryFeeGET /orders—OrderFee,DeliveryFeeGET /events/{eventId}/orders—OrderFee,DeliveryFeeGET /cart/{cartId}/events/{eventId}—DeliveryFeePOST /cart/{cartId}/events/{eventId}—DeliveryFee
What to do: Use the item-level fee fields (UnitFee, UnitFees) instead of order-level fee totals and completely remove support for delivery methods (see below).
4. Delivery method is being removed
Delivery method support is being removed entirely from carts, orders, and sessions — including the related cart-update inputs.
Removed:
GET /cart/{cartId}/events/{eventId}—DeliveryFee,ShippingId,ShippingIsElectronic,ShippingIsPOS,ShippingIdName,DeliveryMethods[],Items[].UnitDeliveryPOST /cart/{cartId}/events/{eventId}—ShippingId,UnitDelivery,DeliveryFeeGET /cart/{cartId}/events/{eventId}/attendees/{attendeeId}—UnitDeliveryPOST /cart/{cartId}/events/{eventId}/attendees/{attendeeId}—UnitDeliveryGET /events/{eventId}/orders—DeliveryTotalGET /sessions/{sessionId}/orders/{orderId}—DeliveryMethodGET /orders/—DeliveryTotalGET /orders/{orderId}—DeliveryMethodPOST /orders/direct—ShipMethod
What to do: Remove any code that reads or sets delivery method fields — this concept no longer exists in Brushfire.
5. "PaidInFull" is being renamed to "PaymentReceived"
This is a naming change only — no change to what the field represents or how payment status is calculated.
Affected:
GET /orders—PaidInFull→PaymentReceivedGET /orders/{orderId}—PaidInFull→PaymentReceivedPOST /orders/—PaidInFull→PaymentReceivedPOST /orders/pos—PaidInFull→PaymentReceived
What to do: Update your integration to send/read PaymentReceived instead of PaidInFull.
What happens if I don't update by September 1?
Starting September 1, 2026, these six changes go live on the Brushfire API — for all API Versions — there's no fallback or transition period. Integrations that haven't been updated may see:
Missing data: Fields like PaymentMethod, TransactionId, OrderFee, DeliveryFee, and delivery-related fields will no longer be returned in API responses. If your integration expects these fields, it may throw errors, show blank/null values, or break depending on how your code handles missing data.
Rejected or ignored input: Fields like ShippingId, DeliveryFee, UnitDelivery, and PaidInFull will no longer be accepted as before. Depending on how your integration sends them, this could result in request errors or the values simply having no effect.
Format errors: Phone numbers not sent in E.164 format (e.g. +14155552671) will be rejected on input starting September 1.
Bottom line: if you haven't migrated by September 1, expect your integration to behave unpredictably — anywhere from silent data gaps to outright request failures, depending on the specific field and how your code is built. We strongly recommend testing against the updated fields before that date rather than waiting to see what breaks.