Items

Vanilla materials, custom model data, glow, and items from ItemsAdder, Oraxen, and Nexo.

The item: section of a voucher defines what the held item looks like. The same item references are also used by the item reward.

item:
  material: PAPER          # vanilla material (default)
  custom: ""               # optional provider item, see below
  custom-model-data: 0     # optional resource-pack model id
  glow: true               # optional enchant glint

Vanilla materials

material is a Bukkit material name, such as PAPER, TRIPWIRE_HOOK, NETHER_STAR, or DIAMOND_SWORD. It is validated when you reload, so a typo like DIMAOND is reported by /voucher reload rather than failing when the voucher is given.

Lower case and the minecraft: prefix are both accepted (paper, minecraft:paper).

Glow

item:
  material: PAPER
  glow: true

glow: true adds the enchantment glint without showing any enchantment in the tooltip. It works with no resource pack.

Enchantments, durability, and trim

Any item (a voucher's own icon or a defined reward item) can carry extra appearance:

item:
  material: DIAMOND_CHESTPLATE
  enchantments:          # key: level, validated at load
    protection: 4
    unbreaking: 3
  damage: 50             # durability damage
  unbreakable: true      # never loses durability
  trim:                  # armor only
    material: quartz
    pattern: sentry
  item-model: "minecraft:diamond_chestplate"   # modern model selector (1.21.4+)
  hide-tooltip: false    # hide the item's entire tooltip
  color: "#FF5555"       # dye leather armor, potions, or maps

Real enchantments glint on their own, so glow is only needed on an item without them. item-model is the successor to custom model data; set whichever your resource pack uses.

color dyes leather armor, tints a potion, or colors a filled map; it is ignored on any other material. The value is a named color (red, lime, light_blue, ...), a #RRGGBB hex string, or an r,g,b triple (255,85,85).

Custom model data

item:
  material: PAPER
  custom-model-data: 1001

custom-model-data is a number a resource pack maps to a custom model. With no pack installed it has no visible effect (the item renders as normal PAPER). Use it when you already serve a pack that defines the model for that number.

Want to test custom model data quickly? A tiny pack can remap a vanilla item to a different vanilla model by number, so you can confirm it works without drawing a texture. ItemsAdder, Oraxen, and Nexo also assign custom model data automatically to their items (see below).

Custom provider items (ItemsAdder, Oraxen, Nexo)

Instead of a vanilla material, you can reference an item from a custom-item plugin with custom: "provider:id":

A voucher whose icon is an ItemsAdder item

item:
  custom: "itemsadder:ax_wings_pack:phoenix_wings"
  glow: true
display-name: "<gradient:#FF4500:#FFD700>Phoenix Wings Voucher</gradient>"
lore:
  - "<gray>Right-click to claim your wings"

The text before the first colon is the provider (itemsadder, oraxen, nexo); the rest is that provider's own item id (which may itself contain colons, as ItemsAdder namespaces do). The provider's model is used, and your display-name and lore are applied on top. If you omit display-name, the provider item keeps its own name.

Oraxen and Nexo look the same

item:
  custom: "oraxen:cool_sword"

Nexo

item:
  custom: "nexo:magic_wand"

Requirements

Custom provider items are resolved through built-in item hooks for ItemsAdder, Oraxen, Nexo, and Head Database, so you only need the provider plugin installed and its item to exist. An unknown provider name (anything other than itemsadder, oraxen, nexo, or headdatabase) is reported by /voucher reload rather than silently ignored. If a known provider's plugin is missing or the id is wrong, the voucher falls back to its material (default PAPER), so if a custom item shows up as paper, check the provider plugin is installed and the id is correct.

This is a deliberate design choice: support is by capability, so every provider works the same way, with no ProVouchers-specific configuration.

Player heads and custom skulls

A voucher item can be a player head, defined with a skull: block instead of (or alongside) a material. The head is built by ProVouchers itself, with no third-party plugin.

A stable custom head from a base64 texture

item:
  skull:
    source: texture
    value: "eyJ0ZXh0dXJlcyI6eyJTS0lOIjp7InVybCI6..."
  glow: true

From a Minecraft texture URL

item:
  skull:
    source: url
    value: "http://textures.minecraft.net/texture/abc123..."

A specific player's head (by name or UUID)

item:
  skull:
    source: player        # alias of name
    value: "Notch"

`source`	Value	Notes
`texture` (`base64`)	base64 `textures` value	Stable, no network. Best for permanent icons.
`url`	a `textures.minecraft.net` URL	Stable, no network.
`name` (`player`)	a player name	Resolves the current skin from Mojang (async); the skin can change.
`uuid`	a player UUID	Resolves the current skin from Mojang (async).

Prefer texture or url for permanent voucher icons: they need no lookup and do not change when a player changes their skin. name/uuid are resolved off-thread and suit dynamic "this player's head" displays. Bad sources and invalid UUIDs are caught by /voucher reload.

Heads from Head Database

Head Database heads are custom items, so they use the custom: field (and the item: reward), exactly like ItemsAdder:

item:
  custom: "headdatabase:7129"   # or hdb:7129

This needs Head Database installed.

Using provider items as rewards

The same references work as rewards, so a voucher can give a custom item:

rewards:
  - "item: itemsadder:ax_wings_pack:phoenix_wings 1"
  - "itemsadder: ax_wings_pack:phoenix_wings"   # shorthand, same result

See Rewards for the full item-reward syntax, amounts, and the provider keyword shorthand.

Advanced item options

Per-item details such as dyes, trims, banner patterns, and stored enchantments are not yet expressed as config keys. For those, use a provider item (ItemsAdder, Oraxen, Nexo) which already encodes the full item, or give the item through a command: reward.

ProVouchers can also store a fully serialized item: a serialized: reference that captures every detail of a real item (enchantments, name, lore, model data, attributes, and other components) exactly. The in-game command to capture a held item into one is planned for a later release, so for now a provider item or a command: reward is the practical route to a fully custom item.

On this page