Is the API read-only?

Yes. The REST keys are read-only: you can list your apps and reviews, but you cannot mutate your account through the API. Publishing and configuration stay inside the product's role-gated actions. The API exists to get your data out into reporting, warehousing, and your own tooling.

What are the endpoints and how do I paginate?

There are two: GET /api/v1/apps and GET /api/v1/reviews, where each review embeds its reply inline. Both use keyset (cursor) pagination: a page returns a next_cursor that you pass back to fetch the next page, looping until next_cursor comes back empty. Keyset pagination is stable under inserts, so new reviews will not shift your pages.

How do I authenticate?

With a bearer token in the Authorization header. Mint the key in Settings > Developers (an admin action); the secret is shown once at creation, so copy it immediately into your secret store. Each key has its own rate limit and can be revoked independently.

Which webhook events exist?

review.created, draft.created, reply.published, digest.weekly, and anomaly.detected, plus a test event you can trigger to confirm your endpoint and signature check work. Each is a single JSON POST whose type tells your handler what to expect.

How do I verify a webhook signature?

Each POST carries an x-ra-signature header of the form t= ,v1= . Recompute the HMAC over the string . using your endpoint's own signing secret, then compare it to the v1 value with a constant-time comparison, not plain equality. Reject mismatches and reject timestamps too far from now to blunt replay. Always verify against the raw body bytes, not a re-serialized object.

Which plan includes the API and webhooks?

The Pro tier and up. Keys are minted by an admin, shown once, and rate-limited per key; webhooks carry a per-endpoint secret you use to verify each signed delivery.

All posts

GuideJul 8, 2026 · 10 min

The Reply Argus API: pull reviews and receive signed webhook events

Mint a read-only key to pull your apps and reviews over REST, or subscribe a webhook to get review, draft, publish, digest, and anomaly events as HMAC-signed JSON POSTs you can verify.

The Argus Team

Reply Argus

If you want your review data in your own systems, Reply Argus gives you two complementary paths: pull and push. Pull is a read-only REST API you query on your schedule to list your apps and reviews. Push is a webhook you subscribe once, after which Reply Argus POSTs you signed JSON the moment something happens: a new review lands, a draft is generated, a reply is published, the weekly digest is ready, or an anomaly is detected. Most integrations use both: the webhook wakes you up, the REST API lets you backfill or reconcile.

This guide covers the public surface of both: how to mint a key, the two REST endpoints and how their cursor pagination works, the webhook event types, and how to verify a webhook signature so you can trust that a POST really came from Reply Argus. Everything below is the documented, stable interface.

How do I get a key?

Mint a read-only key in Settings > Developers. Key creation is an admin action, and the secret is shown once at creation time, so copy it into your secret store immediately; it is not retrievable afterward. Authenticate every request with a bearer token in the Authorization header. Each key carries its own rate limit, so a busy integration cannot exhaust another key's budget, and you can revoke a key without disturbing the rest.

The key is read-only by design. The API is for getting your data out (reporting, warehousing, dashboards, your own tooling), not for mutating your account. Publishing and configuration stay inside the product and its role-gated actions.

What can I pull, and how does pagination work?

There are two endpoints. GET /api/v1/apps lists the apps in your org. GET /api/v1/reviews lists reviews, and each review embeds its reply inline, so you do not need a second round-trip to see how a review was answered. Both endpoints use keyset (cursor) pagination: a page returns a next_cursor, and you pass it back to fetch the following page. Keyset pagination is stable under inserts, so new reviews arriving mid-pagination will not shift rows and cause you to skip or double-read. When next_cursor comes back empty or absent, you have reached the end.

bash

# List your apps
curl -s https://www.replyargus.com/api/v1/apps \
  -H "Authorization: Bearer $RA_API_KEY"

# List reviews, one page at a time (each review embeds its reply)
curl -s "https://www.replyargus.com/api/v1/reviews?limit=100" \
  -H "Authorization: Bearer $RA_API_KEY"

# Follow the cursor to the next page until next_cursor is empty
curl -s "https://www.replyargus.com/api/v1/reviews?limit=100&cursor=$NEXT_CURSOR" \
  -H "Authorization: Bearer $RA_API_KEY"

Bearer-token auth, keyset pagination. Loop on next_cursor until it comes back empty.

What events can I subscribe to?

Subscribe a webhook endpoint and Reply Argus POSTs it JSON whenever one of these events occurs: review.created (a new review synced), draft.created (a reply draft was generated), reply.published (a reply went live on the store), digest.weekly (the weekly digest is ready), and anomaly.detected (a rating-drop or review-flood alert fired). There is also a test event you can send on demand to confirm your endpoint is wired up and your signature check works before real traffic arrives.

Each delivery is a single JSON POST. The event type tells your handler what shape to expect, so a typical consumer switches on the type and routes review.created into your CRM, reply.published into an audit log, anomaly.detected into your incident channel, and so on.

How do I verify a webhook is really from Reply Argus?

Every webhook carries an x-ra-signature header of the form t=<ts>,v1=<hmac>. The hmac is an HMAC computed over the string <ts>.<body>, where ts is the timestamp from the header and body is the exact raw request body. Each endpoint you register has its own signing secret. To verify, recompute the HMAC with your endpoint's secret over the same <ts>.<body> string and compare it to the v1 value using a constant-time comparison, never a plain string equality (which can leak information through timing). Reject anything that does not match, and reject a timestamp too far from now to blunt replay attempts.

javascript

// Verify an x-ra-signature: t=<ts>,v1=<hmac> header (pseudocode).
// `rawBody` MUST be the exact bytes received, not a re-serialized object.
function verify(rawBody, header, secret) {
  const parts = Object.fromEntries(
    header.split(",").map((kv) => kv.split("="))
  );
  const ts = parts.t;
  const sent = parts.v1;

  // Reject stale deliveries to blunt replay (e.g. 5-minute window).
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;

  const expected = hmacSha256(secret, `${ts}.${rawBody}`); // hex
  return constantTimeEqual(expected, sent); // NOT expected === sent
}

Recompute the HMAC over `<ts>.<body>` with the endpoint's secret and compare in constant time.

Sign the raw bytes

Verify against the raw request body, not a parsed-and-re-serialized object. Frameworks that auto-parse JSON will re-order keys and change whitespace, and the recomputed HMAC will never match. Capture the exact received bytes before any JSON parsing and sign those. This is the single most common reason a correct-looking verification fails.

1
Mint a key
In Settings > Developers (an admin action), create a read-only API key and copy the secret immediately; it is shown once. Store it in your secret manager.
2
Pull to backfill
Call GET /api/v1/apps and GET /api/v1/reviews with the bearer key, following next_cursor until it is empty, to load your existing data into your warehouse or dashboard.
3
Subscribe a webhook
Register an endpoint URL and store its per-endpoint signing secret. Send yourself the test event to confirm the round-trip and your signature check.
4
Verify, then act
On each POST, verify the x-ra-signature over `<ts>.<body>` with a constant-time compare and a freshness check, then switch on the event type and route it into your systems.

Who can use it?

The API and webhooks are available on the Pro tier and up. Keys are minted by an admin in Settings > Developers, shown once, and rate-limited per key. The REST surface is read-only; the two endpoints are GET /api/v1/apps and GET /api/v1/reviews, both keyset-paginated. Webhooks deliver the review.created, draft.created, reply.published, digest.weekly, anomaly.detected, and test events, each an HMAC-signed JSON POST you verify with your endpoint's secret.

Frequently asked

Is the API read-only?: Yes. The REST keys are read-only: you can list your apps and reviews, but you cannot mutate your account through the API. Publishing and configuration stay inside the product's role-gated actions. The API exists to get your data out into reporting, warehousing, and your own tooling.
What are the endpoints and how do I paginate?: There are two: GET /api/v1/apps and GET /api/v1/reviews, where each review embeds its reply inline. Both use keyset (cursor) pagination: a page returns a next_cursor that you pass back to fetch the next page, looping until next_cursor comes back empty. Keyset pagination is stable under inserts, so new reviews will not shift your pages.
How do I authenticate?: With a bearer token in the Authorization header. Mint the key in Settings > Developers (an admin action); the secret is shown once at creation, so copy it immediately into your secret store. Each key has its own rate limit and can be revoked independently.
Which webhook events exist?: review.created, draft.created, reply.published, digest.weekly, and anomaly.detected, plus a test event you can trigger to confirm your endpoint and signature check work. Each is a single JSON POST whose type tells your handler what to expect.
How do I verify a webhook signature?: Each POST carries an x-ra-signature header of the form t=<ts>,v1=<hmac>. Recompute the HMAC over the string <ts>.<body> using your endpoint's own signing secret, then compare it to the v1 value with a constant-time comparison, not plain equality. Reject mismatches and reject timestamps too far from now to blunt replay. Always verify against the raw body bytes, not a re-serialized object.
Which plan includes the API and webhooks?: The Pro tier and up. Keys are minted by an admin, shown once, and rate-limited per key; webhooks carry a per-endpoint secret you use to verify each signed delivery.

Try it

Let Argus draft your next reply.

Watch it answer a real review in your voice. 10-day trial, no card to begin.

Start free

See the features or pricing.

Keep reading

Guide8 min

App Store Reviews Not Showing? The Full Fix List for Apple and Google Play

App Store or Google Play reviews not showing? Here's every real cause — moderation delay, wrong country storefront, filtering, rating lag, cache — and the fix.

Guide9 min

Are App Store Reviews Fake? How to Spot Them and What to Do

Yes, some App Store and Google Play reviews are fake — but fewer survive than you think. How to spot them, and what to do when they hit your app.