API Server & Routing

Acceso’s Core API runs behind a centralized, stateless API server. It handles all client-facing requests. It enforces platform-wide guarantees. It forwards domain work to internal services.

The API server is protocol-agnostic. It does not embed Solana, DeFi, or market logic. It focuses on orchestration, validation, routing, and response consistency.

Responsibilities

The API server owns:

• A single public entry surface for REST-style traffic.

• Deterministic request preprocessing and early rejection.

• Versioned routing to exactly one internal domain owner.

• Uniform response envelopes and error normalization.

• Request correlation and baseline telemetry emission.

It does not own:

• Domain parsing rules and transformations.

• Stateful sessions.

• Long-lived streams (handled by dedicated services when present).

Deterministic middleware pipeline

Requests traverse the same ordered pipeline. The goal is fast failure. Invalid or abusive traffic should not reach domain services.

1

1) Edge safety checks

• Security headers.

• CORS validation when enabled.

• Method and content-type checks.

• Body size limits and timeout guards.

2

2) Parse and sanitize

• JSON parsing and strict type checks.

• Query normalization (pagination, filters, sorting).

• Unknown field handling (reject or drop, per endpoint contract).

3

3) Authenticate and gate

• API key validation.

• Policy evaluation (allowed domains, endpoint categories, feature flags).

• Abuse protection and rate limit enforcement.

4

4) Route and forward

• Version-aware route selection.

• Request shaping for internal calls (headers, context, deadlines).

• Exactly-one-service dispatch.

5

5) Wrap and return

• Response envelope normalization.

• Error mapping to stable codes.

• Compression when negotiated.

• Correlation identifiers in response metadata.

The pipeline is intentionally boring. Predictability makes rollouts safer and incidents faster to debug.

Routing strategy

All endpoints are versioned and namespaced. Routing is derived from the request path and version. The mapping is explicit. It stays stable across deployments.

Typical route shapes:

• /v1/solana/*

• /v1/defi/*

• /v1/polymarket/*

• /v1/zk/*

Versioning rules

• The version prefix is required (/v1, /v2, …).

• Breaking changes ship behind a new version prefix.

• Old versions remain routable until formally deprecated.

Domain ownership

Each versioned domain maps to one internal service. That service owns:

• Data fetching and caching strategy.

• Domain validation and transformation.

• Contract-level semantics and invariants.

The API server stays thin. It does not “fix up” domain mistakes.

Stateless design

The API server stores no session state. All context is derived from request inputs and internal service responses. This enables horizontal scaling. It also removes sticky-session coupling.

Practical implications:

• You can run multiple API server replicas behind a load balancer.

• Deployments can be rolled out gradually with low risk.

• Failover is simple. Any replica can handle the next request.

Operational defaults (client-relevant)

These defaults are enforced at the infrastructure layer. They keep behavior consistent across domains.

• Requests have server-side deadlines. Long work should be async.

• Retries are safer when errors are structured and idempotency is used.

• Large payloads are rejected early to protect downstream services.

Example: request routed by version + domain

GET /v1/solana/tx/5wB... HTTP/1.1
Host: <YOUR_ACCESO_API_HOST>
Accept: application/json
Authorization: Bearer <YOUR_API_KEY>

The server selects:

• Version: v1

• Domain: solana

• Owner: internal Solana service