Skip to main content

Changelog

2026-07-08 — IP allowlisting + source IPs on invoices​

  • IP allowlisting. Your API access can now be locked to your approved server IPs (IPv4 and IPv6, single addresses or CIDR ranges) — a leaked key becomes useless from anywhere else. Accounts created from July 2026 onward must have an allowlist configured before their first call; earlier accounts are unchanged until they opt in. Requests from an unapproved address get 403 with error code ip.not_allowed (the rejected IP is echoed so you know exactly what to ask us to add); accounts that require an allowlist but haven't configured one get ip.not_configured. Blocked requests are refused before any processing — a blocked purchase never charges your wallet. Send your server IPs to Plustive to set up or change your list. See Authentication → IP allowlisting.
  • Source IP on every purchase (additive). Each purchase now records the IP it was made from. It appears per transaction on your invoice CSV, and your invoice PDF includes a summary of the addresses your account purchased from during the cycle — useful for reconciling exactly which of your servers made which purchases. Existing integrations are unaffected.

2026-06-20 — Idempotency-collision detection​

  • Reusing a clientReference for a different order now returns 409 Conflict. If a clientReference that already has a transaction arrives with different order-defining parameters — a different plan/product, recipient, or (for variable-amount bills like electricity) amount — we reject it with 409 Conflict (error code transaction.idempotency_conflict) and make no purchase, instead of silently returning the unrelated original transaction. A genuine retry with the same parameters is unchanged: it still returns the original transaction with the idempotentReplay flag / Idempotent-Replay header. Applies to all data, airtime and bill payment vends. See Idempotency.

2026-06 — Idempotent-replay signal​

  • Replays are now flagged (additive). When a purchase reuses a clientReference that already has a transaction, we return the original transaction unchanged (no new vend, no extra charge) — and now mark it so you can tell a replay from a fresh purchase: an "idempotentReplay": true field in the response body and an Idempotent-Replay: true response header. Fresh purchases are unflagged. Existing integrations are unaffected. See Idempotency.

2026-06 — Bill payments + reference sync​

  • Bill payments added. New endpoints for cable TV, electricity, education and broadband — list products, verify a customer identifier, and pay. See Bill payments.
  • token field (additive). Purchase and transaction responses now include an optional token (electricity prepaid token, education PIN; null otherwise). Existing integrations are unaffected.
  • service values. Transaction service now includes CableTv, Electricity, Education, Broadband alongside Data and Airtime.
  • ported removed from requests. Data and airtime purchases no longer accept a ported field — we always handle ported numbers upstream, so you don't need to send it. Requests that still include it are ignored (non-breaking).
  • providerReference. The upstream reference field is named providerReference (it was briefly dataStationReference); same value, neutral name.