Catalogue references

Use these reads to reconcile existing catalogue references before importing. Every result belongs to the API key’s house.

All collections use limit and cursor. Makers support an exact slug filter and active=true|false; without the latter both states are included. Maker results include type, active, name, short description and description. Delivery classes include name, description and position; pagination follows position, then public UUID. These are instructions such as “collection only”, not checkout shipping rates.

Names and descriptions use exactly the house’s default language. Missing copy is null, with no fallback to another language. The new maker and delivery-class detail routes accept the prefixed ID or its bare UUID, including uppercase UUID letters. Unknown filters, unsupported expansions and malformed values return 400; foreign or wrong-prefix IDs return 404. A legacy record without a valid public identity produces a 500 problem rather than an invented ID.

curl "$BIDVISE_API/api/v2/makers?slug=example-workshop&active=true" \
  -H "Authorization: Bearer $BIDVISE_API_KEY"

curl "$BIDVISE_API/api/v2/delivery_classes?limit=100" \
  -H "Authorization: Bearer $BIDVISE_API_KEY"

Existing makers and delivery classes can be assigned through item writes. Creating or changing the reference records themselves remains outside these read routes. Earlier draft documentation called delivery classes shipping_classes; that route was never implemented. Use delivery_classes. Priced shipping methods and custom fields remain planned.

Examples of returned identities: mkr_2d9f6b31-8e4a-4c05-b7d2-9a1e3f8c6047 and dlc_b48e0a19-5c72-4d83-91af-3e6b2c07d514. Use the actual ID returned for your house in detail requests.

Increment strategies

GET /increment_strategies and GET /increment_strategies/{id} expose the existing bid increment configurations with inc_ identities. These require bidding_step_configurations.read, the same permission as bid steps in the backoffice. lots.read or auctions.read alone does not grant access.

The list supports limit, cursor and an exact, case-sensitive name filter. Names need not be unique: reconcile all matches and retain the returned ID. Pagination orders by creation time, then public UUID. Deleted configurations are excluded. Detail accepts a prefixed ID or bare UUID, including uppercase UUID letters; foreign, deleted and wrong-kind IDs return 404. Names are stored directly, without translations.

curl --get "$BIDVISE_API/api/v2/increment_strategies" \
  --data-urlencode "name=Default" \
  -H "Authorization: Bearer $BIDVISE_API_KEY"

Each strategy contains id, name, ordered steps, created_at and updated_at. Each step has until and step_size, both Money objects in minor units of the house currency:

{ "until": { "amount": 10000, "currency": "EUR" },
  "step_size": { "amount": 500, "currency": "EUR" } }

This means steps of €5 up to and including €100. A tier starts above the previous tier’s until (zero for the first tier). The response describes the stored ladder; it does not calculate a lot’s next permitted bid. These routes neither create configurations nor assign them to sessions. Session setup writes remain planned.

Example identity: inc_2d9f6b31-8e4a-4c05-b7d2-9a1e3f8c6047. Use the ID returned for your house.

Existing consignments

GET /consignments and GET /consignments/{id} require seller_profiles.read. Lists accept exact reference and typed seller filters plus limit and cursor; order is creation time then UUID. Deleted consignments are excluded. Each result contains its con_ ID, reference, seller, optional auction, locked flag and timestamps. Notes, commission terms and personal contact details are excluded. An unavailable seller/auction relationship is null.

Example ID: con_2d9f6b31-8e4a-4c05-b7d2-9a1e3f8c6047. Use the returned house-owned ID when assigning an existing consignment through item writes. Consignment creation, terms editing and locking or releasing a consignment are not available through v2.