# Bog — API Agent Score

> Score: 78/100 (Grade: B) | Domain: bog.ge | Rubric: 1.0.0 | Checked: October 22, 2026

Bog scored 78/100 (B), classified "partially-ready".

[View full report](https://www.postman.com/ai/ai-ready-apis/company/bog)
[All organizations](https://www.postman.com/ai/ai-ready-apis/llms.txt)

## Summary

- Overall: 78/100 (B)
- Classification: partially-ready

## Category Scores

- API Design: 92/100 (A+)
- Developer Experience: 67/100 (C)
- Agent Discovery: 86/100 (A)
- Agent Understanding: 79/100 (B)
- Agent Usability: 68/100 (C)

## Check Results

### API Design

- [pass] Machine-readable, versioned contract — Uses OpenAPI 3.0.1 (3.0.x; 3.1 adds JSON Schema 2020-12 alignment but is not required for full credit), a current version that agent tooling reads natively. Investigated: spec 100%, docs 100%.
- [pass] Auth declared & discoverable — Authentication is required across the API (declared globally or on every operation), so an agent knows credentials are needed. Investigated: spec 100%, docs 100%.
- [warn] Schema coverage & depth — Operations take a high 12.4 parameters each on average; the request body of POST /v1/{payment-service}/{payment-product}, POST /v1/{payment-service}/{payment-product}/{paymentId}/authorisations, PUT /v1/{payment-service}/{payment-product}/{paymentId}/authorisations/{authorisationId} (+5 more) has a structured shape (more than 5 top-level fields, or a nested object / array-of-objects field), making it hard for an agent to build a valid request. Investigated: spec 63%, sdk 0%.
- [pass] Security & governance hygiene — No credential-shaped strings detected in spec. Investigated: spec 100%, sdk 83%, wellknown 0%.
- [pass] Example coverage — Only 28% of parameters and responses (252 of 892) include example values, so an agent has little grounding in real payload shapes. Investigated: spec 100%, docs 100%, sdk 0%.

### Developer Experience

- [pass] Quickstart present — Quickstart at https://api.bog.ge/docs/en/bonline/introduction-token includes a runnable first-call code sample. Investigated: docs 100%.
- [pass] Code samples in docs — Code samples appear on 4 of 20 sampled docs pages across 2 language(s), but broader multi-language coverage is missing. Investigated: docs 100%.
- [pass] Description completeness — Only 85% of operations and parameters have substantive descriptions (31 of 40 ops, 460 of 496 params; target 90%+). Investigated: spec 100%.
- [fail] Self-service developer portal — No self-service signup detected — no signup link on the homepage or docs, and no conventional signup path (/signup, /sign-up, /register, /get-started, /console/signup, /dashboard/signup, /try, /try-free, /free, /free-trial, /start, /start-free, /join, /create-account, /account/signup, /auth/signup, /users/sign_up) resolved — so an agent can't onboard on its own. Investigated: docs 0%.
- [fail] Changelog published — No changelog link or mention appears in the spec, so an agent can't tell what changed before something breaks. Investigated: spec 0%, docs 0%.

### Agent Discovery

- [pass] Registry & SDK presence — Indexed on Context7 (websites/api_bog_ge_en, 1534 snippets). Investigated: docs 100%, sdk 88%, cli 0%.
- [warn] llms.txt present, valid & comprehensive — No llms.txt directive found in HTML of any of 49 sampled pages; 1 failed to fetch. Investigated: docs 80%.
- [warn] Docs reachable, not hard auth-gated — Server ignores Accept: text/markdown header (0/49 sampled pages return markdown). Investigated: docs 75%.
- [warn] Crawlable / AEO — Sitemap has 0 entries but no lastmod values, so crawlers can't tell what changed recently. Investigated: wellknown 75%.

### Agent Understanding

- [pass] Machine-readable errors (RFC 9457) — Documents 11 distinct 4xx/5xx error response codes, so an agent can branch on specific failures instead of guessing. Investigated: docs 100%, spec 75%.
- [warn] Operation purpose clarity — Only 63% of operations (25 of 40) have both a clear summary and a descriptive name (target 90%+), so an agent may pick the wrong endpoint for the rest. Investigated: spec 90%.
- [warn] Agent-navigable, token-efficient docs — 16 of 48 pages have substantive content differences between markdown and HTML (avg 11% missing); 1 failed to fetch. Investigated: docs 88%.
- [warn] Agent instructions file (AGENTS.md) — No agents.md or skill.md context file found (nice-to-have for agent operation). Investigated: sdk 50%, wellknown 0%.
- [warn] Description consistency across surfaces — Mean pairwise description similarity across 3 surfaces (spec, docs, sdk) is 1% (threshold 35% for full credit).
- [fail] Docs structured data — No JSON-LD or OpenGraph/meta tags found across 3 assessed pages (3 JS-rendered), so answer engines have nothing to cite. Investigated: docs 0%.

### Agent Usability

- [pass] Idempotency documented — idempotency is documented on the docs site at https://api.bog.ge/docs/en/link-payment/glossary, even though it isn't declared in the API spec. Investigated: spec 100%, docs 100%.
- [pass] Sandbox separation — sandbox is documented on the docs site at https://api.bog.ge/docs/en/sandbox/payments/introduction, even though it isn't declared in the API spec. Investigated: spec 100%, docs 100%.
- [fail] Rate-limit signaling — No rate-limit response headers are documented, so an agent can't tell when it is approaching a limit and will get throttled. Investigated: spec 0%, docs 0%.
- [fail] Runnable collection with test scripts — No README found. Investigated: sdk 0%, platform 0%.
- [skip] Pagination documented & consistent — No surface produced evidence for this capability in this run.

## Executive Summary

Bog's API program shows strong fundamentals in design, discovery, and documentation structure — partners and agents can find and parse your APIs today. The two areas most likely to stall partners are developer experience and agent usability: there is no changelog to signal breaking changes before they cause incidents, no runnable collection that lets a partner or AI agent validate a workflow end-to-end, and no self-service signup path to convert interested developers without a sales conversation. Prioritizing these gaps will compress the time from discovery to a working integration and reduce churn caused by silent contract changes.