SWYPE Developer Docs

SWYPE is best understood as a layered platform. The top layer is the product surface: the website, swap screen, Swype Me request flows, creator tipping, embeds, widgets, partner portal, and partner API. Beneath that sits the application API layer, which validates requests, enforces access rules, creates route records, and returns tracking state to the client.

Under the API layer sits the routing and orchestration layer. This is where SWYPE decides whether a flow should use a direct public route, a protected private route, or a hosted fiat-connected route. The orchestration layer records state, stores tracking identifiers, and keeps the user-facing experience consistent even when execution happens through external providers and supported networks.

The persistence and trust layer stores user profiles, payout preferences, request records, swap records, sessions, rate-limit entries, and operational metadata. Sensitive fields are protected server-side. The final execution layer is external: supported routing providers, hosted checkout providers, and blockchain networks handle execution and settlement while SWYPE remains non-custodial.

A key architectural point is that SWYPE is not built as several disconnected products. The first-party website, partner API, widget, iframe, and private routing surfaces all reuse the same underlying routing and tracking model. When route support or execution behavior changes inside SWYPE, those improvements can propagate across multiple surfaces instead of being rebuilt several times.

This is one of the clearest reasons to describe SWYPE as routing infrastructure and payments software rather than only as a single swap page. It supports different entry points, but those entry points feed into a shared orchestration model.

The public architecture description should explain system responsibilities and boundaries, not proprietary route heuristics. It is accurate to say that SWYPE validates requests, resolves payout intent, creates non-custodial route instructions, tracks state transitions, and reconciles external execution state back into SWYPE status views.

It is not necessary to publish internal provider-ranking rules, exact fallback thresholds, release timing logic, provider sequencing rules, or operational traces. That detail belongs in internal operations, not public documentation.