Staging
Test your integration against demo data before going live
Staging
Staging runs the same code as production against its own database, seeded with demo customers. Build and test against it, then change one URL to go live.
| Staging | Production | |
|---|---|---|
| Base URL | https://staging-api.loyalty.lt | https://api.loyalty.lt |
| Code | The same commit as production | — |
| Data | Your real catalogue, demo customers | Real customers |
| Credentials | Staging pair only | Production pair only |
| Refresh | Every Sunday morning | Never |
Create a staging key/secret in the Partners Portal → API Credentials → environment Staging. Staging credentials are rejected by the production API and vice versa.
curl -X POST "https://staging-api.loyalty.lt/lt/shop/validate-credentials" \
-H "X-API-Key: $LOYALTY_API_KEY" \
-H "X-API-Secret: $LOYALTY_API_SECRET"What is in there
Your partner record, shops, products, offers and games are copied from production, so the catalogue you test against is your own. Customers are not — those are demo accounts created fresh:
| Customer | Phone | Points |
|---|---|---|
demo@loyalty.lt | +37060000001 | 1500 |
test@loyalty.lt | +37060000002 | 500 |
sdk@loyalty.lt | +37060000003 | 2500 |
Each one holds a loyalty card for every partner, numbered
900-{user_id}-{partner_id} with both parts zero-padded to three digits.
Do not hardcode a card number. The IDs change whenever staging is refreshed. Look the card up by the customer instead:
curl -X GET "https://staging-api.loyalty.lt/lt/shop/loyalty-cards/info?user_email=demo@loyalty.lt" \
-H "X-API-Key: $LOYALTY_API_KEY" -H "X-API-Secret: $LOYALTY_API_SECRET"loyalty-cards/info takes card_number, card_id, user_id or user_email — the
last is the one that survives a refresh, since the demo emails never change. Note that
plain GET /shop/loyalty-cards lists the partner's card designs, not customers'
cards.
Two demo staff accounts exist for the POS staff app: staff@loyalty.lt (cashier) and
manager@loyalty.lt (manager).
Weekly refresh
Every Sunday morning, in order:
| Time (EET) | What happens |
|---|---|
| 04:00 | The database is cleared |
| 05:00 | Your partner record, shops, products, offers and games re-copied from production |
| 06:00 | Demo customers, their cards and demo staff recreated |
Cleaning first is deliberate: the clear cascades through users, so running it after the copy would discard what the copy just brought in.
Your API credentials survive. Anything you created during the week does not — treat staging as disposable and make your tests recreate what they need.
A first end-to-end test
// 1. Credentials reach the API
await sdk.validateCredentials();
// 2. Find a shop to work against
const { data: shops } = await sdk.getShops();
const shopId = shops[0].id;
// 3. Register a purchase — this awards the points
await sdk.createTransaction({
user_email: 'demo@loyalty.lt',
order_id: `TEST-${Date.now()}`,
order_total: 25.50,
currency: 'EUR',
shop_id: shopId,
});
// 4. Read the new balance
const card = await sdk.getLoyaltyCardInfo({ user_email: 'demo@loyalty.lt' });
const balance = await sdk.getPointsBalance({ card_id: card.id });Then reverse it, using the same order_id:
await sdk.createTransaction({
user_email: 'demo@loyalty.lt',
order_id: 'TEST-...', // the same order_id as above
type: 'refund',
order_total: 25.50,
});When something does not work
Staging-specific answers — expired credentials, missing demo cards, what survives the weekly refresh — are in the FAQ.
Stuck? info@loyalty.lt — include your partner ID
and the request_id from the response.