Why do some API list field values return text instead of numeric IDs?
When retrieving list field values through the Bob API, you may notice that some values are returned as numeric IDs while others are returned as human-readable text. This behavior is expected.
Why does this happen?
The format depends on when the list value was originally created:
- List values created before December 2021 use legacy string-based identifiers. The API returns these values as their display text.
- List values created after December 2021 are assigned unique numeric IDs. The API returns these numeric IDs.
This applies regardless of when your organization’s Bob account was created. Some default Bob system values were created before December 2021 and therefore continue to use the legacy format.
Can I make all values return numeric IDs?
If your integration requires consistent numeric IDs, you can:
- Create new replacement list values.
- Update employees to use the new values.
- Archive the legacy values once they are no longer in use.
Newly created list values receive numeric IDs and will be returned as numeric IDs by the API.
Can I make all values return text?
In some API endpoints, yes. The humanReadable parameter determines the format of the data returned in the response.
The available values are:
- If not sent: The response includes only machine-readable values (numeric IDs, where applicable).
- APPEND: include the additional "humanReadable" JSON node in the response.
- REPLACE: supply only humanReadable values in the JSON response instead of machine-readable values.
If your integration requires display names instead of numeric IDs, check whether the endpoint you’re using supports the humanReadable parameter and choose the option that best fits your use case.