generated: '2026-08-11' method: searched source: >- https://github.com/pqchase/rugspull/releases + https://rugspull.com/openapi.json (info.version) + https://github.com/pqchase/rugspull/blob/main/docs/INTEGRATION.md + https://rugspull.com/.well-known/api-onboarding versioning: scheme: semver-document-version current: 0.4.0 in_path: false in_header: false media_type_versioning: false note: >- info.version 0.4.0 matches the monorepo package version and the v0.4.0-evidence.1 GitHub prerelease tag, so the spec version and the software version move together. The wire contract carries no version at all: no /v1 path segment, no version header, no versioned media type. A consumer cannot pin, and a breaking change would arrive unannounced. The API is also pre-1.0 by its own numbering, which the provider does not contradict anywhere. changelog: url: https://github.com/pqchase/rugspull/releases format: github-releases dated: true see: changelog/rugspull-read-api-changelog.yml status_page: documented: false url: null health_endpoint: https://rugspull.com/api/health health_endpoint_declared_in: https://rugspull.com/.well-known/api-catalog note: >- There is no status page. The RFC 9727 API Catalog declares a `status` relation, but it points at /api/health — a liveness probe returning {"ok":true,"service": "rugspull-api"}. The provider is careful about this: the OpenAPI describes that response as "Service process is responding; this is not chain, indexer, RPC, or financial-state health." A machine liveness endpoint is not an operational status surface, so no StatusPage pointer is emitted. The nearest thing to an operational signal is getIndexerStatus, which exposes latestBlock, staleBlockThreshold and a warnings[] array. deprecation: policy_documented: false sunset_header: false deprecation_header: false rfc8594: false deprecated_operations: [] note: >- No deprecation or sunset policy is published, no RFC 8594 Sunset/Deprecation header was observed on any live response, and no operation in the OpenAPI carries deprecated: true. At 0.4.0 with no version in the URL, there is no mechanism by which a retirement could be signalled to an automated consumer. sla: documented: false uptime_target: null support_response_time: null note: >- The provider states the absence explicitly and repeatedly rather than leaving it implied: "No numeric rate-limit or uptime SLA is offered" (OpenAPI description), "There is no public numeric rate-limit or uptime SLA" (INTEGRATION.md), "numericRateLimitSla: false" (integration.json), "no bounty or response-time SLA is offered" (security.txt). This is an honest, machine-readable zero. stability: stage: pre-launch gate: >- The provider records organized new mainnet activity as NO-GO while published Stage 0 activation gates are unresolved (https://rugspull.com/stage-0-review), and states an independent audit has not been completed. The read API is live and answering, but the protocol it indexes is not in general operation — the discovery cache returned zero rugs on every probe. evidence: - {url: 'https://rugspull.com/api/rugs?limit=5', status: 200, body: '{"rugs":[],"nextCursor":0}'} - {url: 'https://rugspull.com/api/indexer/status', status: 200, note: 'latestBlock 115378684, warnings []'} data_lifecycle: cache_rebuildable: true retention_policy: not documented note: >- The D1 discovery cache is explicitly rebuildable from chain state, so data loss in the API tier is recoverable by design and carries no durability commitment. Event history through listRugEvents is capped at 100 rows with no cursor, which is a permanent ceiling rather than a retention window. gaps: - No status page or incident history. - No deprecation/sunset policy and no version in the request path or headers. - No SLA of any kind, stated as a deliberate position rather than an omission. cross_links: changelog: changelog/rugspull-read-api-changelog.yml conventions: conventions/rugspull-read-api-conventions.yml