Reference Data

Reference endpoints expose the configuration you need to build valid orders and storefronts: payment methods, expense categories, event categories, time slots, blocked dates, custom field definitions, and computed availability.

All reference endpoints require the reference:read scope, accept both secret (ibp_sk_) and publishable (ibp_pk_) keys, answer OPTIONS preflight with 204, and return CORS headers on every response (success and error), so a browser storefront can read them directly.

Responses differ by key type

Three of these endpoints return less data to a publishable key than to a secret key: merchant-authored free text and back-of-house definitions are withheld from a publishable key. The response shape is identical either way, so you never branch on key type, but the values are not.

EndpointSecret key (ibp_sk_)Publishable key (ibp_pk_)
/reference/blocked-datesreason as authored, holiday_name as authoredreason is always the literal "unavailable", holiday_name is always null
/availabilityblocked_reason as authoredblocked_reason is always the literal "unavailable" when bookable is false
/reference/custom-fieldsAll active definitions, each with an internal booleanDefinitions flagged internal are omitted entirely; no internal key is present on the returned objects

Only a secret key (ibp_sk_) receives the merchant view. Every other key type receives the public view, so assume any key that is not a secret key sees the public content.

The remaining reference endpoints (expense-categories, payment-methods, event-categories, time-slots) return the same data to both key types.

Caching

Static, code-defined data carries Cache-Control: private, max-age=3600. Tenant-specific or live data carries Cache-Control: no-store.

EndpointCacheable
/reference/expense-categoriesYes (1 hour)
/reference/payment-methodsNo (tenant config)
/reference/event-categoriesNo (tenant config)
/reference/time-slotsNo (tenant config)
/reference/blocked-datesNo (live)
/reference/custom-fieldsNo (tenant config)
/availabilityNo (computed)

GET/api/v2/reference/expense-categories

Expense categories

The fixed, code-defined expense category list (19 categories). Identical for every account and static per release. Use the id when creating an expense.

Required scope: reference:read. Takes no query parameters.

Response

{
  "expense_categories": [
    { "id": "ingredients", "label": "Ingredients",
      "description": "Raw ingredients and food inputs" }
  ]
}

GET/api/v2/reference/payment-methods

Payment methods

The account's enabled payment methods. Disabled methods are omitted and the underlying enabled flag is never returned.

These are tenant-defined, free-form ids used for expense and payment bookkeeping. They are not the order-level payment_method value and not the payment-record method vocabulary. See Payment method vocabularies.

Returns an empty array when the account has never configured payment methods.

Required scope: reference:read. Takes no query parameters.

Response

{
  "payment_methods": [
    { "id": "eftpos", "name": "EFTPOS" }
  ]
}

GET/api/v2/reference/event-categories

Event categories

The account's event categories, name only. The name is the value you pass as an order's event_category. Any colour configured against a category is dropped.

When the account has not configured any categories, the ibakepro dashboard defaults are returned instead, so the array is never empty for that reason.

Order create does not validate event_category against this list.

Required scope: reference:read. Takes no query parameters.

Response

{
  "event_categories": [
    { "name": "Birthday Party" }
  ]
}

GET/api/v2/reference/time-slots

Time slots

The configured pickup and delivery time slots. This is the raw configured set with no date filtering - use Availability to see which slots are offered on a given date.

Required scope: reference:read

Query parameters

  • Name
    type
    Type
    string
    Description

    pickup or delivery. Omit for both. Any other value returns 400 (invalid_value, field type). Note that this parameter does not accept dispatch, even though orders can carry that fulfilment type.

Field notes

  • available_days is an array of day-of-week integers, 0 = Sunday through 6 = Saturday. An empty array means the slot is offered on every day, not on no days.
  • multiplier is a pricing multiplier applied to the delivery fee. It defaults to 1 when unset or non-numeric.
  • start and end come from the configured range. For a single-time slot they are the same value. Either may be null if the account's configuration is incomplete.
  • label falls back to "{start} - {end}" and then to an empty string.
  • id is the configured slot id. Accounts on pre-migration configuration return positional fallbacks of the form ps_migrated_0 (pickup) or ds_migrated_0 (delivery). Treat ids as opaque.
  • Results are ordered pickup slots first, then delivery slots, each in configured order. There is no pagination.

Response

{
  "time_slots": [
    {
      "id": "ps_pY3qjdcyDdVqy45s",
      "label": "9:00 AM - 11:00 AM",
      "type": "pickup",
      "start": "09:00",
      "end": "11:00",
      "multiplier": 1,
      "available_days": [1, 2, 3, 4, 5]
    }
  ]
}

GET/api/v2/reference/blocked-dates

Blocked dates

Explicitly blocked single dates and weekly recurring closed rules. The full configured set is returned - there is no date filter and no pagination.

Required scope: reference:read. Takes no query parameters.

reason and holiday_name are merchant-authored free text and are only returned to a secret key. A publishable key always receives "reason": "unavailable" and "holiday_name": null, on every entry, including entries where is_holiday is true.

Single dates

  • date is a YYYY-MM-DD calendar string.
  • id may be null on legacy entries.
  • is_holiday is true only when explicitly flagged.

Recurring rules

  • type is "weekly". Only weekly rules are evaluated by Availability; a rule of any other type never matches a date.
  • days_of_week uses the same 0 = Sunday convention as time slots. An empty array matches nothing.
  • enabled is true unless explicitly set to false. A disabled rule never blocks a date.
  • start_date and end_date are inclusive YYYY-MM-DD bounds, or null for unbounded.
  • A recurring rule never exposes a reason string, to either key type.

Response (secret key)

{
  "dates": [
    { "id": "blkd_Y1HhVvu9kSAxvRnb", "date": "2026-12-25", "reason": "Christmas Day",
      "is_holiday": true, "holiday_name": "Christmas Day" }
  ],
  "recurring_rules": [
    { "id": "weekly-blocked-days", "type": "weekly", "days_of_week": [0],
      "enabled": true, "start_date": null, "end_date": null }
  ]
}

Response (publishable key)

{
  "dates": [
    { "id": "blkd_Y1HhVvu9kSAxvRnb", "date": "2026-12-25", "reason": "unavailable",
      "is_holiday": true, "holiday_name": null }
  ],
  "recurring_rules": [
    { "id": "weekly-blocked-days", "type": "weekly", "days_of_week": [0],
      "enabled": true, "start_date": null, "end_date": null }
  ]
}

GET/api/v2/reference/custom-fields

Custom fields

Custom field definitions, active only. Use the field id when supplying custom_fields on an order, product, or customer. There is no pagination.

Required scope: reference:read

Definitions flagged internal (back-of-house fields the buyer is never asked for) are omitted entirely for a publishable key. A secret key receives them, and every field in a secret-key response additionally carries an internal boolean so you can tell them apart. A publishable response has no internal key at all.

Query parameters

  • Name
    scope
    Type
    string
    Description

    order, product, or customer. Omit for all three. Any other value returns 400 (invalid_value, field scope).

Field notes

  • scopes is an array of the singular external names (order, product, customer). ibakepro also supports internal-only scopes that have no external name; those are stripped, so a definition scoped only to them is returned with an empty scopes array when you omit the scope parameter.
  • key falls back to id when the definition has no key.
  • name falls back to an empty string.
  • type is one of text, textarea, email, tel, number, date, select, checkbox, radio, customerChoice. It defaults to text when unset.
  • options is an array, empty for types that do not use options.
  • required is true only when explicitly set.

Response (publishable key)

{
  "fields": [
    {
      "id": "9TmQ4bVxZ0Lr8KpNsWdE",
      "key": "dietary_notes",
      "name": "Dietary Notes",
      "type": "text",
      "required": false,
      "options": [],
      "scopes": ["order"]
    }
  ]
}

Response (secret key)

{
  "fields": [
    {
      "id": "9TmQ4bVxZ0Lr8KpNsWdE",
      "key": "dietary_notes",
      "name": "Dietary Notes",
      "type": "text",
      "required": false,
      "options": [],
      "scopes": ["order"],
      "internal": false
    }
  ]
}

GET/api/v2/availability

Availability

Per calendar date: whether the date is blocked, and which configured time slots fall on that date's day of week.

Required scope: reference:read

What it computes

For each requested date, in this order:

  1. Look for an explicit blocked single date matching the date. If found, the date is not bookable.
  2. Otherwise look for an enabled weekly recurring rule whose days_of_week contains the date's day of week and whose start_date/end_date bounds contain the date. If one matches, the date is not bookable.
  3. If the date is bookable, list the configured slots whose available_days include the date's day of week (a slot with an empty available_days is offered on every day). A blocked date always returns "time_slots": [].

Dates are treated as UTC-anchored calendar strings, so there is no timezone or daylight-saving drift.

What it does not compute

bookable: true means only "no explicit blocked date and no matching enabled weekly rule". It is not a booking guarantee and it is not a hold. Specifically, this endpoint does not consider:

  • Capacity or remaining slots. No booking-count model exists. A date with 500 orders on it returns exactly the same response as an empty date.
  • Lead time. The account's minimum-notice setting is not applied here. A date inside the merchant's lead time can still return bookable: true, including today or a date in the past.
  • Product availability, stock, or per-product fulfilment methods.
  • Order-level or delivery-address eligibility (service areas, minimum spend).

Query parameters

Exactly one of date or from+to is required. Omitting both returns 400.

  • Name
    date
    Type
    string
    Description

    A single date, YYYY-MM-DD. Rejected with 400 if malformed or not a real calendar date (for example 2026-02-30). Combining it with from or to returns 400.

  • Name
    from
    Type
    string
    Description

    Start of an inclusive range, YYYY-MM-DD. Requires to. Supplying one without the other returns 400.

  • Name
    to
    Type
    string
    Description

    End of an inclusive range, YYYY-MM-DD. Must be on or after from, and the inclusive span must not exceed 90 days, or the request returns 400.

  • Name
    type
    Type
    string
    Description

    Optional, composes with either mode. pickup or delivery. Omit for both. Any other value returns 400. It filters the time_slots array only - it never changes bookable.

Every entry in the requested range is returned, in ascending date order, including non-bookable ones.

blocked_reason is merchant-authored free text and is only returned to a secret key. A publishable key always receives the literal "unavailable" whenever bookable is false. It is null for a bookable date under either key type.

Request

GET
/api/v2/availability
curl -G https://au.api.ibakepro.com/api/v2/availability \
  -H "Authorization: Bearer {api_key}" \
  -d from=2026-07-04 -d to=2026-07-05

Response (secret key)

{
  "availability": [
    {
      "date": "2026-07-04",
      "bookable": true,
      "blocked_reason": null,
      "time_slots": [
        { "id": "ps_pY3qjdcyDdVqy45s", "label": "9:00 AM - 11:00 AM", "type": "pickup",
          "start": "09:00", "end": "11:00", "multiplier": 1 }
      ]
    },
    {
      "date": "2026-07-05",
      "bookable": false,
      "blocked_reason": "Closed Sundays",
      "time_slots": []
    }
  ]
}

Response (publishable key)

{
  "availability": [
    {
      "date": "2026-07-05",
      "bookable": false,
      "blocked_reason": "unavailable",
      "time_slots": []
    }
  ]
}

Slot objects here omit available_days - the date filter has already been applied. Every other slot field matches Time slots.


Static enums

These are compile-time constants. They are static per release and do not vary per account. Use them to interpret response values and to know the legal set when writing.

Order status

draft, inquiry, quote, pending, payment_pending_verification, confirmed, in_production, ready, dispatched, delivered, completed, cancelled.

Order create validates status against this full list and rejects anything else with 400. The v2 API has no order update or status-transition endpoint, so this is the only place you write a status.

The table below is the lifecycle ibakepro enforces on its own surfaces. It is useful for interpreting order updates you receive over webhooks; it is not applied to status on create.

FromTo (any of)
pendingconfirmed, in_production, ready, dispatched, delivered, completed, cancelled
confirmedin_production, ready, dispatched, delivered, completed, cancelled
in_productionready, dispatched, delivered, completed, cancelled
readyin_production, dispatched, delivered, completed, cancelled
dispatchedready, delivered, completed, cancelled
quotepending, confirmed, cancelled
deliveredcompleted
completednone (terminal)
cancellednone (terminal)

draft, inquiry and payment_pending_verification have no entry in the table and are not constrained by it.

Payment status

The order-level payment_status values. Create validates against exactly this set and rejects anything else with 400:

pending, pending_payment, partial_payment, paid, failed, refunded, overdue, partial_refund, disputed, chargebacked.

The last three are written by ibakepro's own refund and dispute handling. They are accepted on create.

On reads, payment_status is echoed back exactly as stored. Historical and imported orders can therefore carry values outside the set above. Treat an unrecognised payment_status as unknown rather than failing.

Payment method vocabularies

There are three distinct payment-method vocabularies. They are not interchangeable.

  1. Order-level payment_method. Free-form on create: it is stored and echoed back unchanged, with no validation. The values ibakepro's own surfaces write are stripe, paypal, square, shopify, bank_transfer, cash, card, other. Reads can carry any string.
  2. Payment-record method (the method on a payment you attach when creating an order). This is normalised against a fixed map, and anything unrecognised silently becomes other rather than returning an error. Recognised inputs: card, credit_card, bank_transfer, wire_transfer, cash, check, cheque, paypal, apple_pay, google_pay, afterpay, klarna, store_credit, imported, other. See Orders.
  3. Tenant payment methods from /reference/payment-methods. Free-form ids the account defines for its own bookkeeping. This page's endpoint is the authority for that list only.

Delivery type

pickup, delivery, dispatch.

dispatch is carrier shipping. Note that the type parameter on Time slots and Availability accepts only pickup or delivery: time slots are configured as pickup and delivery sets only, so there are no dispatch slots to return. A dispatch order also has its scheduled time forced to null on create.

Allergen levels

On a product's allergens array, each entry's level is one of: contains, may_contain, processed_in.