Add Algolia plugin#67
Conversation
| "baseDataSourceName": "httpRequestScopedSingle", | ||
| "config": { | ||
| "httpMethod": "get", | ||
| "baseUrl": "https://analytics.{{dataSource.analyticsRegion || 'us'}}.algolia.com", |
There was a problem hiding this comment.
Wondering if this should be the primary baseUrl and only override it for the indexes data stream?
There was a problem hiding this comment.
Good point, have swapped it around
|
@claude review once |
🧩 Plugin PR Summary📦 Modified Plugins
📋 Results
🔍 Validation Details✅
|
| "importNotSupported": false, | ||
| "restrictedToPlatforms": [], | ||
| "keywords": ["algolia", "search", "analytics", "index", "search analytics"], | ||
| "objectTypes": ["Algolia Index"], |
There was a problem hiding this comment.
🔴 The 'Algolia Index' → 'Index' sourceType rename in commit e4473e5 was incomplete: metadata.json:13 still declares "objectTypes": ["Algolia Index"] (now out of sync with the renamed sourceType in custom_types.json, indexDefinitions/default.json, scopes.json and all four scoped data streams), and docs/README.md:39 ('What gets indexed' table) still labels the object type as Algolia Index even though custom_types.json declares singular: "Index" / plural: "Indices" so the UI now displays 'Index'/'Indices'. Update both occurrences to 'Index'. (Line 8's 'Algolia Index perspective' is fine — that's the dashboard name in algoliaIndex.dash.json, which legitimately remains 'Algolia Index'.)
Extended reasoning...
What the bug is
Commit e4473e5 ("Rename Algolia sourceType to Index as per guidelines") renamed the source type identifier from Algolia Index to Index across the plugin in response to an earlier review comment. The rename was applied to seven files but two occurrences were missed, leaving the plugin internally inconsistent and the user-facing documentation disagreeing with what the UI will actually display.
Where the rename was applied (correctly)
custom_types.json:3-4—nameandsourceTypeboth set to"Index"(withsingular: "Index"/plural: "Indices"providing the friendly display name)indexDefinitions/default.json:10—type.value: "Index"(this is the type every imported object is stamped with)defaultContent/scopes.json—sourceType.values: ["Index"]dataStreams/noResultRate.json,dataStreams/noResultSearches.json,dataStreams/searchCount.json,dataStreams/topSearches.json— all fourmatches.sourceType.valueset to"Index"
Where the rename was missed
1. plugins/Algolia/v1/metadata.json:13
"objectTypes": ["Algolia Index"]The objectTypes field advertises which source types this plugin emits (used by the SquaredUp catalogue and type filters). It must match the actual emitted sourceType — but after the rename it doesn't. Sibling plugins confirm this convention: UptimeRobot/v2/metadata.json lists every type from its custom_types.json in objectTypes, and WorldCup2026/v1/metadata.json lists "World Cup Team" exactly matching its custom_types.json sourceType.
2. plugins/Algolia/v1/docs/README.md:39
| **Algolia Index** | A single search index in your application | ... |After the rename, custom_types.json declares singular: "Index" / plural: "Indices", so the SquaredUp UI displays these objects as Index (singular) / Indices (plural) — not 'Algolia Index'. The README's user-facing 'Object type' column therefore disagrees with what the user will actually see in product.
What is intentionally NOT affected
The string 'Algolia Index' legitimately remains in two places that are not sourceType references:
README.md:8— "…and an Algolia Index perspective…" refers to the dashboard whosenameis literally"Algolia Index"inalgoliaIndex.dash.json:2(and the scope variable name"Algolia Index"inscopes.json). The dashboard/scope display name is separate from the sourceType.algoliaIndex.dash.json:2—"name": "Algolia Index"(the dashboard's display title).
These are correct and should be left as-is.
Impact
- metadata.json: minor —
objectTypesis used for catalogue/type-filter advertising. The plugin imports and queries indices correctly because every functional matcher uses"Index". But the metadata advertises a sourceType that the plugin no longer emits, which is an internal inconsistency in a brand-new plugin and directly contradicts the stated goal of commit e4473e5. - README.md: cosmetic/documentation — the docs claim the type is called 'Algolia Index' while users will see 'Index'/'Indices' in the UI. Documentation/UI drift on a brand-new plugin where the cost of fixing it is one line.
How to fix
Two one-line edits:
# plugins/Algolia/v1/metadata.json line 13
- "objectTypes": ["Algolia Index"],
+ "objectTypes": ["Index"], # plugins/Algolia/v1/docs/README.md line 39
-| **Algolia Index** | A single search index in your application | ... |
+| **Index** | A single search index in your application | ... |Step-by-step proof
grep -rn '"Algolia Index"\|Algolia Index' plugins/Algolia/v1— five hits.- Two of those (
algoliaIndex.dash.json:2dashboard name,README.md:8perspective reference) refer to the dashboard/scope display name, which is correctly still"Algolia Index". - One (
scopes.json) refers to the scope's ownnamefield — also a display name, correctly preserved. - The remaining two —
metadata.json:13(objectTypes) andREADME.md:39('Object type' table) — are sourceType references that should have been renamed. - Cross-reference
custom_types.json:3-4:name: "Index",sourceType: "Index",singular: "Index",plural: "Indices"— confirms the rename target. - Cross-reference
indexDefinitions/default.json:10and all four scoped data streams'matches.sourceType.value— all"Index". - Therefore the two unrenamed occurrences are leftovers from the incomplete commit, not intentional.
| @@ -0,0 +1,50 @@ | |||
| ## What this plugin monitors | |||
There was a problem hiding this comment.
🟡 README headings start at level 2 (##) — line 1 opens with ## What this plugin monitors and the other top-level sections (lines 10, 27, 35, 43) are also ##. REVIEW.md:88 says "Should typically start headings from level 1. When embedded in SquaredUp, the headings will be sized appropriately", and every other plugin README in the repo (DigiCert, GoogleSheets, UptimeRobot, Huntress, Spotify, NinjaOne, UniFi, etc.) starts with #. Looks like an over-correction to the earlier # Algolia review nudge — dropping a level rather than renaming the heading. Promote the five top-level section headings back to #. Cosmetic nit only.
Extended reasoning...
What the issue is
plugins/Algolia/v1/docs/README.md opens with ## What this plugin monitors (a level-2 heading) and every other top-level section in the file (lines 10, 27, 35, 43 — ## Prerequisites — getting your credentials, ## Configuration fields, ## What gets indexed, ## Known limitations) is also level 2. There are no level-1 (#) headings anywhere in the file.
Why it matters
REVIEW.md:88 spells the convention out explicitly: "Should typically start headings from level 1. When embedded in SquaredUp, the headings will be sized appropriately." The README is rendered in-product under a built-in "Need help?" panel, and the in-product styling assumes the document's outer-most heading level is # — so a README that starts at ## ends up rendered with subtly wrong sizing/hierarchy relative to every other plugin's docs.
How this slipped through
This looks like an over-correction to the earlier review nudge against # Algolia as the opening heading. That earlier comment (inline #3433498073) correctly flagged # Algolia as a heading that just repeats the plugin name and recommended replacing it with something like # Before you start or # Prerequisites. The author instead dropped every top-level heading by one level — so the file went from # Algolia + ## ... to all ## — which now violates a different piece of the same REVIEW.md section. The intended fix is to keep the headings at level 1 but rename the first one (e.g. to # Before you start or by promoting ## Prerequisites — getting your credentials to be the first heading).
Convention across the repo
A sweep of every other plugin README under plugins/*/v*/docs/README.md confirms the convention is dominant and consistent: DigiCert, GoogleSheets, UptimeRobot, Huntress, Spotify, NinjaOne, UniFi, DattoRMM, AutoTask, Phare, Steam, WorldCup2026, RSS all start with a level-1 # Before you start; MicrosoftDefender uses # Configuring the data source. Algolia is the only outlier opening with ##. (SumoLogic also starts ## Setup, so the convention isn't strictly enforced — but it is documented and is the standard.)
Impact
Cosmetic only — no functional effect on validation, deployment, or runtime. The plugin loads and renders fine; the only consequence is that headings render with subtly wrong sizing inside the "Need help?" panel and the README's heading hierarchy doesn't match peer plugins'. Severity is nit.
How to fix
Promote the five top-level section headings from ## to #:
-## What this plugin monitors
+# What this plugin monitors
...
-## Prerequisites — getting your credentials
+# Prerequisites — getting your credentials
...
-## Configuration fields
+# Configuration fields
...
-## What gets indexed
+# What gets indexed
...
-## Known limitations
+# Known limitationsOr, to also address the earlier "don't repeat the plugin name" guidance simultaneously, rename the first heading to # Before you start while promoting the rest.
Step-by-step proof
- Open
plugins/Algolia/v1/docs/README.md— line 1 is## What this plugin monitors. There are no#(single-hash) headings anywhere in the file. - Open
REVIEW.mdline 88 — "Should typically start headings from level 1. When embedded in SquaredUp, the headings will be sized appropriately." - Open any other plugin README (e.g.
plugins/DigiCert/v1/docs/README.md,plugins/UptimeRobot/v2/docs/README.md,plugins/Huntress/v1/docs/README.md) — every one starts with a#heading. - Conclusion: the Algolia README is the only one in the repo that opens at level 2 and the only one with no level-1 heading at all; promote the top-level headings to
#to match the documented convention.
| { | ||
| "type": "password", | ||
| "name": "apiKey", | ||
| "label": "API Key", |
There was a problem hiding this comment.
🟡 ui.json:13 sets "label": "API Key" for the API key field. REVIEW.md's displayName/label guidance gives "API key" (lowercase k) as the canonical example ("First word uppercase, then lowercase (e.g. 'Table name', or 'API key')"), and repo consensus is overwhelming: 9 existing plugins use "API key" (Rootly, DattoRMM, UptimeRobot, Phare, SendGrid, MetOffice, Checkly, DigiCert, Postcoder) vs only 1 (UniFi) using "API Key". Recommend changing line 13 to "label": "API key" for consistency with the documented convention.
Extended reasoning...
What the issue is
plugins/Algolia/v1/ui.json line 13 declares:
{
"type": "password",
"name": "apiKey",
"label": "API Key",
...
}The label "API Key" uses an uppercase "K" on the second word. The repository's REVIEW.md guidance for ui.json label/displayName fields is explicit on capitalization style:
First word uppercase, then lowercase (e.g. "Table name", or "API key").
Notably, "API key" is literally the example chosen in the guidance — not a coincidence; it's the exact case being violated here.
Repo-wide consensus
A grep over plugins/**/ui.json confirms the documented convention is also the dominant repo pattern:
- 9 plugins use "API key" (lowercase k): Rootly, DattoRMM, UptimeRobot, Phare, SendGrid, MetOffice, Checkly, DigiCert, Postcoder.
- Only 1 other plugin uses "API Key" (uppercase K): UniFi.
So with Algolia, the count is 9 conforming vs 2 outliers. For a brand-new plugin, following the documented example and the established 9-to-1 majority is the lower-friction choice.
Impact
Cosmetic only — there is no functional or validation impact. The plugin loads, deploys, and authenticates correctly. The label is purely a UI string shown next to the password input on the plugin configuration form.
The cost of leaving it as-is is small but non-zero: the configuration form for this plugin will display "API Key" while ~9 other plugins in the SquaredUp catalogue display "API key" for the equivalent field. On a brand-new plugin shipping for the first time, the convention cost of fixing it is near zero.
How to fix
One-character change on line 13 of plugins/Algolia/v1/ui.json:
- "label": "API Key",
+ "label": "API key",Step-by-step proof
- Open
plugins/Algolia/v1/ui.jsonline 13 — observe"label": "API Key". - Open
REVIEW.mdand locate the ui.jsondisplayName/labelguidance — confirms the rule "First word uppercase, then lowercase" with "API key" given as the canonical example. - Run
grep -rh '"API [Kk]ey"' plugins/**/ui.json— returns 9 occurrences of "API key" (Rootly, DattoRMM, UptimeRobot, Phare, SendGrid, MetOffice, Checkly, DigiCert, Postcoder) and 2 occurrences of "API Key" (UniFi + this PR). - Conclusion: "API key" (lowercase k) is both the documented example and the dominant pattern by a wide margin. Severity is nit — purely cosmetic, but worth aligning on a new plugin while the change is trivial.
🔌 Plugin overview
X-Algolia-Application-Id/X-Algolia-API-Keyheaders (an Admin key, or a custom key with thelistIndexes,settingsandanalyticsACLs).🖼️ Plugin screenshots
Plugin configuration
Default dashboards
🧪 Testing
Built and tested end-to-end against a live, authenticated Algolia application in a SquaredUp tenant (every data stream tested live, not just authored):
configValidationAuthenticate step (List Indices) probed viasquaredup testreturned HTTP 200.squaredup indexcompleted successfully; 13Algolia Indexobjects imported (records, data/file size, last build time, pending tasks) and confirmed present in the graph.squaredup test:indexes(account-wide) — one flat row per index, correct numeric types.searchCount,noResultRate,topSearches,noResultSearches(per-index, scoped) — tested against two different indices each and confirmed they return differing results (e.g.cloud_docs≈ 551 searches/7d vsce_docs≈ 2); empty results for zero-traffic indices confirmed as valid HTTP 200 rather than errors.https://{{applicationId}}.algolia.nethost; Analytics streams overrideconfig.baseUrltohttps://analytics.{{region}}.algolia.com. Auth headers (set once at plugin level) work across both hosts; analytics region resolved and confirmed.squaredup validatepasses (5 data streams, 1 import definition, UI, icon, default content, config validation, custom types) and the plugin deploys cleanly.baseUrlincludes a|| 'us'fallback so an accepted default still resolves correctly.listIndexesACL required — a Search-Only key will fail setup validation because it cannot list indices..tmpreindex indices are imported as objects and may appear/disappear between imports — a normal Algolia reindex artefact, not a plugin bug.📚 Checklist