73 lines
3.6 KiB
Markdown
73 lines
3.6 KiB
Markdown
# Verifying SaaS "API Available" Claims
|
|
|
|
When a vendor claims "REST API" or "API-ready" but offers no public developer portal, use this systematic verification pattern.
|
|
|
|
## The BlueNotary Case Study (Jul 2026)
|
|
|
|
BlueNotary (bluenotary.us) markets itself as "developer-friendly REST API" and "fully white-labeled and API-ready" on their integrations page, with a prominent "See API Docs" button. **No actual API documentation exists publicly.**
|
|
|
|
### Verification probe pattern
|
|
|
|
```bash
|
|
# 1. Check all common API/doc subdomain patterns
|
|
for sub in api docs developers developer help support; do
|
|
curl -sL --max-time 10 "https://$sub.bluenotary.us" 2>&1 | grep '<title>' | head -1
|
|
done
|
|
# Result: help subdomain has helpdesk; all others empty/no DNS
|
|
|
|
# 2. Check common API/doc paths on main domain
|
|
for path in api developers docs developer-api api-reference api-documentation api-docs; do
|
|
curl -sL --max-time 10 "https://example.com/$path" 2>&1 | grep '<title>' | head -1
|
|
done
|
|
# Result: all return 404 (WordPress "Page not found")
|
|
|
|
# 3. Check app subdomain for API paths
|
|
curl -s "https://app.bluenotary.us/api/docs"
|
|
# Result: {"errors":{"msg":"URL_NOT_FOUND"}}
|
|
|
|
# 4. Check raw API endpoint
|
|
curl -s "https://api.bluenotary.us"
|
|
# Result: empty (no DNS)
|
|
|
|
# 5. Search the integrations page for actual API documentation text
|
|
curl -sL "https://bluenotary.us/integrations" | grep -i -E '(rest|endpoint|webhook|swagger|openapi|api key|api token|developer documentation)'
|
|
# Result: only meta keywords mention "notary API" — no technical docs text
|
|
|
|
# 6. Check business-for page for API section text
|
|
curl -sL "https://bluenotary.us/for-businesses" | grep -i -E 'api|documentation'
|
|
# Result: JavaScript template literal references "See API Docs" CTA but no actual docs
|
|
|
|
# 7. Check pricing page for API mention
|
|
curl -sL "https://bluenotary.us/pricing" | grep -i -E 'api|integration'
|
|
# Result: No API mention in any pricing tier
|
|
```
|
|
|
|
### Red flags
|
|
|
|
| Signal | Meaning |
|
|
|--------|---------|
|
|
| "See API Docs" button redirects to integrations page | Docs don't exist — button is a marketing placeholder |
|
|
| API is listed as meta keywords but not in pricing tiers | API is enterprise-only, sales-gated |
|
|
| App subdomain returns `URL_NOT_FOUND` for `/api/docs` | No internal API doc route exists |
|
|
| Developer subdomains have no DNS records | No developer portal has ever been stood up |
|
|
| Enterprise tier requires "Contact Sales" | API access is custom-priced, not self-service |
|
|
|
|
### Diagnosis
|
|
|
|
If all common API/doc paths return 404 and no subdomains resolve:
|
|
- **The API may not exist yet** — it's a roadmap item being sold to enterprise prospects
|
|
- **The API is gated behind a sales conversation** — you cannot evaluate it independently
|
|
- **No sandbox/test keys are available** — integration timeline is undefined
|
|
|
|
### Action items for ambiguous API claims
|
|
|
|
1. **Do not assume API availability based on marketing copy** — "API-ready" often means "we can build it for you if you pay enough"
|
|
2. **Probe all doc paths before making any recommendation** — don't stop at the landing page
|
|
3. **Report the absence transparently** — say "no public API docs found" rather than guessing
|
|
4. **Recommended next step**: Book a sales demo, but set expectations that without published docs, integration lead time is 4-8 weeks minimum
|
|
5. **Alternative**: Look for a competitor with published API documentation (e.g., OneNotary at dev.onenotary.us, Proof/Notarize)
|
|
|
|
### Keep this reference
|
|
|
|
This pattern works for any SaaS vendor that claims API support on their marketing site but doesn't link to actual documentation. Pre-built API doc site builders (ReadMe, Stoplight, SwaggerHub) follow predictable URL patterns — their absence is a clear signal.
|