API documentation

🛍️ Products & prices :- https://msconfirmationid.com/buy-api/products?limit=20&token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/buy-api/products?limit=20&token=YOUR_TOKEN

Products grouped by category, account prices, quantity tiers and stock. Use next_after_id as after_id for the next page.

Example · REST · GET

curl "https://msconfirmationid.com/wp-json/tgbt-api/v1/buy/products?limit=20" \
  -H "X-API-Key: YOUR_TOKEN"

Example response · success

Illustrative data only; keys, prices and balances are examples.

{
    "success": true,
    "data": {
        "categories": [
            {
                "category_id": 1,
                "name": "Software",
                "products": [
                    {
                        "product_id": 123,
                        "code": 123,
                        "name": "Example license",
                        "description": "One license key",
                        "unit_price": "3.00",
                        "stock": 4,
                        "delivery": "Instant Delivery",
                        "warranty": "30 days"
                    },
                    {
                        "product_id": 124,
                        "code": 124,
                        "name": "Example manual product",
                        "description": "",
                        "unit_price": "5.00",
                        "stock": "out_of_stock",
                        "delivery": "2 hours",
                        "warranty": "7 days",
                        "customer_info_required": true,
                        "quantity_prices": [
                            {
                                "min_quantity": 10,
                                "unit_price": "4.50"
                            }
                        ]
                    }
                ]
            }
        ],
        "next_after_id": null,
        "limit": 20
    }
}

Stock is a positive number or out_of_stock. Quantity pricing and customer-information requirements appear only when applicable. Delivery and warranty contain the product labels.

Pending imported keys: if status is processing, show the message and only the keys actually present in the keys array. Check the order endpoint later with order_id. Do not display request_id, request_reference, or your own integration tracking reference as a product key or customer delivery message. These identify requests, not delivered licenses. Supplier references are internal. Retrying the same purchase request_id returns the current order without a new purchase; use the same original purchase parameters. Never send a new request_id merely to check delivery.

🛒 Buy product or create account :- https://msconfirmationid.com/buy-api/buy?code=Product_ID&quantity=Quantity&token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/buy-api/buy?code=123&quantity=1&token=YOUR_TOKEN

Buy 1–100 products using code (product ID) and quantity. Custom O365 accounts require quantity 1 plus first_name, last_name and username. A custom order may return processing while the provider creates it; poll order for email and password.

Example · REST · POST

curl -X POST "https://msconfirmationid.com/wp-json/tgbt-api/v1/buy/buy" \
  -H "X-API-Key: YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"code":123,"quantity":1}'

Example response · success

Illustrative data only; keys, prices and balances are examples.

{
    "success": true,
    "request_id": "auto-123e4567-e89b-42d3-a456-426614174000",
    "data": {
        "order_id": 1323,
        "order_number": "EXAMPLE-1323",
        "product_id": 123,
        "quantity": 1,
        "status": "completed",
        "delivery_type": "automatic",
        "total": "3.000000",
        "keys": [
            {
                "key": "EXAMPLE-KEY-NOT-VALID",
                "details": "Example activation information",
                "delivered_at": "2026-10-11 09:00:00"
            }
        ],
        "customer_info": "",
        "customer_info_required": false,
        "delivery_details": [],
        "instructions": "Follow the activation instructions provided with your product.",
        "instructions_html": "<p>Follow the activation instructions provided with your product.</p>",
        "created_at": "2026-10-11 09:00:00",
        "balances": {
            "USD Wallet balance": "$47.000000",
            "GetCID_balance": 0,
            "shared_with_telegram": true
        }
    }
}

This example shows a completed automatic delivery. Manual or pending orders may have an empty keys array; use Order details & keys to check progress. Manual delivery messages appear in delivery_details.

Pending imported keys: if status is processing, show the message and only the keys actually present in the keys array. Check the order endpoint later with order_id. Do not display request_id, request_reference, or your own integration tracking reference as a product key or customer delivery message. These identify requests, not delivered licenses. Supplier references are internal. Retrying the same purchase request_id returns the current order without a new purchase; use the same original purchase parameters. Never send a new request_id merely to check delivery.

Custom O365 account example

Use the imported custom product ID for the domain you want. Reuse the same request_id when retrying a request. A processing response means check the order endpoint until delivery is complete.

curl -X POST "https://msconfirmationid.com/wp-json/tgbt-api/v1/buy/buy" -H "X-API-Key: YOUR_TOKEN" -H "Content-Type: application/json" -d {"product_id":123,"quantity":1,"first_name":"John","last_name":"Doe","username":"john.doe","request_id":"custom-john-doe-001"}

Want duplicate-order protection? Add orderId using your own website’s order number, for example orderId=1323. Retry the same purchase with the same number, product and quantity to avoid a second charge. Use a different reference for each new purchase.

This is optional. Without it, every call is a new purchase; check Orders History after a timeout before trying again. The response includes your generated order ID and request reference. request_id is also accepted instead of orderId.

Browser URL · GET

https://msconfirmationid.com/buy-api/buy?code=123&quantity=1&orderId=1323&token=YOUR_TOKEN

REST · POST

curl -X POST "https://msconfirmationid.com/wp-json/tgbt-api/v1/buy/buy" -H "X-API-Key: YOUR_TOKEN" -H "Content-Type: application/json" -d '{"code":123,"quantity":1,"orderId":"1323"}'

📦 Order details & delivery :- https://msconfirmationid.com/buy-api/order?order_number=Order_number&token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/buy-api/order?order_number=ORDER_NUMBER&token=YOUR_TOKEN

Read your latest order state, keys and messages. Use order_id or order_number; your original purchase orderId is also accepted. Includes Telegram orders.

Example · REST · GET

curl "https://msconfirmationid.com/wp-json/tgbt-api/v1/buy/order?order_number=ORDER_NUMBER" \
  -H "X-API-Key: YOUR_TOKEN"

Example response · success

Illustrative data only; keys, prices and balances are examples.

{
    "success": true,
    "data": {
        "order_id": 1323,
        "order_number": "EXAMPLE-1323",
        "product_id": 123,
        "quantity": 1,
        "status": "completed",
        "delivery_type": "automatic",
        "total": "3.000000",
        "keys": [
            {
                "key": "EXAMPLE-KEY-NOT-VALID",
                "details": "Example activation information",
                "delivered_at": "2026-10-11 09:00:00"
            }
        ],
        "customer_info": "",
        "customer_info_required": false,
        "delivery_details": [],
        "instructions": "Follow the activation instructions provided with your product.",
        "instructions_html": "<p>Follow the activation instructions provided with your product.</p>",
        "created_at": "2026-10-11 09:00:00",
        "balances": {
            "USD Wallet balance": "$47.000000",
            "GetCID_balance": 0,
            "shared_with_telegram": true
        }
    }
}

This example shows a completed automatic delivery. Manual or pending orders may have an empty keys array; use Order details & keys to check progress. Manual delivery messages appear in delivery_details.

Pending imported keys: if status is processing, show the message and only the keys actually present in the keys array. Check the order endpoint later with order_id. Do not display request_id, request_reference, or your own integration tracking reference as a product key or customer delivery message. These identify requests, not delivered licenses. Supplier references are internal. Retrying the same purchase request_id returns the current order without a new purchase; use the same original purchase parameters. Never send a new request_id merely to check delivery.

📜 Orders History :- https://msconfirmationid.com/buy-api/orders?token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/buy-api/orders?token=YOUR_TOKEN

Latest 50 orders and failed purchase attempts, newest first. Use an order ID or number for delivery details.

Example · REST · GET

curl "https://msconfirmationid.com/wp-json/tgbt-api/v1/buy/orders" \
  -H "X-API-Key: YOUR_TOKEN"

🛡 Warranty status & replacements :- https://msconfirmationid.com/buy-api/warranty?order_id=Order_ID&token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/buy-api/warranty?order_id=123&token=YOUR_TOKEN

Read warranty eligibility and per-key replacement history for your own order. Use order_id or order_number. Replacement keys have no further warranty.

Example · REST · GET

curl "https://msconfirmationid.com/wp-json/tgbt-api/v1/buy/warranty?order_id=123" \
  -H "X-API-Key: YOUR_TOKEN"

Warranty workflow

1. Read the order or warranty endpoint. Show Claim warranty only when can_claim is true.
2. POST the order ID and affected original key(s). For a single-key order, your app can take the key from the order response automatically. The API still requires that key.
3. Read each result status below. If pending, check the warranty endpoint later to retrieve the replacement after admin fulfillment. Avoid continuous polling.

Authenticate with the buying account’s API key. You may use order_number instead of order_id. Only original keys belonging to that account and order qualify. Each original key gets one replacement; replacement keys have no further warranty. No new purchase or wallet charge occurs.

Illustrative response

Example keys and dates only.

{
    "success": true,
    "data": {
        "can_claim": true,
        "expires_at": "2026-11-01 12:00:00 UTC",
        "original_keys_remaining": 1,
        "replacement_warranty": false,
        "claims": []
    }
}

Per-key results

Inspect every result: top-level success: true means the request was processed, not that every key was replaced. Accepted pending/completed claims are safe to retry: the existing result is returned without another replacement. After a timeout, check warranty status before retrying. Warranty GET returns history in data.claims; claim POST returns results in data.results.

Global PID bypass, provider errors or unclear verification queue manual review. Enabled main-admin replacement alerts cover API claims too. After admin fulfillment, retrieve the new key through the warranty or order endpoint; this feature does not send an API callback to your website.

🛡 Claim warranty replacement :- POST https://msconfirmationid.com/wp-json/tgbt-api/v1/buy/warranty/claim

POST only. Send order_id (or order_number) and key, or keys (up to 2). Only original keys delivered to your own order qualify. Each key can be replaced once. Global PID bypass, provider errors or unclear results queue admin review. Confirmed dead keys are replaced from suitable stock; otherwise await stock/admin. No purchase or wallet debit is made. Inspect each result status; retrying an accepted claim does not allocate another key.

Example · REST · POST

curl -X POST "https://msconfirmationid.com/wp-json/tgbt-api/v1/buy/warranty/claim" \
  -H "X-API-Key: YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"order_id":123,"key":"AAAAA-BBBBB-CCCCC-DDDDD-EEEEE"}'

Warranty workflow

1. Read the order or warranty endpoint. Show Claim warranty only when can_claim is true.
2. POST the order ID and affected original key(s). For a single-key order, your app can take the key from the order response automatically. The API still requires that key.
3. Read each result status below. If pending, check the warranty endpoint later to retrieve the replacement after admin fulfillment. Avoid continuous polling.

Authenticate with the buying account’s API key. You may use order_number instead of order_id. Only original keys belonging to that account and order qualify. Each original key gets one replacement; replacement keys have no further warranty. No new purchase or wallet charge occurs.

Multiple keys · POST JSON body

Use key for one key or keys for up to two. Send remaining keys in another request.

{
    "order_id": 123,
    "keys": [
        "AAAAA-BBBBB-CCCCC-DDDDD-EEEEE",
        "FFFFF-GGGGG-HHHHH-IIIII-JJJJJ"
    ]
}

Illustrative response

Example keys and dates only.

{
    "success": true,
    "data": {
        "order_id": 123,
        "results": [
            {
                "original_key": "AAAAA-BBBBB-CCCCC-DDDDD-EEEEE",
                "claim_id": 42,
                "status": "replaced",
                "message": "✅ Warranty replacement ready. Use the new key today. Replacement keys have no further warranty.",
                "replacement_key": "KKKKK-LLLLL-MMMMM-NNNNN-OOOOO",
                "details": "Example activation instructions",
                "replacement_warranty": false
            }
        ]
    }
}

Per-key results

Inspect every result: top-level success: true means the request was processed, not that every key was replaced. Accepted pending/completed claims are safe to retry: the existing result is returned without another replacement. After a timeout, check warranty status before retrying. Warranty GET returns history in data.claims; claim POST returns results in data.results.

Global PID bypass, provider errors or unclear verification queue manual review. Enabled main-admin replacement alerts cover API claims too. After admin fulfillment, retrieve the new key through the warranty or order endpoint; this feature does not send an API callback to your website.

Success: {"success":true,"data":{...}}. Failure: {"success":false,"error":{"code":"...","message":"..."}}. For history lookups, inspect the nested saved response too. Times are UTC; money uses decimal USD strings.

Product purchases accept an optional request_id/orderId; without one, every call is a new purchase. Check Orders History after a timeout before buying again. Other actions in this section still require a reference. Supplied references must be unique for each new action (1–64 letters, digits, dot, colon, underscore or hyphen). Repeat the same action with the same ID and fields to replay its result. After a timeout, find the matching reference in history. Processing/review: wait or contact support; do not submit another ID.

200: read/success · 202: still processing/review · 400: input or service error · 401/403: key/access · 404: missing record/endpoint · 409: account busy or action conflict · 429: limit · 503: temporarily unavailable. A saved failed action may be returned inside a successful history lookup.

Limit: 30 requests/minute per account. OCR: 100/day. PID shares the bot’s daily quota. Purchases and deposit actions may return account_busy; retry those using the same ID.

🔢 GetCID :- https://msconfirmationid.com/getcid-api/generate?iid=Your_IID_here&token=your_api_key_here

Example · Browser URL · GET · IID with hyphens

https://msconfirmationid.com/getcid-api/generate?iid=6407142-1898830-5913156-7151185-2805065-1745860-9354801-9089053-2803922&token=YOUR_TOKEN

Send a 54- or 63-digit IID and API key. No client reference is needed in Browser or REST calls. No charges for old/public CIDs or failed/blocked requests.

Example · REST · POST

curl -X POST "https://msconfirmationid.com/wp-json/tgbt-api/v1/getcid/generate" \
  -H "X-API-Key: YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"iid":"6407142-1898830-5913156-7151185-2805065-1745860-9354801-9089053-2803922"}'

Example response · success

Uses the sample IID above. This CID is illustrative, not an activation result. Billing and balances depend on your account.

{
    "success": true,
    "data": {
        "iid": "640714218988305913156715118528050651745860935480190890532803922",
        "cid": "111111-222222-333333-444444-555555-666666-777777-888888",
        "billing": "package",
        "balances": {
            "USD Wallet balance": "$47.000000",
            "GetCID_balance": 9,
            "shared_with_telegram": true
        }
    }
}

CID billing values

• package: one purchased CID credit.
• public_charged: public lookup succeeded and this account is configured to pay one CID credit.
• database_charged: one CID credit for another user’s stored CID when free sharing is disabled.
• public_free / database_free: no purchased CID credit used.
• daily_free_paid: this bot/account’s rolling free paid-provider allowance was used.

The API key selects the bot and account; callers cannot change their scope with a bot_id parameter. With no available credit, a chargeable public or stored CID returns cid_package_required without delivering the CID. Telegram and API share the same account allowance. Optional entitlement_id selects one of your CID packages.

Browser URL · GET

https://msconfirmationid.com/getcid-api/generate?iid=640714218988305913156715118528050651745860935480190890532803922&token=YOUR_TOKEN

REST · POST

curl -X POST "https://msconfirmationid.com/wp-json/tgbt-api/v1/getcid/generate" -H "X-API-Key: YOUR_TOKEN" -H "Content-Type: application/json" -d '{"iid":"640714218988305913156715118528050651745860935480190890532803922"}'

Both IID formats work: with hyphens, as shown above, or digits only. No request reference is needed.

💰 GetCID balance :- https://msconfirmationid.com/getcid-api/balance?token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/getcid-api/balance?token=YOUR_TOKEN

Shows your USD wallet balance and GetCID credits.

Example · REST · GET

curl "https://msconfirmationid.com/wp-json/tgbt-api/v1/getcid/balance" \
  -H "X-API-Key: YOUR_TOKEN"

🕘 GetCID history :- https://msconfirmationid.com/getcid-api/history?token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/getcid-api/history?token=YOUR_TOKEN

Shows your last 50 CID requests, newest first.

Example · REST · GET

curl "https://msconfirmationid.com/wp-json/tgbt-api/v1/getcid/history" \
  -H "X-API-Key: YOUR_TOKEN"

Success: {"success":true,"data":{...}}. Failure: {"success":false,"error":{"code":"...","message":"..."}}. For history lookups, inspect the nested saved response too. Times are UTC; money uses decimal USD strings.

GetCID generation needs IID and API key, with optional entitlement_id; no client reference in Browser or REST calls. History shows your latest 50 requests.

200: read/success · 202: still processing/review · 400: input or service error · 401/403: key/access · 404: missing record/endpoint · 409: account busy or action conflict · 429: limit · 503: temporarily unavailable. A saved failed action may be returned inside a successful history lookup.

Limit: 30 requests/minute per account. OCR: 100/day. PID shares the bot’s daily quota. Purchases and deposit actions may return account_busy; retry those using the same ID.

📷 Read Installation ID :- https://msconfirmationid.com/ocr-api/recognize?image_url=Your_image_URL_here&token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/ocr-api/recognize?image_url=https://msconfirmationid.com/wp-content/plugins/telegram-commerce-0.16.5/assets/ocr-sample.png&token=YOUR_TOKEN

Read an IID from a JPEG/PNG/WebP image, max 5 MB and 25 megapixels. Browser: image_url. REST also accepts image_base64 or multipart image. No client reference is needed. Each call runs OCR and uses daily allowance. Result: data.iid; no CID is generated.

Example · REST · POST

curl -X POST "https://msconfirmationid.com/wp-json/tgbt-api/v1/ocr/recognize" \
  -H "X-API-Key: YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"image_url":"https://msconfirmationid.com/wp-content/plugins/telegram-commerce-0.16.5/assets/ocr-sample.png"}'

🕘 OCR history :- https://msconfirmationid.com/ocr-api/history?token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/ocr-api/history?token=YOUR_TOKEN

Shows your last 30 OCR requests, newest first.

Example · REST · GET

curl "https://msconfirmationid.com/wp-json/tgbt-api/v1/ocr/history" \
  -H "X-API-Key: YOUR_TOKEN"

Success: {"success":true,"data":{...}}. Failure: {"success":false,"error":{"code":"...","message":"..."}}. For history lookups, inspect the nested saved response too. Times are UTC; money uses decimal USD strings.

OCR needs only an image and API key. Each call runs OCR and consumes daily allowance; results are not replayed. After a timeout, inspect history before retrying.

200: read/success · 202: still processing/review · 400: input or service error · 401/403: key/access · 404: missing record/endpoint · 409: account busy or action conflict · 429: limit · 503: temporarily unavailable. A saved failed action may be returned inside a successful history lookup.

Limit: 30 requests/minute per account. OCR: 100/day. PID shares the bot’s daily quota.

🔍 PID key check :- https://msconfirmationid.com/pid-api/check?key=Your_key_here&token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/pid-api/check?key=N3B73-7TG3P-XJX6X-33M3M-HT9TT&token=YOUR_TOKEN

Check up to 100 keys using key (one) or keys (array, comma or newline-separated) and API key. No client reference is needed in Browser or REST calls. Each unique key uses one shared daily PID check.

Example · REST · POST

curl -X POST "https://msconfirmationid.com/wp-json/tgbt-api/v1/pid/check" \
  -H "X-API-Key: YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"key":"N3B73-7TG3P-XJX6X-33M3M-HT9TT"}'

Example response · success

Uses the sample key above. This is an illustrative response, not a live check. Check each item in results: an individual key may return success=false with an error.

{
    "success": true,
    "data": {
        "count": 1,
        "results": [
            {
                "key": "N3B73-7TG3P-XJX6X-33M3M-HT9TT",
                "success": true,
                "result": {
                    "status": "valid",
                    "description": "Example product description",
                    "remaining": "10",
                    "error_code": "0xC004C008",
                    "subtype": "Example product subtype",
                    "blocked": false
                }
            }
        ]
    }
}

Browser URL

https://msconfirmationid.com/pid-api/check?keys=N3B73-7TG3P-XJX6X-33M3M-HT9TT,B8N2B-G68RJ-HGJC4-GXWDT-2BCBV&token=YOUR_TOKEN

REST API · POST

curl -X POST "https://msconfirmationid.com/wp-json/tgbt-api/v1/pid/check" -H "X-API-Key: YOUR_TOKEN" -H "Content-Type: application/json" -d '{"keys":["N3B73-7TG3P-XJX6X-33M3M-HT9TT","B8N2B-G68RJ-HGJC4-GXWDT-2BCBV"]}'

Send up to 100 keys per request. Duplicate keys count once. Inspect each result; a completed HTTP request can include failed checks.

🕘 PID Key Checker history :- https://msconfirmationid.com/pid-api/history?token=your_api_key_here

Example · Browser URL · GET

https://msconfirmationid.com/pid-api/history?token=YOUR_TOKEN

Shows your last 30 key checks, newest first.

Example · REST · GET

curl "https://msconfirmationid.com/wp-json/tgbt-api/v1/pid/history" \
  -H "X-API-Key: YOUR_TOKEN"

Success: {"success":true,"data":{...}}. Failure: {"success":false,"error":{"code":"...","message":"..."}}. For history lookups, inspect the nested saved response too. Times are UTC; money uses decimal USD strings.

PID checks need key or keys and API key; no client reference in Browser or REST calls. Checks run on each call and consume daily allowance. After a timeout, inspect history before checking again.

200: read/success · 202: still processing/review · 400: input or service error · 401/403: key/access · 404: missing record/endpoint · 409: account busy or action conflict · 429: limit · 503: temporarily unavailable. A saved failed action may be returned inside a successful history lookup.

Limit: 30 requests/minute per account. OCR: 100/day. PID shares the bot’s daily quota.