API

Routy is API-first. The dashboard you log into isn't a special privileged interface that exposes things the API doesn't — it's a UI built on top of the same REST API we expose to you. That sounds like a technicality and it changes everything about what you can do with the platform.

In an industry where most tracking platforms either ship no API, ship a partial read-only API, or charge enterprise-tier rates for API access, Routy treats programmatic access as table stakes. Every action you can take in the UI is a documented API call you can make from your own code. Every report you can build is queryable. Every link you can create, every postback you can configure, every webhook you can wire up, every export you can run — all of it is accessible from a code path you control.

For the technical buyer, the developer at an agency, the data team at a larger operation, or anyone seriously considering building Routy into a wider stack rather than just using it as a standalone dashboard, this is usually the deciding feature.

The API surface covers every domain in the platform:

• Full read and write access across affiliate accounts, brand and offer links, click data, conversion data, traffic sources, networks, the program catalog, reports, webhooks, exports, and the rest of the platform. There are no "read-only in the API but writable in the UI" exceptions and no "this requires support to configure" gaps.
• The same API the Routy dashboard uses. This matters more than it sounds: the API isn't a parallel surface we maintain separately and might forget to update when a UI feature ships. If a capability is in the UI, it's in the API the day the UI ships it, because the UI is using the API to do its work.
• OpenAPI specification maintained alongside the platform. The spec is the contract — generate an SDK in TypeScript, Python, Go, Ruby, or whatever language your stack runs on, and the generated client is automatically in sync with the actual endpoints.
• Token-based authentication with granular permission scoping. You issue tokens per integration — one for the script that runs your nightly batch updates, one for the internal tool your VA uses, one for the dashboard you've embedded somewhere — and each token has only the permissions that specific integration needs. Tokens are revocable individually; rotating a compromised token doesn't break the rest of your integrations.
• Versioned and stable so the integration you build today doesn't break the next time we ship a new feature. Breaking changes follow a deprecation cycle with advance notice; non-breaking additions ship without disrupting existing clients.
• Rate limits documented and predictable so you can plan batch jobs without guessing. The limits scale with plan tier and burst handling is designed to be forgiving for legitimate workloads (data exports, periodic syncs) rather than aggressive enough to penalise normal use.
• Webhook delivery for event-driven integrations where polling the API isn't the right pattern. Conversions, link changes, payouts — anything that fires an event in Routy can fire an outbound webhook to your endpoint.

The combination of these is what makes the API genuinely useful rather than a token "we have an API" box-tick. Most affiliate tracking platforms ship something they call an API but the coverage is partial, the documentation is stale, or the limits are aggressive enough that real workloads are impractical.

You generate an API token from the settings section of your Routy dashboard. Each token can be named (so you remember what it's for), scoped to a permission set (read-only, write to specific domains, full account access), and revoked individually at any time.

You point your code at the documented endpoints. The full OpenAPI spec is downloadable from the developer documentation and importable into any OpenAPI-compatible toolchain — Swagger UI for browsing, openapi-generator for SDK generation, Postman for ad-hoc testing.

Authentication is a bearer token in the standard Authorization header. Responses are JSON. Pagination, filtering, and sorting follow consistent conventions across endpoints, so the experience of working with one resource type carries over to the others.

A few practical specifics worth knowing:

• Rate limits are per-token rather than per-account. Generous burst allowances mean that legitimate batch operations rarely hit them; if your workload needs higher limits, the request goes through your account manager and is handled on a per-case basis.
• Webhook signatures are HMAC-signed with your account secret, so your receiving endpoint can verify that an incoming webhook actually came from Routy and wasn't spoofed.
• API versioning uses URL-based versions (e.g. /v1/affiliates). New versions are introduced when breaking changes are needed; the previous version stays available for the deprecation window before being sunset.
• OAuth flow is available for integrations where end users grant access to their own Routy accounts (rather than your developer team holding the token directly). Useful for building third-party tools that connect to Routy on a user's behalf.

The API is the feature most operations don't think they need until they suddenly do. The pattern goes something like this: a team uses Routy through the dashboard for the first few months, builds up a stable operation, then runs into the specific thing the dashboard doesn't do quite the way they want. It might be a bulk-update they want to script. A custom dashboard they want to embed in their own internal tool. A reporting integration into the BI tool their leadership team lives in. A workflow they want to automate that touches Routy on one end and something else on the other.

At that moment, the difference between a platform with a real API and one without one becomes everything. With a real API, the thing they want is buildable in a few hours. Without one, they're filing a feature request, waiting for the platform to ship it, or working around it manually for the foreseeable future.

For the buyers who already know they'll need this — agencies running multiple client accounts, larger operations with internal data teams, anyone planning to embed Routy into a broader stack rather than treat it as a standalone tool — the API is usually one of the first things they evaluate. The "obvious to them, deciding factor for some" framing fits exactly here. To an experienced platform buyer, "we have a full REST API" sounds basic. But the platforms that actually deliver on that promise (full coverage, the same API the UI uses, versioned, stable, documented OpenAPI spec) are uncommon enough that having one is a genuine differentiator.

For solo operators and smaller teams not currently planning to build automations, the API still pays off later. The data you accumulate in Routy stays accessible programmatically forever, which means future-you (or future-you's data analyst) can always extract what they need without having to migrate platforms first.