నాలెడ్జ్ బేస్

HostBill, Blesta లేదా మీ స్వంత సిస్టమ్ నుండి Zinn® హోస్టింగ్‌ను విక్రయించండి

HostBill, Blesta లేదా మీ స్వంత సిస్టమ్ నుండి Zinn® హోస్టింగ్‌ను విక్రయించండి: ఉచిత HostBill మాడ్యూల్, సింగిల్-ఫైల్ PHP క్లయింట్, ఉల్లంఘించినప్పుడు ఖర్చుతో కూడుకున్న రెండు నియమాలు మరియు వదిలివేయడానికి సులభమైన రెండు అభ్యర్థన ఫీల్డ్‌లు.

మీరు WHMCSను రన్ చేస్తుంటే, బదులుగా WHMCS మాడ్యూల్ను ఉపయోగించండి — ఈ పేజీ మిగిలిన అన్నింటి కొరకు ఉద్దేశించబడింది. రెండు ఎంపికలు ఉన్నాయి, రెండూ ఉచితం మరియు రెండూ GPL-2.0-or-later.

HostBill

WHMCS మాడ్యూల్‌లో ఉండే అదే ఆరు చర్యలను కలిగి ఉన్న హోస్టింగ్ మాడ్యూల్.

  1. దీన్ని డౌన్‌లోడ్ చేసుకోండి మరియు అన్-జిప్ చేయండి.
  2. zinn డైరెక్టరీని includes/modules/Hosting/ లోకి అప్‌లోడ్ చేయండి, తద్వారా ఫైళ్లు includes/modules/Hosting/zinn/class.zinn.php మరియు includes/modules/Hosting/zinn/ZinnHostBillClient.php వద్దకు చేరతాయి.
  3. Settings → Modules → Hosting కు వెళ్లి, Zinn Digital® ను సక్రియం చేయండి మరియు ఒక కనెక్షన్‌ను జోడించండి:
  • API address: https://api.zinndigital.com
  • API key: మీ Zinn® API కీ (ఇది ఒక password ఫీల్డ్, కాబట్టి HostBill దీనిని ఎన్‌క్రిప్ట్ చేసి నిల్వ చేస్తుంది)
  1. ప్రోడక్ట్‌పై Product line (ఉదా. mainstream), Stack (డిఫాల్ట్‌గా wordpress), మరియు ఐచ్ఛికంగా Application మరియు PHP version లను సెట్ చేయండి.
  2. Test connection ను నొక్కండి.

⛔ zinn డైరెక్టరీ పేరును మార్చవద్దు. HostBill యొక్క లోడర్ డైరెక్టరీ పేరు నుండి తాను వెతికే క్లాస్‌ను గ్రహిస్తుంది, కాబట్టి పేరు మారిస్తే ప్యానెల్ జాబితా చేసే మరియు ఎన్నడూ కాల్ చేయని మాడ్యూల్ తయారవుతుంది.

మరేదైనా — PHP క్లయింట్

ఒకే ఫైల్, ఎటువంటి డిపెండెన్సీలు లేవు, ప్యానెల్ ఊహలు లేవు. మీ స్వంత కోడ్‌బేస్‌లోకి ZinnProvisioning.php ను చేర్చి ఆరు మెథడ్స్‌ను కాల్ చేయండి.

require_once 'ZinnProvisioning.php';

$zinn = new ZinnProvisioning(getenv('ZINN_API_KEY'));

// When an order is paid — once per CUSTOMER, then once per SERVICE:
$orgId  = $zinn->account('customer-4211', 'Acme Ltd');
siteId = $zinn->provision('service-9915', $orgId, 'acme.com', 'mainstream', 'wordpress');
// Store $orgId against your customer and $siteId against your service.

$zinn->suspend($siteId, 'INV-2026-114 unpaid');   // an invoice goes unpaid
$zinn->unsuspend($siteId);                        // they pay
$zinn->terminate($siteId);                        // they cancel — schedules a deletion

// When they click "log in to my hosting" — mint it on the CLICK, never on page render:
header('Location: ' . $zinn->signInLink($siteId));

PHP రాయడం లేదా? అవే కాల్‌లు API reference లో ఉన్నాయి మరియు మీరు వాటిని దేని నుంచైనా చేయవచ్చు.

API కీ

ఏడు అనుమతులు, అంతకు మించి ఏమీ లేవు: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ reseller.manage కాదు. బిల్లింగ్ ప్యానెల్‌లో మీరు పేస్ట్ చేసే కీ చెల్లింపు చేయనందుకు క్లయింట్‌ను హోల్డ్‌లో ఉంచగలగాలి మరియు వారిని సైన్ ఇన్ చేయగలగాలి; అది మీ స్వంత పేమెంట్-గేట్‌వే ఆధారాలను తిరిగి రాయగలగకూడదు.

ఉల్లంఘించినప్పుడు ఖర్చుతో కూడుకున్న రెండు నియమాలు

  1. మీ ఖాతాను CUSTOMER పై, మరియు సైట్‌ను మీ SERVICE పై కీ చేయండి. కస్టమర్ యొక్క రెండవ ఆర్డర్ ఇప్పటికే వారికి ఉన్న ఖాతాలోకి చేరాలి. రెండింటినీ సర్వీస్‌పై కీ చేస్తే ఒకే కస్టమర్ సంబంధం లేని మూడు ఖాతాలను మరియు మూడు వేర్వేరు కంట్రోల్ ప్యానెల్‌లను కలిగి ఉండే పరిస్థితి ఏర్పడుతుంది.
  2. ప్రతి క్రియేట్‌పై ఆ వస్తువు కోసం మీ స్వంత id నుండి ఉత్పన్నమైన ఐడెంపోటెన్సీ కీని పంపండి. ప్రతి బిల్లింగ్ సిస్టమ్ మళ్లీ ప్రయత్నిస్తుంది — గేట్‌వే కాల్‌బ్యాక్ రెండుసార్లు వస్తుంది, అడ్మిన్ విఫలమైన ప్రొవిజన్‌ను మళ్లీ రన్ చేస్తారు, కస్టమర్ డబుల్-క్లిక్ చేస్తారు. ఇది లేకుండా రెండవ ప్రయత్నం రెండవ సైట్‌ను సృష్టిస్తుంది మరియు దానికి మీకే బిల్లు పడుతుంది. రెండు మాడ్యూళ్లు మరియు PHP క్లయింట్ మీ కోసం దీన్ని చేస్తాయి; మీరు నేరుగా API ని కాల్ చేస్తుంటే, Idempotency-Key ని పంపండి.

సులభంగా విస్మరించబడే మూడు ఫీల్డ్‌లు

ప్రతి ఒక్కటి ఒక పూర్తి వెర్బ్‌ను విచ్ఛిన్నం చేస్తుంది, మరియు మొదటిది మినహా ఏదీ ధృవీకరణ లోపం తప్ప మరేమీ చూపించదు — మొదటిది ఏమీ చూపించదు:

  • ⛔⛔ క్లయింట్ యొక్క మొదటి సైట్ ప్రొవిజన్ చేయబడటానికి ముందే వారు ఒక ప్లాన్‌లో ఉంచబడాలి, దీని కోసం POST /v1/reseller/clients/{orgId}/plan ఉపయోగించబడుతుంది, మరియు దాని subscription_id POST /v1/sites కు పంపబడుతుంది. ఇందులో చదవడానికి ఎటువంటి ఎర్రర్ ఉండదు. కొత్త క్లయింట్ ఖాతాలో ఎటువంటి సబ్‌స్క్రిప్షన్ ఉండదు మరియు POST /v1/sites లో ప్లాన్ ఫీల్డ్ ఉండదు, కాబట్టి ఏదీ లేకుండా ప్రొవిజన్ చేయబడిన సైట్ ఎటువంటి ప్లాన్‌ను కలిగి ఉండదు: మీ హోల్‌సేల్ స్టేట్‌మెంట్ మీ క్లయింట్ల లైవ్ సబ్‌స్క్రిప్షన్‌ల నుండి రూపొందించబడుతుంది, కాబట్టి ఏ లైన్ జోడించబడదు మరియు హోస్టింగ్ నడుస్తున్నంత కాలం Zinn® మీ నుండి ఏమీ బిల్ చేయదు; మీ క్లయింట్‌కు ఎటువంటి అలవెన్సులు లభించవు, కాబట్టి వారి సైట్‌కు ఎటువంటి కోటా వర్తించదు; మరియు అప్‌గ్రేడ్ మార్చడానికి ఏమీ ఉండదు. ఆర్డర్ 201 ని అందిస్తుంది, సైట్ ప్రొవిజన్ అవుతుంది, మరియు అది సరిగ్గా పని చేస్తుంది. ఏ వైపు కూడా దీని గురించి ఏమీ నివేదించదు.

క్రమం ముఖ్యం: POST /v1/sites రన్ అయ్యే సమయానికి ఏ సబ్‌స్క్రిప్షన్ ఉంటే దానిని రికార్డ్ చేస్తుంది, కాబట్టి తర్వాత సెట్ చేయబడిన ప్లాన్ మునుపటి దానికి వర్తించదు.

  • POST /v1/sites కు stack_type అవసరం. దానిని విస్మరిస్తే ఏ ఆర్డర్ కూడా విజయవంతం కాదు.
  • DELETE /v1/sites/{siteId} కు {"confirm_domain": "<the site's own domain>"} అనే బాడీ అవసరం — ఇది టైప్ చేసిన నిర్ధారణ, ఎందుకంటే ఇది వినాశకరమైన చర్య. దానిని విస్మరిస్తే ఏ రద్దు కూడా విజయవంతం కాదు, కాబట్టి సర్వీస్ నడుస్తూనే ఉంటుంది మరియు మీరు దాని కోసం బిల్ చేయబడుతూనే ఉంటారు. మీ స్వంత రికార్డును ఉపయోగించకుండా GET /v1/reseller/services/{siteId} నుండి డొమైన్‌ను తిరిగి చదవండి: ఇది సైట్ యొక్క స్వంత ప్రాథమిక డొమైన్‌తో పోల్చబడుతుంది మరియు ఎలియాస్‌తో ఎప్పుడూ పోల్చబడదు.

కేవలం వాక్యాన్ని మాత్రమే కాకుండా, పూర్తి ఎర్రర్‌ను చదవండి

ధ్రువీకరణ నిరాకరణ సందేశం ఉద్దేశపూర్వకంగా సాధారణమైనదిగా ఉంటుంది — "The request was well-formed but failed validation." — ఎందుకంటే చర్య తీసుకోదగిన భాగం details లో ఉంటుంది, ఇది ఫీల్డ్ మరియు కారణాన్ని పేర్కొంటుంది. రెండు మాడ్యూల్స్ మరియు PHP క్లయింట్ మీ అడ్మిన్‌కు చూపించే సందేశానికి దీనిని జోడిస్తాయి. మీరు స్వయంగా API ని కాల్ చేస్తుంటే, error.details ని చదవండి; కొన్ని ఎంట్రీలు వాక్యానికి బదులుగా కేవలం విలువను కలిగి ఉంటాయి, మీ రీసెల్లర్ ప్లాన్‌లో ఖాళీ లేనప్పుడు max_sites: 0 మీకు ఈ విధంగానే చేరుతుంది.

మీ మొదటి ఆర్డర్‌కు ముందు

మీ క్లయింట్లు కొనుగోలు చేసే సైట్‌లు మీ రీసెల్లర్ ప్లాన్ యొక్క సైట్ అలవెన్స్‌కు వ్యతిరేకంగా లెక్కించబడతాయి, కాబట్టి మీకు అందులో ఖాళీ ఉన్న ప్లాన్ అవసరం. కనెక్షన్ పరీక్ష దీనిని గుర్తించలేదు — ఇది మీ ప్రోగ్రామ్‌ను చదువుతుంది మరియు దేనినీ ప్రొవిజన్ చేయదు — కాబట్టి ఇది ఇంకా విక్రయించలేని ఆరోగ్యకరమైన ఖాతాను నివేదిస్తుంది. అలవెన్స్ లేకుండా చేసిన ఆర్డర్ ఖచ్చితంగా ఆ విషయాన్ని తెలిపే సందేశంతో నిరాకరించబడుతుంది.

మీ డౌన్‌లోడ్‌ను ధృవీకరించండి

రెండు ఆర్కైవ్‌లు మా స్వంత హోస్ట్‌నేమ్ నుండి TLS ద్వారా అందించబడతాయి, మరెక్కడికీ దారి మళ్లించబడవు, వాటి SHA-256 చెక్‌సమ్‌లు డౌన్‌లోడ్‌ల పేజీ లో డౌన్‌లోడ్ లింక్‌ల పక్కన ముద్రించబడి ఉంటాయి.

బ్లాగ్ నుండి తాజావి

హోస్టింగ్, SEO మరియు భారీ స్థాయిలో సైట్‌లను నిర్వహించడం గురించి మేము రాసినవి.

హోస్టింగ్ లేయర్ నుండి ఎస్ఈఓ మరియు లింక్ బిల్డింగ్: 2026 ఆపరేటర్ దృక్కోణం

2026లో హోస్టింగ్ అనేది ఇండెక్సింగ్ మరియు లింక్ ఈక్విటీని ఎలా రూపొందిస్తుంది: పేజీలను ఇండెక్స్‌లో ఉంచడం, పాత డొమైన్‌లపై పని ప్రారంభించడానికి ముందే వాటిని పరిశీలించడం, ఎటువంటి ఆధారాలు (footprint) లేకుండా లింక్ బిల్డింగ్ చేయడం, మరియు SEO కోసం మౌలిక సదుపాయాలు ఏమి చేయగలవు మరియు ఏమి చేయలేవు అనేదానిపై ఒక నిజాయితీపూర్వక విశ్లేషణ.

పోస్ట్‌ను చదవండి →

WordPress ను వేగవంతంగా మరియు సురక్షితంగా మార్చడం: పనితీరు మరియు ప్లగిన్ చెక్‌లిస్ట్

వేగవంతమైన, సురక్షితమైన WordPress కోసం ఒక ఆచరణాత్మక చెక్‌లిస్ట్: సర్వర్-స్థాయి కాషింగ్, సైట్ వారీగా ఆబ్జెక్ట్ కాష్, ఉపయోగించదగిన కొన్ని ప్లగిన్లు, స్టాక్‌ను తాజాగా ఉంచడం మరియు మీరు ఎప్పటికీ కాష్ చేయకూడని WooCommerce పేజీలు.

పోస్ట్‌ను చదవండి →

2026లో నిర్వహించబడే వెబ్ హోస్టింగ్‌ను ఎలా ఎంచుకోవాలి: కొనుగోలుదారు గైడ్

కంట్రోల్ ప్యానెల్‌తో కూడిన చౌకైన సర్వర్ నుండి మంచి నిర్వహించబడే హోస్టింగ్‌ను వాస్తవంగా ఏది వేరు చేస్తుంది — మైగ్రేషన్‌లు, బ్యాకప్‌లు, ఐసోలేషన్, నిజమైన కాషింగ్ మరియు నిజాయితీతో కూడిన స్కేలింగ్ — మరియు మీరు నిబద్ధత వ్యక్తం చేయడానికి ముందు దానిని ఎలా అంచనా వేయాలి.

పోస్ట్‌ను చదవండి →

బ్లాగు చదవండి →

ఇంకా సమస్య ఉందా?

ప్రతి ప్లాన్‌లోనూ మద్దతు (సపోర్ట్) అందించబడుతుంది, సహాయ కేంద్రం రోజులో 24 గంటలూ అందుబాటులో ఉంటుంది మరియు మీరు మా 58 భాషలలో దేనిలోనైనా మాకు రాయవచ్చు — మేము మీ సొంత భాషలోనే మీకు సమాధానం ఇస్తాము.

సహాయాన్ని సంప్రదించండి → అన్ని కథనాలు →