Documentation or API method for `option_id` information, for the `/flags/options` API calls?

Question

The Stack Exchange API has a couple of calls that return a list of flag_option objects.

These objects contain a couple of properties that can be used to identify the flag you need.
For example, when I want to cast a spam flag from an app, I used to look for a flag option with an title equal to "spam":

{"has_flagged":false,"option_id":46534,"title":"spam"},

This approach went down the drain when a user tried to cast a flag on a non-English SE site, since their flag options look a little different:

{"has_flagged":false,"option_id":46534,"title":"contenido no deseado"},

Now, the option_id is something else I can identify the proper option from, but these aren't documented anywhere (that I know of).

I'd rather not rely on my own interpretation of these ids from a couple of API calls, since mistakes in flagging just aren't acceptable.

---

TL;DR: Can these option_ids be documented on the flag_options page, or in an answer here?

Even these flag Ids aren't stable, and could change at any time.

---

Feature Request:

Please add an API route that tells me what option_id is used for what type of flag, for a specific site. (Where "type of flag" is a constant):

A call that'd return something like this:

{
    site: 'siteName',
    flag_options:{
        spam: x,
        rude_abusive: y,
        not_an_answer: z,
        <...>
    }
}

Answer 1

The original intent of these options is clearly not to enable automated flagging, but rather to allow an application to generate a UI that presents the applicable options to a user who would be expected to understand them.

With that in mind, the only safe way to identify a flag is by using an exact string match: one that takes into account the terms used for each flag in various translations.

Yes, this has the potential to fail if we rename (or re-translate) a particular option. But, it will fail by not finding an applicable flag rather than by finding the wrong one. Since you already need to handle this outcome for cases where a given post cannot be flagged (already deleted, etc.), your application should thus be able to avoid causing problems.

Answer 2

The official documentation is here:

Available flags vary from object to object, user to user, and site to site. An application should not assume that particular flags are always available, or that particular option_ids are stable.

Which isn't great. You may be able to get away with it, but there's nothing saying the option IDs can't change out from under you at any time.

Answer 3

Flag options are returned in a list items which is ordered in the same way as flag options in the web interface. If the list has one item, it's the mod-attention flag on a deleted post. Otherwise:

• items[0] is Spam
• items[1] is Rude/Abusive

For Answers:

• items[2] is Not An Answer
• items[3] is VLQ if the list has 5 items, or mod attention if it has 4.
• items[4], if it exists, is mod attention

For Questions (assuming user has at least 50 rep):

• items[2] is Should be Closed
• items[3] is a Duplicate
• items[4] is VLQ if the list has 6 items, or mod attention if it has 5
• items[5], if it exists, is mod attention

Users under 50 rep do not have the Close and Duplicate flag options.