Find API IDs for queues, statuses, agents and custom-field choices

An API integration needs the identifier for a queue, status, agent or dropdown choice, rather than just the name people see on screen. API Reference IDs gives your operations team a read-only way to find those values. Use it when preparing an integration, checking a mapping after a configuration change, or helping a developer route cases to the right place. You do not need to guess IDs or inspect customer records to use this lookup.

Understand names, IDs and the two kinds of custom-field identifier  ·  Before you begin  ·  Find and copy an ID  ·  Choose the right catalog  ·  Worked B2B example: prepare equipment-support routing  ·  Troubleshoot missing or incorrect values

Understand names, IDs and the two kinds of custom-field identifier

A name is the readable label, such as “Technical Support.” An ID is the value an integration uses to refer to that definition. Similar names can exist in different hierarchies, and a number copied from another Supportbench account is not a reliable mapping for this account.

Before you begin

• Confirm that you are in the Supportbench account used by the integration. Do this before copying any IDs.
• You need access to the API settings section. The role permission is API access, and the page must be available for the account. This lookup has no edit or save operation.
• Have the integration’s intended action and API reference available. Know whether you are identifying a case status, an article status, a field definition or a field choice.
• Write down the visible business name and, if relevant, its parent or hierarchy. “Hardware → Pumps” is more useful than “Pumps” when several branches use similar labels.

This page shows reference definitions and selectable choices. It does not display the actual values customers have entered on their cases, contacts, companies or assets. Looking up an ID also does not give an integration permission to use it; the API connection has its own authorization.

Find and copy an ID

1. Open Settings → API → Data tables. The page heading is API Reference IDs.
2. Use the reference-type selector to choose one or more catalogs. Divisions is selected initially; remove it if it is unrelated to the task. You can keep several catalogs open for a mapping exercise.
3. Find the card for the catalog you need. Enter the visible name, a hierarchy path, or a known ID in that card’s search field. Search applies to that source, not to every selected catalog.
4. Read the matching row’s ID and Name. Check the full path when the catalog is hierarchical. Do not select a similarly named row just because it appears first.
5. Select Copy in that row’s Actions column. Paste it into your mapping notes or the specific API parameter required by the API reference.
6. Record the account, source catalog, readable name, copied ID and intended parameter together. This lets a colleague check the mapping without reverse-engineering a number.
7. If configuration has just changed, use that card’s Refresh control and find the value again before testing.

The table supports sorting by ID or name and page sizes of 50, 100 or 200. A card can be collapsed while you work on another source. There is no CSV/JSON export or copy-all action here; use the per-row Copy action. The lookup returns IDs as strings, but the API operation you call determines the required request type.

Choose the right catalog

Custom dropdown sources depend on the active, undeleted field definitions in this account. If a field was disabled, removed, changed to a different type, or belongs to another object, it may not appear where you expect. Check the field’s configuration before treating an absent option as a lookup failure.

Worked B2B example: prepare equipment-support routing

A support operations lead is helping an integration send equipment incidents to the right specialist team. The intended business mapping is a particular queue, a starting case state and an equipment-model dropdown choice. The lead owns the operational meaning; the developer owns the supported request and validation.

1. Write the intended outcome in words: “Create the incident for the correct customer, route it to the pump specialists, and record the model reported by the customer.”
2. Select Queues and find the exact specialist queue. Copy its ID and label the mapping queue_id.
3. Select Case states and identify the starting state required by the team’s process. Copy that ID separately.
4. Select Custom field definitions to find the equipment-model field’s definition ID. Then select that field’s dropdown source and find the intended choice ID.
5. Ask the developer to build the request using the current API reference. Do not infer a create/update payload from this lookup page alone.
6. Test through your agreed controlled process. Open the resulting case and check the actual customer, queue, state and displayed model. An accepted API response is not sufficient evidence that every mapping means what the team intended.

Keep the mapping with the integration’s operational handover. When the team renames or retires a queue or dropdown option, review the mapping and rerun the relevant verification. Do not assume that a copied numeric identifier remains suitable forever.

Troubleshoot missing or incorrect values

Continue learning

• Configure MCP connections and agent access
• Use connected AI tools in support operations
• Understand case workflow events and conditions