Radar

PASS consensus from 3 PASS.

The page names the Test Publishable key, Authorization header, endpoint, required fields, and curl syntax, despite its live-key sample. One page carries the whole first-call path: key location, Authorization header, Publishable vs Secret levels with the explicit instruction to use the Test Publishable key for non-production, then POST https://api.radar.io/v1/track with deviceId, latitude, longitude, and accuracy marked required and a copy-pasteable curl sample. Authentication (API keys from Settings, Authorization header) and the Track endpoint are fully documented with a curl example; path is unambiguous.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

Track's hourly and daily values are unstated; fixed plan quotas are absent, and radar.com/pricing.md returned Not Found. Geocoding (100/s forward, reverse, IP), Search (100/s autocomplete, 50/s geofences and places, 25/s address validation, 10/s users), and Routing (50/s distance, 20/s directions, 10/s matrix, route match, optimize) each carry an exact default rate limit in the API reference and no other page contradicts them, but Track is documented as "1 request per second per device" in the API reference while the testing page says hour and day limits also exist and never gives those numbers, and no plan quota figures appear anywhere in the docs. All per-endpoint rate limits are documented, but plan-level quotas (monthly MTU or request caps by pricing tier) are absent from the docs.

PARTIAL consensus from 2 PARTIAL, 1 FAIL.

The error list names three causes, but it gives no diagnostic signal or complete correction for each cause. The docs name three separate causes for one status code but define only the first: "no state change" and "selective throttling" each appear exactly once across all 58 indexed pages with no explanation, no Retry-After or rate-limit response header is documented anywhere, and the only recovery instruction on the site is the testing page's advice to collect locations less frequently and to reinstall the app to reset per-hour and per-day limits. The three causes of 429 are identified but no Retry-After header, backoff strategy, or correction workflow is documented.

PARTIAL consensus from 3 PARTIAL.

The page covers creation, POST delivery, and 2xx acknowledgement, but does not specify the signature digest encoding or comparison method. Creation, delivery shape, and acknowledgement are complete and unambiguous (dashboard Integrations page, Test or Live environment, Single or Multiple Events chunked in groups of 5, return any 2xx), but verification cannot be implemented without guessing because the digest encoding is never stated (hex or base64), no sample X-Radar-Signing-Id value or sample header block is shown, no verification code exists in any language, and the page does not say where the security token is displayed. Webhook creation, 2xx acknowledgement, and HMAC-SHA1 verification are described but the docs lack a concrete verification code example and the signing payload is ambiguously specified.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The Swift path works, but the Objective-C example waits for AuthorizedAlways before requesting Always authorization. The Swift path is complete and matches the API reference (pinned CocoaPods, SPM, and Carthage versions, Radar.initialize with prj_test_pk_, Info.plist usage strings, escalation from requestWhenInUseAuthorization to requestAlwaysAuthorization, Radar.trackOnce with a 13-value status enum), but the Objective-C snippet in the same Request permissions block escalates from the wrong state and never reaches Always authorization. Installation (CocoaPods/SPM/Carthage), initialization with publishable key, permission requests, and trackOnce() are fully documented with matching Swift and Objective-C examples.