The Siren REST API Is Complete

For a long time, Siren had an API. It didn’t have an API surface.

That distinction matters. You could read a handful of resources, and a handful of endpoints existed to make the WordPress admin work, but if you wanted to manage a program end to end from outside Siren, you hit a wall fast. You could list collaborators, but not create them cleanly. You could read conversions, but couldn’t post one from another system. The API was real. It just wasn’t complete.

3.0 closes that gap. The core program model has a REST surface end to end, and the shape is consistent enough that once you understand one resource, you understand all of them.

Why now? Because the number of Siren customers wanting to run a program outside the default WordPress admin has been growing for a year, and “we have an API” stopped being a useful answer. The design has to match the claim.

Complete means every resource

Every resource in Siren’s data model has a REST interface. The split between what’s mutable and what isn’t follows the shape of the data, not a tier gate: the resources an operator authors get full CRUD, and the resources the system authors as side effects get read-only access, because rewriting a ledger makes the audit trail lie. The endpoint reference is the authoritative list.

The point of a complete surface is what you can build on top of it. Siren is a WordPress plugin and will be for as long as WordPress is the right place for it, but the programs don’t have to live inside a WordPress experience. A team running a donation-per-purchase program, a creator royalty split, or a sales-team bonus pool can run the Siren admin on a subdomain, point their marketing site at a static frontend, and push conversions into Siren from whatever stack their commerce actually runs on. The default admin and Collaborator Portal are opinionated for standard affiliate programs. For anything else, the API is how you build the interface your program actually has.

Developers evaluating whether the API holds up should start at the endpoint reference. It covers every resource, every field, and the pagination and field-selection pattern every list endpoint shares. Auth runs on the standard WordPress JWT model. Idempotency behavior for ledger writes and the event-delivery story for external systems live in the same reference, because those are the questions that decide whether an API is usable, not whether it exists. If you’re looking for an OpenAPI spec or a typed SDK, the honest answer is that the endpoint reference is the contract today, and the tooling on top of it is a roadmap item, not a shipped thing. That’s where to go before installing.

It ships on every tier, Lite included

The REST API is part of every Siren tier, not gated to paid plans. The free tier, Siren Lite, includes full API access. This is deliberate.

If you’re a builder evaluating whether Siren is the right platform to run an incentive program on, the API is part of what you’re evaluating. Gating it behind a paid plan would force you to buy before you could answer the question. The whole point of Lite is to let you prove the model on real data, on a real site, before you commit.

Headless WordPress, via the opportunity ID header

Every visitor who lands on a Siren-tracked site is assigned an opportunity ID, and that ID is the anchor Siren uses to attribute a later conversion back to the right collaborator. On a traditional WordPress-rendered site, the opportunity ID lives in a cookie and moves through requests automatically. On a headless site, where the frontend is a static build and WordPress lives on a subdomain doing nothing visible, the opportunity ID has to be handed around explicitly. Siren 3.0 formalized that pattern.

The flow is short. A visitor lands on your static frontend with a referral URL. Your frontend calls the Siren tracking endpoint, Siren returns an opportunity ID, and you hold onto it client-side. When the visitor later converts, whether that’s completing a checkout, submitting a form, or any other event your program attributes on, you send the opportunity ID back in a header called X-Siren-OID. Siren uses it to credit the right collaborator.

The Siren marketing site you’re reading right now is one example of this pattern. It’s an Astro-generated static site served from a CDN, with the Siren plugin running on a WordPress install we control on a separate subdomain. Every page initializes tracking, every conversion carries the opportunity ID back through that header, and attribution works the way it does on a traditional WordPress site. Nothing in that stack requires a paid tier. Headless WordPress with Siren tracking runs on Lite, Essentials, Plus, and Pro the same way.

The API makes the infrastructure claim real

The 3.0 relaunch post argued that Siren is infrastructure, not an affiliate plugin. The API is the load-bearing version of that claim. Infrastructure products are defined by how they behave when you don’t use them the way the vendor imagined. A good one exposes its operations cleanly enough that you can build something the vendor never thought of.

The full surface is at the endpoint reference. If your program is typical, the admin and the portal will handle it cleanly. If it isn’t, you have a surface you can build on.