REST API
Every connection to the promotions and loyalty engines goes through REST.
For developers
We plug into your stack. Not the other way around.
Payloot connects through a REST API to the architecture you already run. Here's what sits behind the console, how it connects and where its limits are.
# One condition, one benefit IF order.subtotal >= 150 && customer.segment == 'vip' AND NOT order.items.contains('restricted_category') THEN trigger.benefit({ type: 'gift_with_purchase', sku: 'premium_glass' }) > STATUS: rule evaluated and approved for checkout #9012
# Connect your engine POST /api/v1/promotions/sync { "cart": { ... }, "customer": { ... } } > 200 OK
# Order recalculation POST /v1/recalculo { "order_id": "8821", "picker_substitute": true, "items": [ ... ] } > 200 OK - recalculated
Illustrative examples. Your team gets the full reference once you request access.
One API in the middle of what you already run.
Your channels call the Payloot API. Payloot resolves the request with its engines and connects to your ERP, your OMS or your corporate engine.
Your channels
Ecommerce
App
Point of sale
Mobile wallets
Payloot
REST API
Rules engine
Loyalty engine
Recalculation
Your systems
ERPSAP or custom
OMSOrder management
Corporate engineIf you connect your own
How the engine is built.
Six design decisions that explain how Payloot behaves once it's connected to your operation.
Live evaluation
Each cart is evaluated against current rules. No saved results.
Instant changes
New rules go live across every channel without batch syncs.
Independent transactions
Loyalty earn and redeem are recorded separately, which keeps audits and reversals clean.
Line-level logic
Promotions and messages are calculated per line item, not just on the order total.
Recursive hierarchies
Store structure is read straight from your ERP, so rules roll out by branch.
Public docs, hands-on help where it counts.
Public APIs come with full documentation, so your team can integrate on its own. Specialized work is enabled together with our engineers.
Specialized APIs
Specialized endpoints, such as bulk loads, are enabled with hands-on support from our engineers to protect platform performance.
What we walk through with your engineers
- Evaluating a cart and applying a coupon.
- Earning and redeeming loyalty balance.
- Generating referral codes.
- Recalculating a modified order.
- Authentication, rate limits, versioning and test environment.
Map once, then let it run.
Every integration starts by mapping the fields Payloot needs to evaluate promotions and to earn or redeem balance.
| In your system (example) | What Payloot needs | What it's used for |
|---|---|---|
| Item code | SKU | Identify the products in each rule |
| List price | Price | Calculate the discount and its proration |
| Units in cart | Quantity | Evaluate buy X, get Y and tiered promotions |
| Customer or member ID | Customer | Segments, tiers and per-customer caps |
| Sales channel | Channel | Run different promotions in store and online |
| Store | Store | Regional rollout and store hierarchies |
Illustrative table. Actual field names depend on your system.
Built for high volume.
The engine is designed for high transaction volumes in online channels.
Coupons per day—
Transactions per second—
Uptime—
Caching and load on your infrastructure
Does Payloot use caching?
Not to calculate promotions. Payloot never answers with saved results: every cart is evaluated against the rules in effect right now, so customers always see the real promotion.
If you connect your own engine
Every request reaches your engine in real time, so it needs solid infrastructure. If it isn't built for that volume, our team can design a caching layer that protects it and keeps carts accurate.
If you use Payloot as your engine
Payloot provides the infrastructure. Because every cart is evaluated in real time, infrastructure cost varies with your volume.
Controls built in by design.
Product decisions that protect your data, your margin and your operation.
No card BINs
For security, card BINs aren't used inside the platform.
Identified customers
Deep discounts require the customer to identify first, so Payloot can check eligibility and history.
Audit log
Every rule change is recorded with user and date. See the audit log
What's included, and what isn't.
So you know from day one what the platform handles, what needs professional services and what isn't available.
| Capability | Status |
|---|---|
| Every promotion type, in every channel | Included |
| Order recalculation with card payments | Included |
| Recalculation with other payment methods | With professional services |
| Price differences on substitutes | With professional services |
| Caching for third-party engines | With professional services |
| Connectors beyond SAP, VTEX and Oracle Commerce | With professional services |
| Interest-free installment plans as a promotion | Not applicable: it's a payment method |
| Card-BIN promotions | Not supported, for security |
Ready to look under the hood?
Get access to the API docs, or tell us what you run and we'll map out the connection with you.