Can an AI agent buy here without any human involvement?

Yes. Search, order, payment and delivery are all plain HTTP with JSON bodies. Payment is an on-chain transfer or an x402 USDC settlement, which a wallet-holding agent performs on its own. Nothing in the flow renders a page or requires a click.

Does the agent need an API key or an account?

No. The public API takes no credentials. The order create call returns a per-order access token, and that token is the only secret in the whole flow.

What exactly does the agent receive after paying?

The order poll response. For gift cards it carries delivery.code, for eSIMs an esim object with the iccid and the LPA activation string, for phone numbers the number itself. The same content also goes to the delivery email.

Is it safe to retry a request that timed out?

Yes, if you sent an Idempotency-Key header on the create call. A repeat with the same key returns the same order instead of creating a second one. Payment settlement is idempotent on the provider side as well.

What happens when fulfilment fails after payment?

The order status turns to failed and the response says so. Refunds are handled by a human: write to support@blinkcodes.com with the order id. There is no automatic refund endpoint, deliberately.

How current is the catalog?

It refreshes on a 25-minute cycle. Cache product lists on your side rather than re-listing 1200 rows per query, and re-read a single product right before ordering: the detail endpoint is uncached.

for AI agents

A store your AI agent can buy from

Point an agent at blinkcodes.com and it can search roughly 1200 gift cards, top-ups and travel eSIMs, pay, and read the delivered code out of a JSON response. No account signup, no browser session, no CAPTCHA. The delivery email address is the only identity the store asks for.

Every endpoint below is the same API the site itself runs on, so nothing here is a demo sandbox. If you are an agent reading this page right now, fetch https://blinkcodes.com/llms.txt first. It is shorter than this page and written for you.

buy.sh

# 1. search the catalog
curl "https://blinkcodes.com/api/public/products?q=steam&type=voucher"

# 2. create the order (email is the only identity)
curl -X POST https://blinkcodes.com/api/public/create-order \
  -H "Idempotency-Key: agent-7f3a" \
  -H "Content-Type: application/json" \
  -d '{"email":"agent@example.com","product_type":"giftcard",
       "product_id":123,"item_id":456}'
# -> {"order_id":"...","access_token":"..."}

# 3. pay with an on-chain transfer
curl -X POST https://blinkcodes.com/api/public/create-heleket-payment \
  -d '{"order_id":"...","to_currency":"USDT","network":"bsc"}'
# -> {"address":"0x...","pay_amount":"5.28"}

# 4. poll until completed, read the code
curl "https://blinkcodes.com/api/public/order/{order_id}?token={access_token}"
# -> {"status":"completed","delivery":{"code":"XXXX-YYYY-ZZZZ"}}

The whole flow is 4 HTTP calls

Search, create, pay, poll. The create call answers with an order id and a per-order access token, and that token is the only credential you will ever hold. Send an Idempotency-Key header on the create call: a retried request resolves to the same order instead of buying twice.

quantity defaults to 1, so a minimal gift card body is just email, product_type, product_id and item_id. Once the order reaches completed, the same poll response carries the code. It also goes out by email, but the agent never needs to read a mailbox.

Machine-readable everything

Agents should not scrape this site, and they do not have to. The discovery documents below describe every public endpoint, the auth model and the payment constraints. They are generated from the same code that serves the API, so they cannot drift from reality.

Or talk to it: MCP and A2A

The store runs an MCP server at https://blinkcodes.com/mcp (Streamable HTTP) and an A2A agent at https://blinkcodes.com/a2a (JSON-RPC message/send, card at /.well-known/agent-card.json). Both expose the same two read-only tools, search_catalog and get_product, so a chat-native agent can browse without writing HTTP calls.

Buying stays on the HTTP flow on purpose. A purchase takes money and a delivery address, and that decision belongs in code you wrote, not in a tool call a model improvised.

Paying without a browser

Two rails. The crypto invoice (create-heleket-payment) answers with a plain on-chain address and an exact amount, USDT on bsc or tron being the reliable pairs, with a 1 USD minimum per order. x402 at /api/v1/buy sells the goods in a single call: the first request answers 402 with the exact USDC price on Base, the same request with a signed X-PAYMENT header settles and fulfils. No minimum, so it is the rail for anything under the invoice floor.

Pricing is discoverable before any order exists: each payable operation in /openapi.json carries an MPP (Machine Payment Protocol) x-payment-info block with the rail's floor, and /api/public/payment-methods reports the same numbers live.

x402.sh

# quote: 402 carries accepts[] with the exact USDC amount
curl -X POST https://blinkcodes.com/api/v1/buy \
  -d '{"email":"agent@example.com","product_type":"giftcard",
       "product_id":123,"item_id":456}'

# same request + signed X-PAYMENT header: verify, settle, fulfil
# -> 200 {"delivery":{"code":"XXXX-YYYY-ZZZZ"}}

Questions agents (and their operators) ask

By product