ब्लॉग पर वापस जाएं
तुलनातकनीक

B2B इमेज होस्टिंग API स्पेक्स 2026: खरीद से पहले 15 चेक पॉइंट

प्रकाशित12 min read
साझा करें

Image hosting vendor choose करना और database vendor choose करना — दोनों में एक बात common है: landing page का hero section देखकर decision मत लो।

मेरी company ने मुझसे एक alternative evaluate करने को कहा। मैंने पिछले तीन साल में production में जो भी गलतियाँ की थीं, उन सबको एक checklist में compile कर दिया। ये document CDN nodes count करने के लिए नहीं है। ये वो table है जो तुम directly RFP में paste करो और vendor से हर item पर "Yes / No / Partial" लिखवाओ। ऊपर से सब image hosting एक जैसा दिखता है, लेकिन architecture level पर बहुत फ़र्क होता है।

अगर तुम्हें बस free या सस्ता option चाहिए, तो पहले free image hosting comparison या Imgur alternatives देखो। ये article technical leads, SaaS procurement teams, और DevOps engineers के लिए है।

B2B Image Hosting Selection: Individual Users से पूरी तरह अलग Game

Individual user को बस इतना चाहिए — "upload हो रहा है? Link share हो रहा है?"

Enterprise का concern list बिलकुल different है। Contract में SLA mention है या नहीं? API पर heavy load आने पर rate limit कैसे degrade होगा? Egress cost किसी random month में double तो नहीं हो जाएगा? DPDP Act 2023 compliance audit में EXIF data retention period पूछा तो answer दे पाओगे?

सच बताऊं तो, B2B image hosting procurement basically तीन चीज़ें खरीदना है: predictable cost curve, verifiable system guarantees, और integrable protocol interfaces। नीचे की 15 items इन्हीं तीन pillars के around हैं।

एक बार production में incident हुआ, तब समझ आया — free plan demo तक चलता है, real traffic handle नहीं कर पाता।

India-Specific Compliance: IT Act और DPDP Act 2023

B2B procurement में India-specific rules ignore करना बड़ी गलती है। Digital Personal Data Protection Act (DPDP) 2023 अब enforce हो रहा है। Key points:

  • Data localization preference: Sensitive personal data ideally India में store होना चाहिए। AWS Mumbai (ap-south-1) या Jio Cloud support वाले vendors को priority दो।
  • Consent management: Image में embedded personal data (EXIF GPS coordinates, facial features) DPDP Act के under "personal data" है।
  • Data Principal rights: Users का delete request 72 hours में process होना चाहिए।
  • IT Act Section 43A: Data breach होने पर compensation liability vendor पर भी आ सकती है।

RFP में ये explicitly पूछो: "Do you have a data processing node in India or ap-south-1?"

15-Point RFP Checklist (Copy-Paste Ready)

ये table मैंने actual vendor evaluation में use किया था। हर item के साथ verification method दिया है — सिर्फ "support करते हो?" पूछने से काम नहीं चलता, क्योंकि vendor हमेशा Yes बोलेगा।

# Spec Item Verification Method Pass Criteria
1 S3 API Compatibility Run s3api list-objects-v2 --prefix Response schema matches AWS
2 Multipart Upload Upload 500MB file, interrupt & resume Supports part retry
3 Pre-signed URL Generate 15-min URL and verify signature HMAC-SHA256, configurable TTL
4 Webhook Events Trigger upload/delete events HMAC signature + retry mechanism
5 Rate Limit Policy Run burst test Returns 429 + Retry-After header
6 SLA Terms Read MSA contract >=99.9%, has service credit
7 Availability Zones Ask for region list >=2 regions, cross-region sync
8 Egress Billing Request pricing sheet Transparent pricing, tier discounts
9 Image Processing Pipeline Test on-the-fly transform WebP/AVIF support, URL params
10 CDN Edge Nodes Run global ping test >=50 PoP, includes Asia-Pacific
11 EXIF / Metadata Control Upload photo with GPS data Selective strip supported
12 Authentication Methods Review API docs OAuth2 + API Key rotation
13 Audit Logs Ask about log retention >=90 days, exportable
14 Compliance Certs Request SOC 2 / ISO 27001 At least one certification
15 Data Residency & Deletion Ask DPA terms Region selection + hard delete

सिर्फ Yes/No tick मत करो। हर item पर vendor से documentation link या technical verification step माँगो। जो attach नहीं किया, वो practically "planned but not implemented" है।

Core Specs की Implementation Details

Table skeleton है। नीचे वो items हैं जहाँ contract negotiation में vendors सबसे ज़्यादा mislead करते हैं।

S3 Compatibility: एक Line में नहीं Settle होता

"हम S3 compatible हैं" — ये image hosting vendors की favourite line है। लेकिन S3 API में 200+ operations हैं। Verify करना है कि तुम्हारे use case वाले operations काम करते हैं या नहीं।

Basic GetObject, PutObject तो सबके पास है। आगे बढ़ो:

# Test multipart
aws s3api create-multipart-upload --bucket test --key big.mp4 \
  --endpoint-url https://vendor.example.com

# Test versioning
aws s3api put-bucket-versioning --bucket test \
  --versioning-configuration Status=Enabled

# Test lifecycle
aws s3api put-bucket-lifecycle-configuration ...

मैंने खुद try किया — तीन में से तीनों pass करने वाले 60% से कम मिले। Especially bucket lifecycle और object lock — ये दोनों missing हों तो compliance audit में फँसोगे।

Pre-signed URL: TTL और Signature Algorithm

B2B scenario में ये सबसे common authentication method है। User के पास तुम्हारे credentials नहीं हैं, तुम एक time-limited ticket issue करते हो।

Underlying mechanism HMAC-SHA256 है — method, path, expiry, headers को pack करके string to sign बनाओ, secret key से sign करो। अच्छा vendor देगा:

  • Adjustable TTL (1 minute से 7 days तक)
  • Source IP locking (aws:SourceIp condition)
  • HTTP method restriction
  • SigV4 support (SigV2 outdated है, अभी भी SigV2 use करने वालों को directly reject करो)

बुरा vendor एक "never-expiring public URL" देगा और बोलेगा ये signed है। इसीलिए pre-signed URL RFP में explicitly mention होना चाहिए।

Webhook Signature Verification: इस Trap में मैं फँसा हूँ

Webhook event-driven architecture का core है। Upload complete, virus scan done, transcoding finished — हर event push होना चाहिए।

लेकिन webhook security में vendors सबसे ज़्यादा shortcut लेते हैं। मैंने जो bad implementations देखे हैं:

  1. कोई signature नहीं, raw POST
  2. Signature है लेकिन secret query string में
  3. Signature है लेकिन MD5 use कर रहे
  4. Signature है लेकिन timestamp नहीं, replay attack possible

Proper webhook requirements:

  • HMAC-SHA256 signature in X-Signature header
  • X-Timestamp included, reject requests older than 5 minutes
  • Auto retry on failure (exponential backoff, minimum 3 attempts)
  • Dead letter queue या replay API available

Webhook verify करने का Go code:

func verifyWebhook(body []byte, sig, ts, secret string) bool {
    if time.Since(parseTS(ts)) > 5*time.Minute {
        return false
    }
    mac := hmac.New(sha256.New, []byte(secret))
    mac.Write([]byte(ts + "." + string(body)))
    expected := hex.EncodeToString(mac.Sum(nil))
    return hmac.Equal([]byte(sig), []byte(expected))
}

Timestamp check हटा दो तो replay attack से पूरा event system compromise हो जाता है।

Rate Limit: दो Layers में समझो

Rate limit दो level पर देखो: तुम्हारा quota कितना है, और quota exceed होने पर क्या होगा।

Quota negotiable है, mostly per-second / per-minute plan में लिखा होता है। असली important चीज़ exceed behavior है:

Behavior Rating
Direct 503 disconnect Fail
429 without Retry-After Partial
429 + Retry-After header Pass
429 + Retry-After + quota header Excellent

Bonus point: X-RateLimit-Remaining जैसे headers provide करना, ताकि तुम proactively throttle कर सको instead of passively getting 429s।

SLA: Numbers के Peeche का Sach

सब लिखते हैं 99.9%। 99.9% means हर month 43.2 minutes downtime, 99.95% means 21.6 minutes, 99.99% means 4.3 minutes।

लेकिन SLA की real value उस number में नहीं, exclusion clause में है:

  • Planned maintenance downtime में count होता है?
  • Regional outage count होता है?
  • DDoS attack के दौरान count होता है?
  • Third-party dependency (upstream DNS etc.) count होता है?

और भी important: service credit mechanism। SLA miss होने पर कितना refund? Account credit या cash? Credit accumulate होता है या expire?

Honestly, ज़्यादातर SLAs paper पर अच्छे लगते हैं, actual claim करते वक़्त exclusion clauses block कर देती हैं। इसलिए procurement में percentage देखने के बजाय past 12 months की actual incident history माँगो — ये NDA के under provide करवा सकते हो।

Egress Billing: Budget का Black Hole

Egress (outbound traffic) image hosting में budget blow करने का #1 reason है। Vendors का favourite trick: storage सस्ता रखो, egress महँगा करो।

Data देखो तो major vendors के egress pricing में 10x+ difference हो सकता है। Cloudflare R2 zero egress देता है (अपने network में), Cloudinary credit model पर चलता है, imgix per-request charge करता है। कौन सा सस्ता पड़ेगा वो तुम्हारे traffic pattern पर depend करता है।

Procurement से पहले तीन चीज़ें ज़रूर पूछो:

  1. Tier-based volume discounts हैं? Usually 10TB/month से ऊपर significant discount मिलता है
  2. Cross-region internal traffic egress में count होता है?
  3. CDN cache hits egress में count होते हैं? कुछ vendors CDN hits को भी traffic में गिनते हैं

मैं इसमें फँसा था: test environment में 200GB/month — कोई issue नहीं। Production में launch होते ही 8TB तक पहुँच गया, bill में एक extra zero आ गया। Contract sign करने से पहले overage behavior नहीं पूछा था, उस month directly budget exceed।

अक्सर Ignore होने वाले तीन Specs

ये तीन items typical "image hosting comparison tables" में नहीं मिलते, लेकिन real usage में pain देते हैं।

EXIF और Metadata: WhatsApp Forward से लेकर Compliance तक

EXIF में GPS coordinates, camera serial number, shooting time होता है। Public image hosting पर upload करो तो ये सब data by default चला जाता है।

B2B context में पूछो:

  • Selective EXIF removal possible है? (सिर्फ GPS हटाओ, copyright info रखो)
  • IPTC / XMP metadata operations support हैं?
  • Metadata processing upload time पर होता है या on-the-fly?

GDPR और India का DPDP Act 2023 दोनों GPS data को personal data मानते हैं। Properly handle नहीं किया तो compliance risk directly तुम्हारी company पर आता है। WhatsApp पर जो images share होती हैं, उनमें भी EXIF data होता है — ये India context में especially relevant है।

OAuth2 + API Key: Mixed Authentication

Purane image hosting services सिर्फ API Key देते थे। Modern B2B requirement mixed approach माँगता है:

  • Internal system-to-system: API Key + IP allowlist
  • User-facing SPA: OAuth2 PKCE flow
  • Temporary access: Pre-signed URL

अगर vendor सिर्फ एक permanent API Key दे रहा है और scope management तुम पर छोड़ रहा है, तो वो security risk तुम पर transfer कर रहा है। Proper solution में scoped tokens, automatic rotation, और revocation API होनी चाहिए।

Hard Delete और Data Retention

GDPR "right to be forgotten" 30 days में execute होना चाहिए। DPDP Act 2023 में भी similar provision है। बहुत सारे image hosting services कहते हैं "हम delete कर देंगे," actual में soft delete होता है — object S3 में पड़ा रहता है, CDN cache में रहता है, backup tapes में रहता है।

Procurement में confirm करो:

  1. Deletion DPA (Data Processing Agreement) में mentioned है?
  2. Backup cycle में corresponding delete mechanism है?
  3. Deletion proof provide कर सकते हैं?

मेरे साथ real case हुआ: client को GDPR deletion request मिला, vendor का cold storage backup 365 days retain करता था और modify नहीं हो सकता था। Legal back-and-forth तीन months चला।

lpic.cc की Position

Honestly बताऊं: lpic.cc अभी B2B enterprise-grade solution नहीं है।

हमारी positioning individual developers, bloggers, और forum sharing scenarios के लिए है — free upload, password protection, 30-day retention। Backend क्लाउड ऑब्जेक्ट स्टोरेज + custom API पर built है, architecture में इस article की कई specs use होती हैं (pre-signed URL, webhook, EXIF processing), लेकिन enterprise SLA नहीं है, SOC 2 certification नहीं है, DPA भी नहीं।

अगर तुम technical lead हो और production-grade image hosting ढूंढ रहे हो, तो ये checklist लेकर Cloudinary, imgix, Cloudflare Images, ImageKit evaluate करो। अगर personal या small team use के लिए lightweight solution चाहिए, तो lpic.cc try करो — free upload करके देखो और decide करो।

FAQ

Q1: छोटी team को enterprise-grade image hosting चाहिए?

ज़रूरी नहीं। Monthly active users 10K से कम, traffic 500GB/month से कम हो, तो Cloudflare R2 + Workers से खुद build करो — cost $5/month से नीचे रख सकते हो। Enterprise solution की value SLA, compliance, support SLA में है, छोटी team को शायद ज़रूरत नहीं। लेकिन अगर तुम B2B clients serve करते हो और client contract में DPA requirement है, तो कोई option नहीं।

Q2: S3 compatibility really matter करती है?

बहुत। S3 API de facto standard है — support मतलब तुम mature SDKs, Terraform providers, backup tools use कर सकते हो। Support नहीं मतलब vendor की proprietary API में lock-in। ये classic vendor lock-in indicator है।

Q3: Webhook vs Polling — Webhook ज़रूरी क्यों?

Polling में तुम हर N seconds पूछते हो "done yet?", webhook में vendor complete होने पर push करता है। Difference: latency (seconds vs milliseconds) और cost (तुम्हारे API call quota vs zero cost)। Upload completion, transcoding, virus scan जैसे events में webhook बिना real-time UX possible नहीं।

Q4: SLA 99.9% और 99.99% में इतना फ़र्क?

Numbers में 43 minutes vs 4 minutes per month। Real impact तुम्हारे business पर depend करता है। E-commerce checkout flow में product images के लिए हर minute revenue loss है; internal employee handbook images के लिए 99.9% या 99% भी काफ़ी है। SLA requirement को actual business impact से align करो, blindly higher number मत chase करो।

Q5: Cloudflare R2 का zero egress — बस वही choose करो?

नहीं। R2 का zero egress Cloudflare network के अंदर limited है (Workers या CDN through)। दूसरे cloud से data pull करोगे तो charge लगेगा। Plus R2 के Class A operations (write-type) की per-unit price ज़्यादा है, write-heavy read-light scenarios में necessarily सस्ता नहीं। Total cost calculate करो अपने read/write ratio के basis पर।

References

#Image Hosting API#S3 Compatible#SLA#CDN#Webhook#Enterprise Procurement#DevOps#Signed URL#India IT Act
H

लेखक

Harvey Zhang

सह-संस्थापक और CTO

Backend इंजीनियर और सिस्टम आर्किटेक्ट