Scoutello API

Scoutello API एक सर्वर-टू-सर्वर API है, जो किसी संगठन के संपर्कों, कार्यों, प्रोटोकॉल, अवसरों, प्रोजेक्ट, माइलस्टोन और इवेंट को दोनों दिशाओं में सिंक्रोनाइज़ करता है। यह केवल-पठन योग्य आउटबाउंड मेल इतिहास, असाइन किए जा सकने वाले सदस्यों की खोज और इकाई-आधारित टैग खोज भी उपलब्ध कराता है। इस संस्करण में इंक्रीमेंटल GET/list रूट और इडेम्पोटेंट बैच अपसर्ट सिंक्रोनाइज़ेशन के मूल साधन हैं। इसमें डिलीट ऑपरेशन या वेबहुक उपलब्ध नहीं हैं।

API का बेस URL है:

https://admin.scoutello.com/api/v1

यह Organization settings → Developer/API में भी दिखता है। OpenAPI दस्तावेज़ यहां उपलब्ध है:

https://admin.scoutello.com/api/v1/openapi.json

कुंजी बनाना और सुरक्षित रखना

मॉड्यूलर संगठनों के लिए, कुंजी के आवश्यक स्कोप के अतिरिक्त CRM मॉड्यूल सक्रिय होना चाहिए। मान्य कुंजी किसी अनुपलब्ध मॉड्यूल को सक्रिय नहीं कर सकती। CRM एक्सेस उपलब्ध न होने पर अनुरोध HTTP 403 और त्रुटि कोड module_not_active लौटाते हैं। संगठन के प्रशासक सदस्यता में CRM की समीक्षा कर सकते हैं या उसे सक्रिय कर सकते हैं; एक्सेस सक्रिय होने के बाद पुनः प्रयास करें।

संगठन प्रशासन Organization settings → Developer/API में इंटीग्रेशन और API कुंजी बना सकता है। पूरी कुंजी केवल एक बार दिखाई जाती है। डायलॉग बंद करने से पहले इसे किसी सीक्रेट मैनेजर में कॉपी करें; Scoutello पूरी कुंजी दोबारा प्रदर्शित नहीं कर सकता।

प्रत्येक बाहरी सिस्टम और एनवायरनमेंट के लिए अलग इंटीग्रेशन और कुंजी का उपयोग करें।
उस सिस्टम के लिए आवश्यक स्कोप ही दें।
कुंजी को ब्राउज़र कोड, URL, सोर्स कंट्रोल, लॉग, सहायता संदेशों या क्लाइंट-साइड स्टोरेज में कभी न रखें।
कुंजियों को निर्धारित अंतराल पर बदलें। सक्रिय इंटीग्रेशन की कुंजी बदलने पर नई कुंजी तुरंत काम करती है और पिछली कुंजी अधिकतम 15 मिनट तक मान्य रहती है, ताकि बाहरी सिस्टम बिना रुकावट के स्विच कर सके। पहले से निर्धारित समाप्ति लागू रहती है, इसलिए पिछली कुंजी इससे पहले भी काम करना बंद कर सकती है।
यदि कुंजी के उजागर होने की आशंका हो, तो उसे बदलने से पहले इंटीग्रेशन को रोक दें। रोकने पर इंटीग्रेशन की सभी कुंजियां अस्थायी रूप से अस्वीकार कर दी जाती हैं। रुकी हुई स्थिति में कुंजी बदलने पर कोई ओवरलैप नहीं होता: पिछली कुंजी निष्क्रिय रहती है और इंटीग्रेशन फिर से शुरू होने तक नई कुंजी भी निष्क्रिय रहती है।
बाहरी सिस्टम डिस्कनेक्ट करते समय पूरे इंटीग्रेशन को स्थायी रूप से रद्द करें। रद्द करने से उसकी सभी कुंजियां निष्क्रिय हो जाती हैं और इसे वापस नहीं किया जा सकता।

प्रमाणीकरण वाले प्रत्येक अनुरोध में कुंजी भेजें:

Authorization: Bearer YOUR_API_KEY

Bearer प्रमाणीकरण को प्राथमिकता दी जाती है। जो क्लाइंट Authorization सेट नहीं कर सकते, वे इसके बजाय x-api-key का उपयोग कर सकते हैं। दोनों हेडर न भेजें; दोनों हेडर में अलग-अलग मान होने पर अनुरोध अस्वीकार कर दिए जाते हैं।

API बैकएंड क्लाइंट के लिए है और क्रॉस-ऑरिजिन ब्राउज़र एक्सेस सक्षम नहीं करता।

कुंजी कॉन्फ़िगर करने के बाद GET /whoami का उपयोग करके उपयोगकर्ता का व्यक्तिगत डेटा प्राप्त किए बिना इंटीग्रेशन, संगठन, स्कोप और कुंजी सीमाओं की पुष्टि करें।

स्कोप

दायरा	अनुमतियाँ
`contacts.read`	संपर्कों की सूची बनाना और उन्हें प्राप्त करना। संगठन-खाते और एक्सेस वाले सदस्य संपर्क शामिल नहीं किए जाते।
`contacts.write`	संपर्क अपसर्ट को मान्य करना और लागू करना।
`tasks.read`	गैर-निजी कार्यों की सूची बनाना और उन्हें प्राप्त करना।
`tasks.write`	कार्य अपसर्ट को मान्य करना और लागू करना।
`protocols.read`	गैर-निजी प्रोटोकॉल की सूची बनाना और उन्हें प्राप्त करना।
`protocols.write`	प्रोटोकॉल अपसर्ट को मान्य करना और लागू करना।
`opportunities.read`	अवसरों की सूची बनाना और उन्हें प्राप्त करना।
`opportunities.write`	अवसर अपसर्ट को मान्य करना और लागू करना।
`projects.read`	प्रोजेक्ट की सूची बनाना और उन्हें प्राप्त करना।
`projects.write`	प्रोजेक्ट और प्रतिभागी अपसर्ट को मान्य करना और लागू करना।
`milestones.read`	प्रोजेक्ट माइलस्टोन की सूची बनाना और उन्हें प्राप्त करना।
`milestones.write`	माइलस्टोन अपसर्ट को मान्य करना और लागू करना।
`members.read`	केवल सदस्य Customer ID, User ID और प्रदर्शन नाम वाले स्वीकृत सदस्यों की सूची बनाना।
`events.read`	इवेंट और मुख्य शेड्यूल की सूची बनाना और उन्हें प्राप्त करना।
`events.write`	इवेंट अपसर्ट को मान्य करना और लागू करना।
`mails.read`	संगठन के स्वामित्व वाले भेजे गए और विफल आउटबाउंड मेल के इतिहास को पढ़ना।
`mail-drafts.read`	इस इंटीग्रेशन के स्टैंडअलोन ईमेल अनुमोदन ड्राफ़्ट और डिलीवरी स्थिति को पढ़ना।
`mail-drafts.write`	मानव अनुमोदन के लिए ईमेल ड्राफ़्ट तैयार करना या संशोधित करना; कभी अनुमोदन या भेजना नहीं।
`tags.read`	समर्थित इकाई प्रकारों के लिए चुने जा सकने वाले टैग ढूँढना।

इस API द्वारा निजी कार्य और प्रोटोकॉल कभी वापस नहीं किए जाते। किसी स्कोप के न होने पर प्राधिकरण त्रुटि लौटती है; इसे खाली परिणाम नहीं माना जाता।

किसी गैर-सदस्य CRM संपर्क को तब भी पढ़ा और संदर्भित किया जा सकता है, जब वह Scoutello लॉगिन से लिंक हो। प्रतिक्रिया में केवल संगठन के CRM फ़ील्ड होते हैं; User की पहचान या एक्सेस फ़ील्ड कभी शामिल नहीं होतीं। भूमिका, अनुमतियाँ, आमंत्रण, स्वीकृति या संगठन-खाता स्थिति वाले संपर्क छिपे रहते हैं। लॉगिन से लिंक संपर्क का संपादन प्रतिबंधित रहता है (protected_contact), इसमें ऐसे CRM फ़ील्ड भी शामिल हैं जो अन्यथा अपरिवर्तित हों। किसी कार्य/प्रोटोकॉल से मौजूदा पठनीय संपर्क को संदर्भित करने के लिए contacts.write केवल externalId, scoutelloId और वैकल्पिक externalUpdatedAt के साथ उसका बाहरी लिंक स्थापित कर सकता है। बाद में केवल लिंक मेटाडेटा के अपडेट के लिए externalId और वैकल्पिक externalUpdatedAt का उपयोग करें; लिंक हो जाने के बाद बूटस्ट्रैप scoutelloId को छोड़ दें। इससे संपर्क या उसके User में कोई बदलाव नहीं होता। स्वीकृत सदस्य का असाइनमेंट अलग members.read प्रोजेक्शन का उपयोग करता है।

नई कुंजियाँ sctl_api_ प्रीफ़िक्स का उपयोग करती हैं और केवल contacts.write से शुरू होती हैं। अन्य सभी स्कोप स्पष्ट रूप से ऑप्ट-इन हैं, जिन्हें कुंजी बनाते या रोटेट करते समय संगठन के प्रशासनिक अधिकारों वाले व्यक्ति को प्रदान करना आवश्यक है। मौजूदा क्रेडेंशियल अपने वर्तमान स्कोप बनाए रखते हैं और मान्य रहते हैं।

प्रोजेक्ट से जुड़े संपर्क और ईमेल ड्राफ़्ट

संपर्क अपसर्ट में वैकल्पिक projectScoutelloId / projectExternalId और companyScoutelloId / companyExternalId युग्म स्वीकार किए जाते हैं (प्रत्येक युग्म में से एक चुनें)। प्रत्येक आइटम के लिए संपर्क, कंपनी संबंध और प्रोजेक्ट सदस्यता को एक साथ एटॉमिक रूप से सहेजा जाता है। प्रोजेक्ट सदस्यता जोड़ने के लिए projects.write आवश्यक है; संदर्भ छोड़ देने पर अन्य संबंध और सदस्यताएँ बनी रहती हैं। संपर्क विवरण के रीडबैक में projectParticipations शामिल होता है, जब projects.read प्रदान किया गया हो। बिक्री-प्रोजेक्ट एजेंट को संपर्क का पुनः उपयोग करने पर भी प्रोजेक्ट संदर्भ स्पष्ट रूप से शामिल करना आवश्यक है।

स्टैंडअलोन ड्राफ़्ट बिना वर्कफ़्लो रन के मौजूदा मानव अनुमोदन प्रणाली का उपयोग करते हैं:

विधि	पथ	उद्देश्य
GET	`/mail-drafts`	इंटीग्रेशन-स्वामित्व वाले पृष्ठांकित ड्राफ़्ट; वैकल्पिक `projectScoutelloId` और `status` फ़िल्टर।
GET	`/mail-drafts/{scoutelloId}`	वर्तमान संस्करण, समीक्षा लिंक, सामग्री हैश, अनुमोदन/भेजने की स्थिति और उपलब्ध होने पर मेल आईडी।
GET	`/mail-drafts/external/{externalId}`	स्थिर इंटीग्रेशन बाहरी आईडी खोजना।
POST	`/mail-drafts/batch-upsert`	ड्राफ़्ट की तैयारी को सत्यापित या लागू करना।

ड्राफ़्ट की तैयारी के लिए mail-drafts.write, contacts.read और projects.write आवश्यक हैं। संदर्भित संपर्क प्रोजेक्ट प्रतिभागी बन जाता है। अनुमोदक ऐसा स्वीकृत संगठन सदस्य होना चाहिए जिसके पास ईमेल संपादित करने की अनुमति हो। प्रेषक का चयन उस सदस्य की मौजूदा अनुमत संगठन या व्यक्तिगत प्रेषक सेटिंग से किया जाता है; मनमाने From पते स्वीकार नहीं किए जाते।

{
  "mode": "validate",
  "records": [{
    "externalId": "sales:indoor:outreach:museum:v1",
    "expectedVersion": 0,
    "project": { "externalId": "sales:indoor" },
    "contact": { "externalId": "sales:indoor:museum:person" },
    "approverScoutelloUserId": "ACCEPTED_MEMBER_USER_ID",
    "senderScope": "organization",
    "content": {
      "to": ["verified-recipient@example.com"],
      "subject": "Indoor tour proposal",
      "body": "The intended email copy only.",
      "notes": "Internal research and review context; not sent."
    }
  }]
}

mode: "apply" के साथ दोबारा प्रयास करने से पहले हर सत्यापन परिणाम की जाँच करें। परिणामी आईडी पढ़कर reviewUrl, draftVersion, contentHash, status, dispatchStatus और mailScoutelloId प्राप्त करें। expectedVersion: 0 का उपयोग केवल निर्माण के लिए करें और संशोधनों के लिए लौटाए गए वर्तमान संस्करण का उपयोग करें। संदर्भ और अनुमोदक अपरिवर्तनीय हैं; समीक्षा किए गए/भेजे गए ड्राफ़्ट बदली हुई सामग्री को अस्वीकार करते हैं। समान दोबारा किए गए अनुरोध मूल ड्राफ़्ट लौटाते हैं।

ड्राफ़्ट प्रोजेक्ट और संपर्क के ईमेल टैब तथा डैशबोर्ड की अनुमोदन सूचनाओं में दिखाई देते हैं। API से तैयारी करने पर कोई ईमेल नहीं भेजा जाता, सूचना देने वाला ईमेल भी नहीं; वर्कफ़्लो के सूचना-ईमेल का मौजूदा व्यवहार अपरिवर्तित रहता है। असाइन किया गया व्यक्ति प्राप्तकर्ता, विषय, मुख्य पाठ और समर्थित अटैचमेंट संपादित कर सकता है, संस्करण सहेज सकता है और फिर अनुमोदन करके भेजें चुन सकता है। एकीकरण अनुमोदन या प्रेषण नहीं कर सकते। विफल या अस्पष्ट डिलीवरी को बिना जाँच के दोबारा कभी न भेजें। प्रोटोकॉल पर आधारित पुराने ड्राफ़्ट बदलते समय मूल प्रोटोकॉल बनाए रखें और उनकी जगह तैयार किए गए रिकॉर्ड के संदर्भ जोड़ें।

MCP तक पहुँच

स्ट्रीम करने योग्य HTTP MCP एंडपॉइंट के साथ वही Scoutello API कुंजी और स्कोप उपयोग किए जा सकते हैं:

https://admin.scoutello.com/api/v1/mcp

MCP क्लाइंट को Authorization: Bearer YOUR_API_KEY भेजने के लिए कॉन्फ़िगर करें। पुराना /api/mcp URL संगतता के लिए वैकल्पिक पथ बना रहता है, लेकिन नए क्लाइंट को संस्करण वाला एंडपॉइंट उपयोग करना चाहिए। पुरानी sctl_mcp_ कुंजियाँ स्वीकार नहीं की जातीं; उन्हें Scoutello API एकीकरण कुंजी से बदलें।

MCP टूल सीधे REST के डेटा अनुबंध से जुड़े हैं और वही रनटाइम स्कीमा, संगठन की जाँच, एकीकरण का जीवनचक्र, अनुरोध सीमा और सेवा विधियाँ उपयोग करते हैं। उदाहरण के लिए, contacts_list, contacts_get, contacts_get_by_external_id और contacts_batch_upsert संपर्क के चार रूट के अनुरूप हैं। कार्यों, प्रोटोकॉल, अवसरों, प्रोजेक्ट, माइलस्टोन और इवेंट के लिए भी यही ढाँचा लागू होता है; ईमेल के लिए mails_list और mails_get, सदस्यों के लिए members_list और टैग के लिए tags_list उपलब्ध हैं।

सर्वर केवल वे टूल खोज में दिखाता है जिनकी अनुमति वर्तमान कुंजी के स्कोप देते हैं। contacts.read वाली कुंजी संपर्क पढ़ने के टूल खोज सकती है, लेकिन contacts_batch_upsert नहीं; contacts.write वाली कुंजी को बैच अपसर्ट टूल मिलता है, पढ़ने के टूल नहीं। whoami हमेशा उपलब्ध रहता है। लिखने वाले टूल के तत्काल प्रभाव उनके REST समकक्ष जैसे ही हैं। इसलिए बैच लागू किए बिना उसकी जाँच करने के लिए mode: "validate" का उपयोग करें।

MCP भी सर्वर से सर्वर के बीच संचार के लिए है और ब्राउज़र से क्रॉस-ऑरिजिन एक्सेस सक्षम नहीं करता। JSON-RPC परिवहन के लिए अलग URL आवश्यक है। इसलिए प्रमाणीकरण और डेटा का व्यवहार समान होने पर भी MCP किसी एक REST संसाधन के URL को साझा नहीं कर सकता।

क्लाइंट कॉन्फ़िगरेशन, सत्यापन, टूल का मिलान और समस्या-समाधान के पूरे निर्देश MCP एकीकरण गाइड में उपलब्ध हैं।

रिकॉर्ड पढ़ें

संपर्क, कार्य, प्रोटोकॉल, अवसर, प्रोजेक्ट, माइलस्टोन और इवेंट पढ़ने के लिए समान रूट उपयोग करते हैं:

GET /contacts?limit=50&updatedSince=2026-09-01T00:00:00.000Z
GET /contacts/{scoutelloId}
GET /contacts/external/{externalId}

अन्य सिंक्रोनाइज़ेशन संसाधनों के लिए contacts को tasks, protocols, opportunities, projects, milestones या events से बदलें। इस एकीकरण से रिकॉर्ड जुड़ा होने पर पढ़ने से लौटाए गए डेटा ऑब्जेक्ट में externalId दिखाई देता है।

सूची के उत्तर का प्रारूप यह है:

{
  "data": [],
  "page": {
    "nextCursor": null,
    "hasMore": false,
    "snapshotAt": "2026-09-01T12:00:00.000Z"
  },
  "requestId": "request-id"
}

limit का मान 1 से 100 के बीच होना चाहिए। परिणाम पहले उस प्रभावी समय के अनुसार और फिर Scoutello आईडी के अनुसार क्रमबद्ध होते हैं, जब उनकी सार्वजनिक API में दिखाई देने वाली जानकारी बदली थी। एकीकरण की कड़ी का मेटाडेटा बदलने पर यह प्रभावी समय लौटाए गए रिकॉर्ड के updatedAt से बाद का हो सकता है। कर्सर की सामग्री का अर्थ नहीं निकालना चाहिए: उसे बिना बदले सहेजें और भेजें।

पहला उत्तर उस पढ़ने के पूरे दौर के लिए snapshotAt तय करता है। अगला क्रमिक पढ़ने का दौर शुरू करने से पहले nextCursor का पालन करें, जब तक hasMore false न हो जाए। इससे पृष्ठ पढ़ने के दौरान रिकॉर्ड में बदलाव होने पर भी वर्तमान दौर स्थिर रहता है।

क्रमिक सिंक्रोनाइज़ेशन के लिए हर कर्सर पृष्ठ पढ़ें और फिर उस दौर का snapshotAt सबसे आगे संसाधित समय के रूप में सहेजें। अगले दौर में उसे ISO-8601 प्रारूप के updatedSince मान के रूप में भेजें। निचली सीमा शामिल होती है, इसलिए पूरा किया गया स्नैपशॉट दोहराने पर सीमा के रिकॉर्ड फिर लौट सकते हैं, लेकिन छूट नहीं सकते।

एक रिकॉर्ड के उत्तर का प्रारूप यह है:

{
  "data": {},
  "requestId": "request-id"
}

एक संपर्क के उत्तर में relations ऐरे भी शामिल होता है। हर संबंध में उसकी Scoutello संबंध आईडी, निर्माण समय, प्रकार, नोट्स और connectedFrom तथा connectedTo संपर्क संदर्भ होते हैं। संपर्क संदर्भों में Scoutello आईडी और उपलब्ध होने पर इस एकीकरण की बाहरी आईडी होती है। संगठन तक पहुँच की गोपनीयता सीमा के कारण API से बाहर रखे गए संपर्क संबंधों के माध्यम से भी उजागर नहीं होते। संपर्क सूची का उत्तर संक्षिप्त रहता है और उसमें संबंध शामिल नहीं होते। संबंधों का विवरण चाहिए तो किसी एक संपर्क को पढ़ने वाले रूट का उपयोग करें।

कार्यों के फ़िल्टर और कर्सर का दायरा

संपर्क सूची search, type (person, company, supplier, other), status और tagIds स्वीकार करती है। खोज के आरंभ और अंत का अतिरिक्त खाली स्थान हटाया जाता है, अक्षरों का बड़ा या छोटा रूप अलग नहीं माना जाता, और सीमा 200 अक्षर या खाली स्थान से अलग किए गए 10 टोकन है। हर टोकन firstName, lastName या companyName में से कम से कम एक में होना चाहिए; इसमें lastName में रखे गए पुराने कंपनी नाम भी शामिल हैं। % और _ जैसे चिह्नों का मिलान उनके मूल रूप में होता है। टैग 1–50 आईडी में से किसी भी चयनित टैग से मिलान स्वीकार करते हैं। सभी दिए गए फ़िल्टर AND के साथ लागू होते हैं। REST टैग आईडी को दोहराए गए पैरामीटर के रूप में भेजता है; MCP ऐरे भेजता है:

GET /contacts?search=Hamburg%20Hotel&type=company&status=prospect&tagIds=tag-one&tagIds=tag-two

संपर्क के कर्सर संगठन, एकीकरण और हर फ़िल्टर से जुड़े होते हैं। हर पृष्ठ पर फ़िल्टर बनाए रखें; कोई फ़िल्टर बदलने पर कर्सर अस्वीकार हो जाता है। टैग का क्रम या दोहराव तथा खोज टोकन का क्रम, अक्षरों का बड़ा/छोटा रूप या खाली स्थान प्रभावी फ़िल्टर नहीं बदलते।

वर्क सूची रूट निम्नलिखित अतिरिक्त फ़िल्टर स्वीकार करते हैं; अन्य संसाधन/फ़ील्ड संयोजन अस्वीकार कर दिए जाते हैं:

संसाधन	फ़िल्टर
कार्य	`projectScoutelloId`, `milestoneScoutelloId`, `status`, `statusType`, `priority`, `parentState`, `blockedState`, `assignedScoutelloUserId`, `dueBefore`, `dueAfter`
प्रोटोकॉल	`projectScoutelloId`, `milestoneScoutelloId`, `status` (`draft` या `final`)
अवसर	`projectScoutelloId`, `stage`, `ownerScoutelloUserId`
प्रोजेक्ट	`status`, `assignedContactScoutelloId`
माइलस्टोन	`projectScoutelloId`, `status`, `assignedContactScoutelloId`, `dueBefore`, `dueAfter`

dueBefore की सीमा शामिल नहीं होती; dueAfter की सीमा शामिल होती है। इनकी तुलना कार्य की नियत तारीख या माइलस्टोन की समाप्ति तारीख से की जाती है; बिना उस तारीख वाले रिकॉर्ड मेल नहीं खाते। टाइमज़ोन सहित ISO तारीख और समय दें। सभी फ़िल्टर पृष्ठों में विभाजन से पहले लागू किए जाते हैं। कर्सर को ठीक उन्हीं फ़िल्टर के साथ जारी रखें, जिनमें updatedSince भी शामिल है, और वही संगठन/एकीकरण रखें। पृष्ठ का आकार बदला जा सकता है। इस रिलीज़ के बाद पुराने दायरे से न जुड़े कर्सर को सहेजे गए सबसे आगे संसाधित समय से फिर शुरू करना होगा।

प्रोजेक्ट, माइलस्टोन, असाइनमेंट और नोट्स

GET /members (MCP members_list) मानक पेजिनेशन का उपयोग करता है और members.read आवश्यक है। यह scoutelloId (सदस्य Customer ID), scoutelloUserId (User ID) और displayName लौटाता है। केवल भूमिका वाले स्वीकृत संगठन सदस्य दिखाई देते हैं; लुकअप से ईमेल या अनुमतियाँ उजागर नहीं होतीं।

कार्य assignedScoutelloUserIds स्वीकार करते हैं; अवसर ownerScoutelloUserId का उपयोग करते हैं। प्रोजेक्ट और माइलस्टोन assignedContacts: [{"scoutelloId":"member-customer-id"}] का उपयोग करते हैं। असाइनमेंट के लिए क्रेडेंशियल वाले संगठन के स्वीकृत सदस्य आवश्यक हैं। छोड़े गए असाइनमेंट अपरिवर्तित रहते हैं; [] उन्हें साफ़ करता है। प्रोजेक्ट, माइलस्टोन, कार्य और प्रोटोकॉल के आयात बिना किसी सूचना के किए जाते हैं: वे असाइनमेंट की सूचनाएँ या अन्य संचार नहीं भेजते।

इवेंट में assignedContacts पढ़े जा सकने वाले CRM संपर्कों और सदस्य की Customer ID से निर्दिष्ट स्वीकृत सदस्यों का समर्थन करता है। स्वीकृत सदस्य सामान्य CRM संपर्क संदर्भों या बाहरी लिंक के लक्ष्य के रूप में उपलब्ध नहीं होते; टीम की ज़िम्मेदारी के लिए सदस्य असाइनमेंट फ़ील्ड का उपयोग करें।

name और projectScoutelloId या projectExternalId में से किसी एक के साथ माइलस्टोन बनाएँ। ये description (Markdown), status (open, in_progress, completed, closed), खाली छोड़े जा सकने वाले startDate/endDate, order (डिफ़ॉल्ट 0), और assignedContacts का समर्थन करते हैं। समाप्ति तिथियाँ आरंभ तिथियों से पहले नहीं हो सकतीं। प्रत्येक माइलस्टोन का इंटीग्रेशन के दायरे में एक स्थिर बाहरी लिंक होता है। API के माध्यम से इसका प्रोजेक्ट बदला नहीं जा सकता। बनाए जाने और अपडेट किए जाने पर नाम/विवरण को संगठन की भाषा में स्थानीयकृत किया जाता है।

टास्क और प्रोटोकॉल प्रोजेक्ट, माइलस्टोन और अवसर के संदर्भों को <entity>ScoutelloId या <entity>ExternalId के रूप में स्वीकार करते हैं, उदाहरण के लिए milestoneExternalId। प्रत्येक संबंध के लिए केवल एक वर्तनी दें, इसमें null के साथ संबंध हटाना भी शामिल है। सभी संबंध क्रेडेंशियल वाले संगठन से संबंधित होने चाहिए। केवल माइलस्टोन का संदर्भ प्रोजेक्ट का अनुमान लगा लेता है; असंगत प्रोजेक्ट, या उसके माइलस्टोन को बनाए रखते हुए प्रोजेक्ट को स्पष्ट रूप से हटाना, अस्वीकार कर दिया जाता है। प्रोजेक्ट से जुड़ा अवसर कार्य के प्रोजेक्ट से मेल खाना चाहिए। छोड़े गए संबंधों के वर्तमान मान बरकरार रहते हैं; स्पष्ट null शेष संदर्भ मान्य होने पर संबंध हटा देता है। रीड में दोनों ID वर्तनियाँ और टास्क असाइनमेंट दिखाई देते हैं।

टास्क योजना और वर्कफ़्लो

टास्क status, टास्क के प्रभावी वर्कफ़्लो में किसी स्थिति की अपरिवर्तनीय कुंजी है, न कि कोई निश्चित enum। tasks.read स्कोप का उपयोग करके GET /task-workflows के साथ उपलब्ध संगठन और प्रोजेक्ट वर्कफ़्लो पढ़ें। प्रत्येक स्थिति में इसकी कुंजी, लेबल, लाइफ़साइकल type (backlog, unstarted, started, completed, या cancelled), रंग, क्रम, डिफ़ॉल्ट फ़्लैग और आर्काइव स्थिति शामिल होती है। प्रोजेक्ट प्रविष्टियाँ बताती हैं कि संगठन का वर्कफ़्लो इनहेरिट किया गया है या नहीं। वर्कफ़्लो कॉन्फ़िगरेशन का प्रबंधन डैशबोर्ड से ही किया जाता है।

कार्य खाली छोड़े जा सकने वाले priority (low, medium, high, या urgent) और estimatedEffortMinutes, साथ ही खाली छोड़े जा सकने वाले startDate और dueDate को स्वीकार करते हैं। कार्य पढ़ने के उत्तर में पहले से समेकित statusType, पैरेंट संदर्भ, संक्षिप्त उपकार्य संदर्भ और blockedBy / blocks संदर्भ शामिल होते हैं।

parentTaskScoutelloId या parentTaskExternalId में से किसी एक का उपयोग करके एक-स्तरीय उपकार्य बनाएँ या अपडेट करें; null इसे शीर्ष-स्तरीय कार्य में बदल देता है। निर्भरताओं के लिए blockedBy और blocks में { "scoutelloId": "..." } या { "externalId": "..." } संदर्भों की सारणियों का उपयोग करें। छोड़े गए संबंध फ़ील्ड मौजूदा संबंध बनाए रखते हैं, जबकि खाली निर्भरता-सारणी उस दिशा को साफ़ कर देती है। API नेस्टेड उपकार्यों, पैरेंट-चाइल्ड निर्भरताओं, अलग-अलग संगठनों के बीच निर्भरताओं, डुप्लिकेट, स्वयं-संदर्भों और प्रत्यक्ष या ट्रांज़िटिव चक्रों को अस्वीकार करती है।

कार्य-सूची फ़िल्टर सटीक वर्कफ़्लो status, लाइफ़साइकल statusType, priority, parentState (top_level, subtask या parent में से कोई एक), और blockedState (blocked, blocking या unblocked में से कोई एक) स्वीकार करते हैं।

प्रोटोकॉल अतिरिक्त रूप से status: "draft" | "final" स्वीकार करते हैं (नए रिकॉर्ड डिफ़ॉल्ट रूप से final पर सेट होते हैं)। नए प्रोटोकॉल के लिए type, date और किसी संपर्क या मान्य प्रोजेक्ट/माइलस्टोन संदर्भ में से एक आवश्यक है। contactExternalId: null संपर्क का संबंध केवल तब हटाता है, जब प्रोजेक्ट/माइलस्टोन संदर्भ बना रहे। इसलिए आंतरिक प्रोजेक्ट नोट ग्राहक गढ़े बिना बनाए और पढ़े जा सकते हैं। ड्राफ़्ट/फ़ाइनल नोट की स्थिति बताता है और कभी कोई संचार नहीं भेजता। निजी कार्य और प्रोटोकॉल अब भी अप्राप्य रहते हैं।

प्रोजेक्ट प्रतिभागी

प्रोजेक्ट participants में contact संदर्भ के आधार पर अतिरिक्त रूप से किए जाने वाले अपसर्ट शामिल होते हैं, उदाहरण के लिए:

{
  "externalId": "gtm:hotels",
  "participants": [{
    "contact": {"scoutelloId": "prospect-contact-id"},
    "role": "Potential pilot",
    "notes": "Existing warm lead; qualify the next step.",
    "groupScoutelloId": null
  }]
}

प्रतिभागी किसी प्रोजेक्ट से जुड़े संभावित या मौजूदा ग्राहकों का विवरण देते हैं; जवाबदेह टीम सदस्य असाइनमेंट का उपयोग करते हैं। छोड़े गए प्रतिभागी, खाली सारणी और छोड़े गए प्रतिभागी फ़ील्ड मौजूदा डेटा बनाए रखते हैं। null role, notes या groupScoutelloId को साफ़ करता है। एक ही पेलोड में डुप्लिकेट रूप से हल किए गए संपर्क अस्वीकार कर दिए जाते हैं। समूहों का पहले से चयनित प्रोजेक्ट से संबंधित होना आवश्यक है; रीड ऑपरेशन में participantGroups (ID/नाम), प्रतिभागी ID, संपर्क, भूमिका, नोट और समूह ID शामिल होते हैं। प्रतिभागियों को हटाना या समूह बनाना फ़िलहाल डैशबोर्ड में उपलब्ध है।

बैच में रिकॉर्ड अपसर्ट करना

रिसोर्स के बैच रूट का उपयोग करके अधिकतम 100 रिकॉर्ड लिखें:

POST /contacts/batch-upsert
Content-Type: application/json

{
  "mode": "apply",
  "records": [
    {
      "externalId": "record-123",
      "externalUpdatedAt": "2026-09-01T11:45:00.000Z",
      "type": "person",
      "firstName": "Alex",
      "lastName": "Example",
      "email": "alex@example.com"
    }
  ]
}

कार्य बैच पैरेंट और निर्भरता संबंध लागू करने से पहले अपने कार्य रिकॉर्ड को हल करते हैं। यह दो-चरणीय प्रोसेसिंग किसी पैरेंट, ब्लॉकर या अवरुद्ध कार्य को रिकॉर्ड के क्रम की परवाह किए बिना, उसी बैच में बनाए गए किसी अन्य कार्य को उसके बाहरी ID से संदर्भित करने देती है।

प्रत्येक संसाधन के फ़ील्ड और सत्यापन संबंधी बाधाओं के लिए OpenAPI दस्तावेज़ का उपयोग करें। प्रत्येक रिकॉर्ड में 1 से 200 वर्णों के बीच एक स्थिर externalId होना अनिवार्य है। इसे एक अपारदर्शी तकनीकी पहचानकर्ता मानें: इसमें ईमेल पता, नाम, API सीक्रेट या अन्य व्यक्तिगत डेटा का उपयोग न करें। externalUpdatedAt वैकल्पिक है, लेकिन जब स्रोत सिस्टम विश्वसनीय संशोधन टाइमस्टैम्प प्रदान करता हो, तब इसका उपयोग करना दृढ़ता से अनुशंसित है।

अनुरोध बॉडी 1 MiB तक सीमित है। mode का डिफ़ॉल्ट मान apply है:

apply स्वीकृत रिकॉर्ड का सत्यापन और लेखन करता है।
validate लेखन किए बिना वही सत्यापन और मिलान करता है और would_* परिणाम लौटाता है।

संपर्क आयात के लिए, अनुरोध में matchByEmail को true पर सेट किया जा सकता है। इसका डिफ़ॉल्ट false है; बाहरी ID अधिक सुरक्षित डिफ़ॉल्ट पहचान सीमा है।

छोड़े गए फ़ील्ड का वर्तमान मान बरकरार रहता है। स्पष्ट null किसी ऐसे फ़ील्ड को साफ़ करता है जिसे खाली छोड़ा जा सकता है, और दी गई खाली असाइनमेंट/टैग ऐरे उस संबंध को साफ़ कर देती है। प्रोजेक्ट participants में अपसर्ट मौजूदा प्रविष्टियों को बनाए रखते हुए जोड़ता या बदलता है: खाली ऐरे से प्रतिभागियों की सूची में कोई बदलाव नहीं होता। संपर्क, कार्य, अवसर और इवेंट टैग लेखन में Scoutello टैग ID का उपयोग होता है। संबंधों की बाहरी ID का समाधान केवल वर्तमान इंटीग्रेशन से संबंधित लिंक के माध्यम से किया जाता है, जबकि स्वामित्व या ज़िम्मेदारी के लिए उपयोग की जाने वाली Scoutello उपयोगकर्ता ID वर्तमान संगठन के स्वीकृत सदस्यों की पहचान करनी चाहिए।

अवसर बनाने के लिए किसी खाते या संपर्क का होना आवश्यक है, और खोए हुए अवसरों के लिए हानि का कारण आवश्यक है। मौद्रिक राशियों में पूर्णांक सेंट का उपयोग होता है। प्रोजेक्ट और इवेंट के नाम और विवरण संगठन की कॉन्फ़िगर की गई भाषा में पढ़े और लिखे जाते हैं। इवेंट लेखन में स्पष्ट तिथियों तथा अपवर्जनों के साथ दैनिक, साप्ताहिक या मासिक पुनरावृत्ति का समर्थन है; प्रकाशित दृश्यता स्तर Scoutello के कानूनी-तत्परता गेट के अधीन रहते हैं। API इवेंट टिकटिंग, प्रतिभागियों, मीडिया, टेम्पलेट, न्यूज़लेटर, सहयोग या अन्य उन्नत इवेंट-प्रबंधन नियंत्रण उपलब्ध नहीं कराती।

टैग खोजें

tagIds देने से पहले टैग एंडपॉइंट का उपयोग करें:

GET /tags?entity=events&type=category

entity आवश्यक है और contacts, tasks, opportunities या events स्वीकार करता है। यह संबंधित संग्रहीत टैग प्रासंगिकता से मैप होता है। type वैकल्पिक है और category या attribute स्वीकार करता है। चयन योग्य श्रेणियाँ संगठन-स्वामित्व वाली या वैश्विक हो सकती हैं; चयन योग्य विशेषताएँ Scoutello के क्यूरेट किए गए वैश्विक विशेषता सेट से आती हैं। परिणामों में scoutelloId, संगठन की भाषा में स्थानीयकृत नाम, type और relevancy शामिल होते हैं। अलग-अलग संगठनों से संबंधित, गलत प्रासंगिकता वाले और गैर-चयन योग्य टैग ID प्रभावित बैच आइटम को अस्वीकार कर देती हैं।

भेजे गए ईमेल का इतिहास पढ़ें

मेल इतिहास केवल पढ़ने के लिए है:

GET /mails?updatedSince=2026-09-01T00:00:00.000Z
GET /mails/{scoutelloId}

केवल sent या failed स्थिति वाला संगठन-स्वामित्व वाला मेल लौटाया जाता है। प्रतिक्रियाओं में सामान्य रूप से संग्रहीत हेडर और मुख्य भाग, BCC, स्थिति और टाइमस्टैम्प, प्रोजेक्ट/इवेंट/न्यूज़लेटर संदर्भ, अटैचमेंट आईडी और प्रकार, तथा प्राप्तकर्ता डिलीवरी/ओपन/क्लिक/बाउंस/शिकायत/अस्वीकृति के समेकित आँकड़े शामिल होते हैं। ड्राफ़्ट, कतार में मौजूद या शेड्यूल किए गए मेल, प्रति-प्राप्तकर्ता पंक्तियाँ, रेंडर किए गए स्नैपशॉट, प्रदाता की कच्ची त्रुटियाँ और अटैचमेंट डाउनलोड URL कभी उजागर नहीं किए जाते। प्राप्तकर्ता की बाद की डिलीवरी अपडेट मेल के प्रभावी सिंक्रनाइज़ेशन टाइमस्टैम्प को आगे बढ़ाती है, इसलिए मेल फिर से क्रमिक रीड में दिखाई देता है। मेल लिखने के लिए कोई रूट उपलब्ध नहीं हैं।

एप्लाई परिणाम created, updated, linked, unchanged, stale_ignored या rejected हो सकता है। सत्यापन में would_create, would_update, would_link, would_leave_unchanged, would_ignore_stale या rejected का उपयोग किया जाता है। मान्य बैच अनुरोध HTTP 200 लौटाता है, भले ही अलग-अलग रिकॉर्ड अस्वीकार कर दिए गए हों, इसलिए हर आइटम और प्रतिक्रिया सारांश की हमेशा जाँच करें। किसी विफलता की जाँच के लिए Scoutello सहायता से संपर्क करते समय प्रतिक्रिया requestId रखें।

टाइमस्टैम्प और विरोधाभास

जब externalUpdatedAt मौजूद होता है, तो Scoutello इसका उपयोग पुराने बदलावों को अस्वीकार करने के लिए करता है, जबकि बैच के बाकी हिस्से में विफलता नहीं आती। stale_ignored परिणाम उस पुराने पेलोड के लिए अंतिम होता है; नया संस्करण भेजना है या नहीं, यह तय करने से पहले वर्तमान रिकॉर्ड प्राप्त करें।

टाइमस्टैम्प को UTC ISO 8601 मानों के रूप में मानें। उनकी मूल सटीकता बनाए रखें और सिंक जॉब के चलने का समय स्रोत रिकॉर्ड के संशोधन समय के स्थान पर न रखें।

इडेम्पोटेंसी

इडेम्पोटेंसी सीमा इंटीग्रेशन और externalId के बीच है। Scoutello कैनॉनिकल पेलोड हैश और वैकल्पिक externalUpdatedAt मान की तुलना करता है, इसलिए उसी रिकॉर्ड का पुनः प्रयास डुप्लिकेट नहीं बनाता और unchanged लौटा सकता है।

externalUpdatedAt के साथ, वही टाइमस्टैम्प और पेलोड unchanged होता है, पुराना टाइमस्टैम्प stale_ignored होता है, और अलग पेलोड वाला वही टाइमस्टैम्प संस्करण विरोधाभास होता है। जिस लिंक ने कभी टाइमस्टैम्प स्वीकार नहीं किया है, उसके लिए टाइमस्टैम्प-विहीन वही पेलोड unchanged रहता है, जबकि बदला हुआ पेलोड प्राप्ति क्रम में लागू किया जाता है। किसी लिंक द्वारा टाइमस्टैम्प स्वीकार करने के बाद, externalUpdatedAt को छोड़ने वाला बदला हुआ पेलोड संस्करण विरोधाभास के रूप में अस्वीकार कर दिया जाता है, ताकि बिना संस्करण वाले डेटा से संस्करणयुक्त स्थिति अधिलेखित न हो सके। इसी कारण स्रोत संशोधन टाइमस्टैम्प की पुरज़ोर अनुशंसा की जाती है।

ऑडिट ट्रेल

स्वीकृत API निर्माण, अपडेट और केवल कड़ी जोड़ने वाली सिंक्रोनाइज़ेशन कार्रवाइयाँ Scoutello के बदलाव इतिहास में Public API को स्रोत के रूप में दिखाती हैं और संबंधित एकीकरण से जुड़ी होती हैं। परिचालन रन के सारांश में समस्या-समाधान के लिए अनुरोध आईडी और समेकित परिणाम-संख्याएँ रखी जाती हैं; इनमें रिकॉर्ड का मुख्य डेटा या API के गोपनीय क्रेडेंशियल नहीं रखे जाते।

त्रुटियाँ और पुनःप्रयास

अनुरोध-स्तर की त्रुटियाँ इस उत्तर प्रारूप का उपयोग करती हैं:

{
  "error": {
    "code": "error_code",
    "message": "Safe error message",
    "requestId": "request-id",
    "details": {}
  }
}

HTTP 429 और अस्थायी 5xx उत्तरों पर हर बार बढ़ते विलंब और थोड़े यादृच्छिक अंतर के साथ पुनः प्रयास करें। Retry-After मौजूद होने पर उसका पालन करें। Scoutello द्वारा अनुरोध स्वीकार किए जाने के बाद भी नेटवर्क विफल हो सकता है; वही बैच दोबारा भेजना सुरक्षित है, क्योंकि प्रत्येक रिकॉर्ड की बाहरी आईडी और मुख्य डेटा के मानक हैश से दोहराव पहचाना जाता है। अनुरोध बदले बिना प्रमाणीकरण, अनुमति, सत्यापन, संस्करण संघर्ष या व्यक्तिगत rejected परिणामों पर स्वतः पुनः प्रयास न करें।

अनुशंसित द्विदिशीय सिंक्रोनाइज़ेशन लूप

सेटअप के दौरान /whoami को कॉल करें और अपेक्षित संगठन तथा स्कोप की पुष्टि करें।
पिछले पूर्ण किए गए दौर के सबसे आगे संसाधित समय के बाद बदले गए हर पृष्ठ को पढ़ें और दोहराव पहचाने जा सकने वाले तरीके से वे बदलाव बाहरी सिस्टम पर लागू करें।
बाहरी बदलावों को /batch-upsert पर भेजें; इसके लिए स्थिर बाहरी आईडी और स्रोत के संशोधन समय का उपयोग करें।
सभी पृष्ठों और प्रविष्टियों के परिणाम संभालने के बाद ही प्रगति के जाँच-बिंदु स्थायी रूप से सहेजें।
स्रोत सिस्टम के स्वामित्व नियमों के अनुसार संघर्ष हल करें; खाली रिकॉर्ड भेजकर हटाने की कार्रवाई की नकल न करें।

Scoutello इस पहले संस्करण में जानबूझकर कोई सार्वजनिक रूट नहीं देता जिससे रिकॉर्ड हटाए जा सकें। जब तक कोई प्रलेखित जीवनचक्र कार्रवाई उपलब्ध नहीं होती, हटाने या संग्रहित करने की नीतियाँ API के बाहर संभालें।

सोशल API किसी नामित मानव समीक्षक के लिए पोस्ट तैयार करती है। यह उनका अनुमोदन या प्रकाशन नहीं कर सकती। REST और MCP समान स्कोप और सेवा का उपयोग करते हैं।

स्कोप	`/api/v1` के अंतर्गत एंडपॉइंट
`social-channels.read`	`GET /social-channels`
`social-posts.read`	`GET /social-posts`, `GET /social-posts/{scoutelloId}`
`social-post-drafts.read`	`GET /social-post-drafts`, `GET /social-post-drafts/{scoutelloId}`, `GET /social-post-drafts/external/{externalId}`
`social-post-drafts.write`	`POST /social-post-drafts/batch-upsert`, `POST /social-media/uploads`, `POST /social-media/uploads/{assetId}/finalize`

नए स्कोप स्पष्ट रूप से देना आवश्यक है। मौजूदा क्रेडेंशियल को अतिरिक्त एक्सेस नहीं मिलता। सदस्यों की उपयोगकर्ता आईडी खोजने के लिए members.read का उपयोग करें और पोस्ट करने की अनुमति वाले समीक्षक (newsletter.edit) का चयन करें। ड्राफ़्ट के लिए CRM संपर्क या प्रोजेक्ट आवश्यक नहीं है।

{
  "mode": "apply",
  "records": [{
    "externalId": "campaign:autumn:launch",
    "expectedVersion": 0,
    "approverScoutelloUserId": "REVIEWER_USER_ID",
    "content": {
      "title": "Autumn launch",
      "publishMode": "schedule",
      "scheduledAt": "2026-10-01T09:00:00+02:00",
      "variants": [{
        "channelId": "CHANNEL_SCOUTELLO_ID",
        "content": "Explore the autumn collection.",
        "settings": {},
        "mediaIds": ["FINALIZED_ASSET_ID"]
      }]
    }
  }]
}

अनुमोदन मिलने पर प्रकाशित करने के लिए publishMode: "now" और scheduledAt: null का उपयोग करें। हर चैनल संस्करण में उसका पूरा पाठ, सेटिंग्स और क्रमबद्ध मीडिया आईडी होती हैं। चैनलों की खोज से समर्थित प्रारूप, सीमाएँ और सेटिंग्स मिलती हैं। वर्तमान में LinkedIn प्रोफ़ाइल/पेज, Facebook, Instagram और Threads समर्थित हैं। Instagram के लिए मीडिया आवश्यक है। एक संस्करण में अधिकतम दस चित्र या वीडियो हो सकते हैं।

बैच मौजूदा अनुरोध सीमा के भीतर अधिकतम 100 अलग-अलग बाहरी आईडी स्वीकार करते हैं; सीमा 1 MiB है। mode: "validate" संदर्भों और संस्करणों की जाँच करता है, लेकिन ड्राफ़्ट नहीं सहेजता, एसेट अपलोड नहीं करता, सूचनाएँ नहीं बनाता और काम कतार में नहीं जोड़ता। लागू करने के परिणामों में आईडी, समीक्षा लिंक, संस्करण और हर रिकॉर्ड का परिणाम होता है। कुछ रिकॉर्ड विफल होने पर सफल रिकॉर्ड के बदलाव वापस नहीं किए जाते। सूचना भेजने में विफलता होने पर चेतावनी और सहेजा गया समीक्षा URL लौटाया जाता है।

लंबित ड्राफ़्ट बदलने से पहले वर्तमान draftVersion पढ़ें। समान अनुरोध दोहराने पर दोहराव से बदलाव नहीं होता और बाद में किए गए मानवीय संपादन सुरक्षित रहते हैं। समीक्षक को उसी ड्राफ़्ट में बदला नहीं जा सकता। अनुमोदन या अस्वीकृति के बाद नए प्रस्ताव के लिए नई बाहरी आईडी उपयोग करें। ड्राफ़्ट केवल कॉल करने वाले एकीकरण द्वारा पढ़े जा सकते हैं; प्रकाशन इतिहास में संगठन के सभी सहेजे गए Scoutello-निर्मित कैंपेन शामिल होते हैं, जिनमें डैशबोर्ड, स्क्रिप्ट और पुराने Scoutello पोस्ट शामिल हैं। बाहरी चैनल का इतिहास आयात नहीं होता।

सूचियाँ मानक limit, cursor और updatedSince पैरामीटर उपयोग करती हैं। पोस्ट और ड्राफ़्ट channelId, status, after, before और search भी स्वीकार करते हैं; हर फ़िल्टर अगले कर्सर पृष्ठों पर बनाए रखें। तारीख के फ़िल्टर प्रकाशन समय पर लागू होते हैं (तुरंत प्रकाशित होने वाले लंबित ड्राफ़्ट के लिए निर्माण समय पर)। ड्राफ़्ट का status अनुमोदन की स्थिति फ़िल्टर करता है; पोस्ट का status कैंपेन या चैनल की डिलीवरी स्थिति से मेल खाता है। पढ़ने के उत्तर में अंतिम ज्ञात डिलीवरी स्थिति, हर चैनल की विफलताएँ, सार्वजनिक लिंक और मिलान के समय मिलते हैं। ड्राफ़्ट को क्रमिक रूप से पढ़ने में कैंपेन की डिलीवरी के बदलाव भी शामिल होते हैं।

मीडिया अपलोड करें

POST /social-media/uploads को clientUploadId, filename, contentType, size के साथ बाइट्स में कॉल करें, और मूल बाइट्स के sha256 को लोअरकेस हेक्साडेसिमल में भेजें। समर्थित प्रकार PNG, JPEG, WebP, MP4, WebM, QuickTime और M4V हैं। अपलोड की अधिकतम सीमा 500 MiB है।
मूल बाइट्स को HTTP PUT के माध्यम से लौटाए गए upload.url पर भेजें और उसके हेडर का उपयोग करें। अपलोड URL 15 मिनट बाद समाप्त हो जाते हैं। उसी फ़ाइल के पुनः प्रयासों के लिए clientUploadId का पुनः उपयोग करें; समाप्त हो चुके सेशन या अलग फ़ाइल के लिए नई ID आवश्यक है।
POST /social-media/uploads/{assetId}/finalize को {} वाले JSON बॉडी के साथ कॉल करें। अंतिम रूप देने की प्रक्रिया आकार, प्रकार, सिग्नेचर और चेकसम की जाँच करती है, एक निजी कॉपी को स्थिर करती है, और mediaIds के लिए एसेट ID लौटाती है। अंतिम रूप देने की प्रक्रिया को दोहराना सुरक्षित है।

अपलोड का स्वामित्व संगठन और इंटीग्रेशन से जुड़ा होता है। ड्राफ़्ट अपने संगठन के अंतिम रूप दिए गए एसेट का संदर्भ दे सकते हैं। प्रीव्यू URL अस्थायी होते हैं; उन्हें ताज़ा करने के लिए ड्राफ़्ट को फिर से प्राप्त करें। अंतिम रूप दिए गए ऑब्जेक्ट के लिए अपलोड URL कभी जारी नहीं किए जाते।

मानव समीक्षा और डिलीवरी

समीक्षक को डैशबोर्ड पर सूचना मिलती है और पोस्टिंग्स से या उसके समीक्षा URL के माध्यम से पोस्ट खोला जा सकता है। संपादन करने पर एक और अपरिवर्तनीय संस्करण बनता है। स्वीकृति प्रदर्शित संस्करण और कंटेंट हैश का उपयोग करती है, सदस्यता, चैनलों और एसेट की फिर से जाँच करती है, और परमानेन्ट रूप से एक कैंपेन बनाती है। यदि प्रस्तावित समय बीत चुका है, तो समीक्षक को स्पष्ट रूप से नया समय सहेजना होगा या स्वीकृति पर प्रकाशन चुनना होगा।

क्यू पुनः प्रयासों में कैंपेन और उसके प्लेटफ़ॉर्म रसीदों का पुनः उपयोग किया जाता है। स्वीकृत कैंपेन को उसी स्थान पर संपादित नहीं किया जा सकता। डैशबोर्ड के माध्यम से रद्द करने पर उनका स्वीकृति इतिहास और मीडिया सुरक्षित रहते हैं; रद्दीकरण सक्रिय डिस्पैच को बाधित नहीं कर सकता। स्वीकृति और वास्तविक प्लेटफ़ॉर्म डिलीवरी में अंतर करने के लिए ड्राफ़्ट या कैंपेन की स्थिति की जाँच करें।

कुंजी बनाना और सुरक्षित रखना​

स्कोप​

प्रोजेक्ट से जुड़े संपर्क और ईमेल ड्राफ़्ट​

MCP तक पहुँच​

रिकॉर्ड पढ़ें​

कार्यों के फ़िल्टर और कर्सर का दायरा​

प्रोजेक्ट, माइलस्टोन, असाइनमेंट और नोट्स​

टास्क योजना और वर्कफ़्लो​

प्रोजेक्ट प्रतिभागी​

बैच में रिकॉर्ड अपसर्ट करना​

टैग खोजें​

भेजे गए ईमेल का इतिहास पढ़ें​

टाइमस्टैम्प और विरोधाभास​

इडेम्पोटेंसी​

ऑडिट ट्रेल​

त्रुटियाँ और पुनःप्रयास​

अनुशंसित द्विदिशीय सिंक्रोनाइज़ेशन लूप​

मानवीय समीक्षा के लिए सोशल पोस्ट​

मीडिया अपलोड करें​

मानव समीक्षा और डिलीवरी​