Offer codes, free trials and entitlements

Three related but separate things sit behind AnythinkPay's /me calls: offers (referral programmes and promo codes), the app free trial (access before any subscription) and entitlements (the one check your app makes to gate a feature). This page covers all three, plus user balances if your project uses account credit. For the wider model, see How payments and subscriptions work.

Offers and codes

An offer is a referral programme or a promotion: a set of codes, an optional eligibility rule and a reward. AnythinkPay creates a default referral offer the first time someone asks for their personal code, so a project with no offers configured still works.

anythink fetch /integrations/anythinkpay/offers
anythink fetch /integrations/anythinkpay/offers/{id}/codes
anythink fetch /integrations/anythinkpay/offers/redemptions

anythink fetch /integrations/anythinkpay/offers --method POST --body \
  '{"kind":"referral","name":"Referral programme","status":"active","redeemer_reward_json":"{\"type\":\"trial_extension\",\"days\":7}"}'

List redemptions for the referral offer on this project.

A subscriber's own codes and referrals

Your app calls these as the signed-in user. They need the subscriber-level anythink_subscription_plans:read permission rather than the administrator-level anythink_offers:read, so a mobile app's own token can call them without administrator rights:

GET  /org/{project_id}/integrations/anythinkpay/offers/me/code
GET  /org/{project_id}/integrations/anythinkpay/offers/me/codes
POST /org/{project_id}/integrations/anythinkpay/offers/me/redeem/{slug}
GET  /org/{project_id}/integrations/anythinkpay/offers/me/referrals

• me/code returns this user's personal code for the default referral programme, creating it the first time.
• me/codes returns their code for every active referral programme.
• me/referrals returns their personal_code_slug, redemption_count, rewards_applied, rewards_pending and a recent list. It includes tier_progress when the programme gives tiered rewards.
• me/redeem/{slug} redeems a code as the user. Add ?subscription_id= when the redemption should apply to a specific subscription.

A rejected code still returns 200, so check success:

{
  "success": false,
  "rejection_reason": "Already redeemed",
  "redemption_id": null,
  "redeemer_reward_summary": null,
  "referrer_reward_queued": false
}

rejection_reason says why: the code doesn't exist, the offer isn't active yet, has expired or has reached its cap, the user has already redeemed it, it's their own code, or they don't meet the eligibility rule. Eligibility is worked out for you from the redeeming user's active subscriptions.

Free trials

There are two separate kinds of trial:

• A plan's own trial (Trial period (days) on the plan) delays a subscriber's first charge after they check out. See Create plans and manage subscriptions.
• The app free trial gives one window of free access to a user who has never subscribed. It doesn't depend on a plan or a payment provider.

Entitlements

One endpoint answers "can this user use the paid feature right now?" across Stripe, Apple and the app free trial:

GET /org/{project_id}/integrations/anythinkpay/subscriptions/me/entitlement

For a Stripe subscriber in the middle of their plan's trial:

{
  "has_access": true,
  "subscription_id": "4c2f9a1e-0000-0000-0000-000000000000",
  "provider": "stripe",
  "product_id": "Pro monthly",
  "status": "trialing",
  "expires_at": "2026-10-11T17:49:06Z",
  "auto_cancel_at": null,
  "cancelled_at": null,
  "is_trial": false,
  "trial_ends_at": null,
  "trial_days_remaining": null,
  "trial_length_days": 7,
  "trial_base_days": 0,
  "trial_bonus_days": 0,
  "pending_product_id": null,
  "pending_at": null
}

For a user on the app free trial, with a 7-day trial and a 14-day promo bonus, the subscription fields are empty and the trial fields are filled:

{
  "has_access": true,
  "subscription_id": null,
  "provider": null,
  "product_id": null,
  "status": "trialing",
  "expires_at": "2026-10-25T09:00:00Z",
  "auto_cancel_at": null,
  "cancelled_at": null,
  "is_trial": true,
  "trial_ends_at": "2026-10-25T09:00:00Z",
  "trial_days_remaining": 21,
  "trial_length_days": 21,
  "trial_base_days": 7,
  "trial_bonus_days": 14,
  "pending_product_id": null,
  "pending_at": null
}

• A user who has never subscribed is resolved from the app free trial. With it off, they get has_access false and status null. While it runs, has_access and is_trial are true and status is trialing. After it ends, has_access is false and status is trial_expired, which is your cue to show a paywall.
• If a user has several subscriptions, the call returns the strongest one: one that grants access first, then the one that runs longest.
• pending_product_id and pending_at let you show "switching to X on your next renewal".
• A user who subscribes stops using the trial and is read from their subscription instead.

The call needs anythink_subscription_plans:read, so a subscriber's own token works and your client needs no administrator key. Payments recipes shows how to grant the permission and gate a feature with it. Use the signed-in user's token, because an API key has no subscriber behind it.

User balances

If your project uses account credit or points, a subscriber reads their own balance the same way, with the subscriber-level permission:

GET /org/{project_id}/integrations/anythinkpay/balances/me

[
  { "unit_type": "points", "currency": null, "total": 100 },
  { "unit_type": "credit", "currency": "gbp", "total": 500 }
]

Points are whole numbers. Credit is in minor units, so 500 is £5.00.

Administrators can also read any user's balance and history, and adjust it by hand. Those calls need anythink_balances:read and anythink_balances:update:

GET  .../balances/users/{user_id}
GET  .../balances/users/{user_id}/history
POST .../balances/users/{user_id}/adjust
{ "unit_type": "credit", "currency": "gbp", "delta": 500, "reason": "Goodwill credit" }

Permissions

Next steps