My account

The end user's endpoints: their points, their benefits, their history and their tier in your program.

Endpoints for the end user, authenticated with the access token returned by verifying the code:

Authorization: Bearer {access}
X-Commerce-Id: {your-commerce-id}

Everything they return is scoped to the commerce in the X-Commerce-Id header: points, benefits, history and tier belong to that program and nothing else. The same user can be in several Loybox programs, and each one only sees its own.

The typical circuit

This is how a loyalty website is built with these endpoints:

The first render

GET /v1/me brings the points, the commerce's branding and the points about to expire, all at once. With a single call you paint the header and the balance.

GET /v1/me/benefits/available to show what they can redeem.

The purchase

POST /v1/me/benefits/exchange trades points for a benefit.

The codes

GET /v1/me/benefits to show them the codes they hold to present at the commerce.

When building the UI

Three things that save round trips:

  • Each of the user's benefit client_benefit_code is also the coupon code: in an online store it is what the user pastes at checkout.
  • Benefits carry benefit_type, which separates catalog ones (normal) from the special rewards (welcome, birthday, monthly_top, level), and color, the commerce's brand color.
  • How much the user is short for a benefit is the benefit's cost minus the points from GET /v1/me.

Buying and redeeming are not the same

BuyingRedeeming
What it doesTrades points for a benefitUses the benefit at the commerce
Who calls itThe user, from your websiteYour server, at the sale
EndpointPOST /v1/me/benefits/exchangePOST /v1/benefits/redeem
CredentialEnd-user tokenCommerce API key

The endpoints

The 401 across the whole section

All of these endpoints return 401 when the access token is missing, expired, or does not belong to an end user. It is the normal case once time has passed: renew it and retry the call.