Callback data shape : category_id vs category_slug

I could have this wrong, but it looks like the data returned by a ‘post’ callback has category_slug but no category_id, while the data returned by a ‘topic’ callback has a category_id but no category_slug.

If that is the case (and I’m not missing a configuration somewhere) would be nice if both callbacks standardised on either category_id or category_slug or returned both.

It would also be most excellent if both types had parent_category_id and parent_category_slug if arriving from a post or topic in a subcategory. Right now both provide category_id which doesn’t indicate whether it’s a category or subcategory.

1 Like

Is there any intention to update webhooks to always include both category_id and category_slug, regardless if the webhook is for a ‘post’ or a ‘topic’?

The current ‘post’ callback information is suboptimal because there is no reliable way to determine which category it belongs with…as (if I understand correctly) category_slug does not have to be unique. If you have a couple different categories, each with three subcategories with the same slugs (because you need the subcategory nav to look the same to the user), you can’t tell which subcategory the ‘post’ was done in just by the slug.

I’m not a Ruby developer but I wonder if there’s a bug in the post_serializer class:

def include_category_id?

Shouldn’t that be:

def include_category_id?

I made a PR to show this change. Could be crazy talk but might help dig out the true solution…


Alternatively, if there is no problem with post_serializer, but it is a problem that ‘post’ webhooks aren’t returning a category_id…

couldn’t the following code be added to web_hook_post_serializer.rb:

  def include_category_id?

(Just as a similar method is already there for include_topic_title?)…

Unfortunately we can’t make these changes ourselves as we have a paid hosted account on Discourse.

Yes this works. I’ve added it:

As a hosted customer you will get it the next time your forum is deployed.