Aska Supplier API

Initial onboarding. Send your full inventory as an array of DiamondStock objects. Aska creates new WebLiveStock rows scoped to your PartyId and runs the field-mapping (shape/color/clarity labels → master IDs) server-side.

Body shape

[
  {
    "TagNo":      "SUP-ABC-001",
    "RefStockId": "ABC-001",
    "ShapeId":    "Round",
    "ColorId":    "F",
    "ClarityId":  "VS1",
    "CutId":      "Excellent",
    "PolishId":   "EX",
    "SymmId":     "EX",
    "FluoId":     "NON",
    "LabId":      "IGI",
    "CertNo":     "LG12345",
    "Cts":        1.05,
    "Rate":       190.50,
    "Amount":     200.03,
    "StoneType":  "HPHT",
    "Location":   "India",
    "ImageFile1": "https://your-cdn.example/abc-001.jpg",
    "VideoFile1": "https://your-cdn.example/abc-001.mp4",
    "CertiFile":  "https://your-cdn.example/abc-001-cert.pdf"
  }
]

curl

curl -X POST https://aska.co.in/api/askajewels/UploadStock \
  -H "transkey: ak_<your-token>" \
  -H "Content-Type: application/json" \
  --data @stones.json

Whitelist-update mode. The server looks up (refStockId, your PartyId) and updates matching rows only. If the SKU doesn't exist on our side, it's silently skipped (returned in the skipped count). Use /UpsertStock below to insert-or-update in one call. Master values (shape, color, clarity, cut, polish, symm, fluo, lab) are accepted as human-readable strings ("Round", "VS1", "D"); we resolve them via the existing master tables. The SP enforces PartyId scoping — a leaked key can only touch its own supplier's inventory.

Body shape

{
  "stones": [
    {
      "refStockId": "ABC-001",
      "cts":         1.05,
      "rate":      190.50,
      "mrate":     175.00,
      "certNo":   "LG12345",
      "shape":    "Round",
      "color":    "F",
      "clarity":  "VS1",
      "cut":      "Excellent",
      "polish":   "Excellent",
      "symm":     "Excellent",
      "fluo":     "None",
      "lab":      "GIA"
    },
    { "refStockId": "ABC-002", "rate": 170.00 }
  ]
}

Response

{
  "Result": {
    "inserted": 1,
    "updated":  1,
    "total":    2,
    "requested": 2
  },
  "Message": "Success"
}

Notes: refStockId is the canonical lookup key (your own SKU). Legacy payloads that send stockId instead are accepted as an alias for back-compat. The skipped count tells you how many rows didn't match. To insert-or-update in one call, use /UpsertStock below.

Best for bootstrap loads where you want guaranteed no-overwrite behaviour. The server checks (refStockId, your PartyId) for each row. If a row already exists, it is skipped — never updated — and listed in duplicates[] with the existing internal Aska TagNo. If your payload contains the same refStockId twice, only the first occurrence is inserted; the rest also surface in duplicates[] with reason="duplicate_in_payload". Non-destructive — your existing inventory stays intact. Distinct from /UploadStock (legacy bulk replace) and /UpsertStock (insert-or-update).

Body shape

{
  "stones": [
    { "refStockId": "ABC-001", "cts": 1.05, "rate": 190.50,
      "shape": "Round", "color": "F", "clarity": "VS1" },
    { "refStockId": "ABC-002", "cts": 0.50, "rate": 170.00 }
  ]
}

Response

{
  "Result": {
    "inserted": 1,
    "skipped": 1,
    "total": 1,
    "requested": 2,
    "duplicates": [
      { "refStockId": "ABC-001", "existingTagNo": "AJ0076", "reason": "existing" }
    ]
  },
  "Message": "Success"
}

Why dedupe? Earlier integrations using /UploadStock (which is destructive REPLACE) could accidentally duplicate stones across runs. /InsertStock never produces a duplicate row, and the duplicates[] array lets your ERP see exactly which of your refStockIds we already know about.

Best for "sync everything from ERP" integrations — your ERP doesn't need to track which SKUs we already have. The server looks up (refStockId, your PartyId) and updates if it exists, inserts if it doesn't. Returned counts split inserted vs updated so your ERP can see what happened. The internal Aska TagNo (AJ + 4-digit) is auto-assigned on insert; you never need to know it.

Body shape

{
  "stones": [
    { "refStockId": "ABC-001", "cts": 1.05, "rate": 190.50,
      "shape": "Round", "color": "F", "clarity": "VS1" },
    { "refStockId": "ABC-002", "rate": 170.00 }
  ]
}

Response

{ "Result": { "inserted": 1, "updated": 1, "total": 2, "requested": 2 }, "Message": "Success" }

Wire this first. Your ERP should fire it the instant a stone is sold off-platform so buyers on aska.co.in don't try to purchase a stone you no longer have. Idempotent — repeated calls with the same ids no-op. The stone disappears from buyer-facing search; it stays in your MyStock response with a flag so you can audit.

Conflict response (HTTP 409): if any of the stockIds you send have an active in-flight buyer order that hasn't shipped yet (Aska has already committed it to a buyer), the call returns { blocked: true, reason: "committed_to_buyer", conflictingTagNos: [...] } and queues an admin alert for manual reconciliation. Aska will reach out — please don't double-commit.

Body shape

{
  "stockIds": ["SUP-ABC-001", "SUP-ABC-002"],
  "reason":   "Sold elsewhere"
}

Read-only verification + the source of truth for what your ERP should sync against. Returns every WebLiveStock row scoped to your PartyId, with label-resolved fields (HPHT / Oval Brilliant / IGI, etc.) — not raw IDs. Recommended polling cadence: every 5–10 minutes while an ERP sync is active. Aska is one-way push-only — there is no outbound webhook from our side today.

Response

{
  "Result": {
    "partyId": 95,
    "stones": [
      {
        "UniqueId": "730",
        "StockId":  "AJ0036",
        "StoneType":"HPHT",
        "Shape":    "Oval Brilliant",
        "Color":    "E",
        "Clarity":  "VS1",
        "Cut":      "EX",
        "Polish":   "EX",
        "Symm":     "EX",
        "Fluo":     "",
        "Lab":      "IGI",
        "CertNo":   "678530428",
        "Cts":      "1.70",
        "Rate":     "155.00",
        "Amount":   "263.50",
        "Location": "India",
        "ImageFile":"https://aska.co.in/aska/Diamonds/AJH001252/AJH001252.JPEG",
        "VideoFile":"https://aska.co.in/aska/Diamonds/AJH001252/AJH001252.MP4"
      }
    ]
  },
  "Message": "Success"
}

Poll periodically (every 5–10 min) to discover new buyer requests on your stones. Each row carries the OrderDetailId you'll quote in StoneApprove / StoneOutofStock. Body is empty {}.

Send a list of OrderDetailIds you're approving. We'll route the stone to the right Aska office (Mumbai for India suppliers, USA for US suppliers) and email you the shipping label info.

Body shape

[
  { "OrderDetailId": 134 },
  { "OrderDetailId": 135 }
]

Aska auto-marks the stone unavailable and notifies the buyer with a generic apology — your rejection reason is admin-internal only, never shared with the buyer. Repeated rejections affect your supplier rating (/Admin/SellerRejectionStats).