Hey everyone 
I wanted to share a small project I built that may be useful for people running Ghost CMS blogs or publications.
It’s called Quick Search UI, a lightweight, fast search experience made specifically for Ghost sites. It provides instant, as-you-type search with relevant results, supports synonyms and stop words, and includes a simple analytics dashboard so you can see what readers are searching for.
What it offers:
• Very fast, real-time search results
• One-time setup by adding a small snippet to your Ghost theme
• Indexes full post content, not just titles & excerpts
• Automatic syncing with your Ghost content
• Search analytics to track popular queries
There’s a 14-day free trial if you’d like to give it a try: https://www.quicksearchui.com/
I’m offering 50% off forever on the yearly plan ($36) for early users.
Would love any feedback, questions, or suggestions. Happy New Year 
2 Likes
Interesting, my only question is why you need an admin api key and not just a content api key, thanks!
1 Like
It is presumably using the admin api key to set up webhooks and/or index members-only content.
But just a reminder to all that your admin api key gives someone very broad abilities on your site. Share with caution.
6 Likes
Hi @ngeorger, Thank you for showing interest.
As @Cathy_Sarisky mentioned, an admin API key is used to set up webhooks and index members-only content. If you are concerned about sharing the admin key, you can regenerate it at any time(Ghost Settings), which will disable the previous key. After regenerating, the reindexing feature will no longer be available, but all other functionality will continue to work as expected.
Thanks,
1 Like
When re-indexing is a need?
Bulk actions like unpublishing multiple posts or adding and removing tags do not trigger webhooks. Also, in some cases webhooks may fail to fire, especially on self-hosted setups. In these situations, re-indexing is needed to make sure everything is synced correctly.
1 Like
Fair. I think we need fine-grained Admin API key permissions.
| Resource |
Access |
| Posts/Pages |
Read / Write / Delete |
| Theme |
Read / Write / Delete |
| Members |
Read / Write / Delete |
| Webhooks |
Add / Remove / List (Only own webhooks) |
And so on…
A nice feature to work on 
4 Likes
Yes, that would be a very useful feature.
Meanwhile, a contributor staff key is almost a read only key.
1 Like
I think the Staff access token is access-controlled (though I’ve never tested it). Also, it does not support webhooks.
Hmm, I can see Staff access tokens can be used wisely for external tools. But I’ll continue on a new topic to not change the context of this topic anymore
1 Like