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":


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',
        spam: x,
        rude_abusive: y,
        not_an_answer: z,
  • The option_id for spam seems stable across all sites. See meta.stackexchange.com/questions/288216/… Commented Apr 10, 2017 at 8:07
  • 1
    @AwesomePoodles: Thanks for the link. That answer also states that the options aren't exactly stable. That would mean there's no proper, secure way to identify a "vlq" flag, for example...
    – Cerbrus
    Commented Apr 10, 2017 at 8:13
  • You could ask for the output of Transifex for the word spam of all localizations?
    – rene
    Commented Apr 10, 2017 at 16:06

3 Answers 3


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.

  • 1
    Could we get the "Feature Request" part of the (revised) question? Trying to keep up with constantly changing translations is a poor way to live. ;) Commented Jul 5, 2017 at 20:39

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.

  • 1
    Yea, I was hoping there was something more permanent out there somewhere. Maybe there should be a API method to get flag options types...
    – Cerbrus
    Commented Apr 10, 2017 at 15:01

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.

  • 2
    Unless a post has been deleted, then items[0] can be "Requires moderator intervention". We can't really rely on their order.
    – Cerbrus
    Commented Apr 10, 2017 at 17:04
  • True; but the length of the list would indicate that.
    – user43888
    Commented Apr 10, 2017 at 17:05
  • 7
    And that's what I don't want to rely on. The more variables, (order, list length), the more possibility there is for the wrong flag to be applied.
    – Cerbrus
    Commented Apr 10, 2017 at 17:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .