What an integrator hits
Told "integrate Sendly", every discovery path leads somewhere else:
- The repo is
sendly-js; the package is sendly-sdk. Neither name finds the other. The repo description says "Official Sendly JavaScript/TypeScript SDK for the sendly.now email platform" without ever naming the npm package, so someone who lands here still has to guess the install line.
npm search sendly surfaces the unrelated SMS product sendly.live first (@sendly/node, @sendly/cli, @sendly/mcp), plus the decoys @sendlyapi/node, @sendlyapp/sdk and a bare sendly.- Context7 (
resolve-library-id: "sendly-sdk") returns exactly one hit: /websites/sendly_live — "an API for sending SMS messages globally". There is no Context7 entry for sendly.now at all. Verified 2026-09-03.
So an agent-assisted integration installs an SMS SDK. We only avoided it because the exact package name had been pinned by hand beforehand.
Compounding it: the docs are unreachable to agents
GET https://docs.sendly.now/sdks with a non-browser User-Agent → 403 (Cloudflare). The same URL from a desktop browser → 200. Sendly ships a well-made llms.txt index and hand-written SDK docs, and an AI-assisted integration cannot read any of it without spoofing a browser.
For a product whose documentation is plainly written for agents, the bot rules work directly against the docs strategy — and they remove the one channel that would have corrected the naming confusion above.
Suggested fixes
- Put the install line (
npm i sendly-sdk) in the repo description and at the top of the README, so the two names are connected wherever someone lands.
- Consider renaming the repo to
sendly-sdk to match the published artifact.
- Claim a Context7 entry for
sendly.now, so the SMS product stops being the only answer.
- Allow well-known AI fetcher user-agents through Cloudflare, or at minimum serve
llms.txt, llms-full.txt and openapi.json outside the bot rules. (Not a code change in this repo, but it is the single highest-cost item in the integration and this is where the SDK audience is.)
Context
Found while migrating a production app onto Sendly. Verified 2026-09-03.
What an integrator hits
Told "integrate Sendly", every discovery path leads somewhere else:
sendly-js; the package issendly-sdk. Neither name finds the other. The repo description says "Official Sendly JavaScript/TypeScript SDK for the sendly.now email platform" without ever naming the npm package, so someone who lands here still has to guess the install line.npm search sendlysurfaces the unrelated SMS product sendly.live first (@sendly/node,@sendly/cli,@sendly/mcp), plus the decoys@sendlyapi/node,@sendlyapp/sdkand a baresendly.resolve-library-id: "sendly-sdk") returns exactly one hit:/websites/sendly_live— "an API for sending SMS messages globally". There is no Context7 entry for sendly.now at all. Verified 2026-09-03.So an agent-assisted integration installs an SMS SDK. We only avoided it because the exact package name had been pinned by hand beforehand.
Compounding it: the docs are unreachable to agents
GET https://docs.sendly.now/sdkswith a non-browser User-Agent → 403 (Cloudflare). The same URL from a desktop browser → 200. Sendly ships a well-madellms.txtindex and hand-written SDK docs, and an AI-assisted integration cannot read any of it without spoofing a browser.For a product whose documentation is plainly written for agents, the bot rules work directly against the docs strategy — and they remove the one channel that would have corrected the naming confusion above.
Suggested fixes
npm i sendly-sdk) in the repo description and at the top of the README, so the two names are connected wherever someone lands.sendly-sdkto match the published artifact.sendly.now, so the SMS product stops being the only answer.llms.txt,llms-full.txtandopenapi.jsonoutside the bot rules. (Not a code change in this repo, but it is the single highest-cost item in the integration and this is where the SDK audience is.)Context
Found while migrating a production app onto Sendly. Verified 2026-09-03.