Skip to main content

API Access

📖 Best for: Developers / integrators / platform admins — people who want to use the OpenAI-compatible protocol to embed YingCore’s models into their own systems, products, or mini-programs

📖 Reading time: 4 minutes

📖 In one sentence: YingCore's unified interface layer that lets your systems / apps / mini-programs call all models configured on the YingCore platform via the OpenAI-compatible protocol. Provides API key management, OpenAPI docs, multi-language SDKs, streaming responses, quota/rate-limit, and webhook callbacks. Accessible from top nav "API Access" (/platform-api-console), all roles, supports OpenAI-compatible + native REST, full details: System Integration Guide.

I. Core Value​

ValueDescription
Protocol compatibilityOpenAI-compatible interface — existing OpenAI SDK code needs only base_url + api_key changes to integrate, with zero migration cost
One-stop shopThe full flow from "key issuance → docs review → code invocation → quota control → billing reconciliation" is done in one place — no jumping between systems
Enterprise-grademTLS mutual authentication, field-level masking, audit logs, IP whitelists, expiration — meets production compliance requirements
ObservablePer-key call volume, token consumption, cost, and error rate are visualized in real time, with bill export
ScalableMulti-language SDKs, streaming responses, webhook callbacks — support everything from "real-time chat" to "million-scale offline batch processing"

II. Main Capabilities​

1. API Key Management​

  • Issue independent API Keys per application / per developer in the workbench, with per-key permission scopes, IP whitelists, and expiration times.
  • List / create / delete platform tokens, with one-click key copy.
  • Built-in security & compliance: mTLS mutual authentication, field-level masking, full audit log traceability.
  • ⚠️ Keys are sensitive credentials — once you close or refresh the page, the plaintext may not be shown again. Keep them safe.

2. OpenAI-Compatible Interface​

  • Provides a standard OpenAI-protocol Base URL: https://your-platform/platform-api/v1.
  • Point your OpenAI SDK's base_url to the platform address and put your key in api_key — and you can call any model configured on the platform.
  • Call the /platform-api/v1/models endpoint with your token to fetch the available model list; each model shows: model ID, vendor, type (chat / embedding / rerank / image2text / tts / speech2text / ocr), original model name, context length, capability tags (vision / tool-calling / reasoning / image generation / multimodal, etc.), and whether tool-calling is supported.
  • Zero migration cost — most existing OpenAI SDK code only needs 2 parameters changed to integrate.

3. Complete OpenAPI Documentation​

  • All platform capabilities — chat, digital employees, workflows, knowledge base, graph — have standard REST API documentation.
  • Comes with Swagger UI for online debugging — fill in params, try the call, and view the response directly on the docs page, no local environment needed.
  • Each endpoint documents: HTTP method, path, parameters, auth method, response structure, error codes, and call examples.

4. Multi-Language SDKs​

  • Official SDKs for Python, Node.js, Java, Go.
  • Encapsulates common concerns — auth, retry, streaming response — so business code focuses on business logic.
  • Also wraps platform-specific capabilities (digital employee calls, workflow triggers, vector retrieval, etc.) so you don't have to call raw REST.

5. Streaming Response (SSE / WebSocket)​

  • LLM chat supports streaming output — the model returns tokens as it generates them, achieving a real-time typewriter effect without waiting for the complete response.
  • Both SSE (Server-Sent Events) and WebSocket protocols are available to fit different frontend architectures.
  • Streams can be interrupted, reconnected, and have their token usage accumulated — enabling the "stop generating" UX in the frontend.

6. Quota & Rate Limiting​

  • Configure QPS, daily quota, monthly quota, and concurrency cap per key.
  • On excess, circuit-break automatically and return explicit error codes (429 Too Many Requests / custom business codes); the frontend can show friendly prompts.
  • Support multi-level quota allocation by team / project / application so admins can govern the entire platform's resources centrally.

7. Usage Statistics & Billing​

  • Per-key call volume, token consumption (input / output), cost, and error rate are visualized in real time.
  • Cross-cut by time dimension (hour / day / month) and model dimension to pinpoint cost hotspots.
  • Bills are exportable (Excel / CSV) for handoff to enterprise finance systems.

8. Webhook Callbacks​

  • For async tasks (workflow execution, batch import, batch summarization, etc.), actively push results to a specified URL when the task finishes — no polling required.
  • Support signature verification (HMAC), retry strategy (exponential backoff), and dead-letter queue (archived after repeated failures).
  • Combined with streaming response, you can do real-time interaction AND offline batch jobs.

III. Typical Use Cases​

Use Case 1: Integrate Into Your Own App​

A developer uses the Python SDK in 3 lines of code to embed LLM chat into their own app:

from yingcore import YingCore
yc = YingCore(api_key="YOUR_KEY")
resp = yc.chat.completions.create(model="deepseek-chat", messages=[{"role":"user","content":"hello"}])
print(resp.choices[0].message.content)

No frontend, no ops, the friendliest path for individual developers — you can get your first demo running in minutes.

Use Case 2: Embed Into Business Systems​

Add an "AI Summary" button in CRM, ERP, or ticketing systems. On click, call YingCore's API to summarize the current ticket / customer profile / contract terms, and render the result directly on the page. The full interaction takes < 3 seconds, no tool-switching for business users, and efficiency jumps significantly.

Use Case 3: Mini-Program Smart Customer Service​

WeChat mini-programs call YingCore over HTTPS, and a digital employee auto-replies to user inquiries. Streaming response gives users a "typing-as-you-read" real-time feel, while webhook callbacks archive high-value conversations back to the CRM.

Use Case 4: Batch Offline Tasks​

Call the API to trigger a batch summarization of 100,000 tickets. The API immediately returns a task_id; the actual processing runs on the platform's backend. When done, webhook callbacks push results, and the business system archives and generates reports on receipt. The whole flow needs no polling from the business system, and resource use drops to zero.

Use Case 5: Cross-Team Quota Management​

Give Team A 1M tokens/month and Team B 500K tokens/month as independent quotas. On excess, circuit-break automatically and send email alerts — preventing one team's runaway consumption from taking down the whole platform. Admins view a platform-wide usage dashboard to plan capacity expansion or cost allocation in advance.

IV. Usage Guide​

Step 1: Apply for an API Key

  1. Click 「获取API」 in the top navigation to enter the console.
  2. In the API Key Management area, click 「创建」 and set the key name, permission scope, IP whitelist, and expiration time.
  3. Click 「复制」 to save the key (once you close or refresh, the plaintext may not be shown again).

Step 2: Read the OpenAPI Documentation

  1. In the console, click 「API 文档」 to open the Swagger UI.
  2. Select the capability to integrate (chat / digital employee / workflow / knowledge base / graph).
  3. Try the call directly on the docs page to confirm parameters and response structure.

Step 3: Integration & Invocation

  1. Simple scenarios: use the OpenAI SDK — change base_url to the platform address, put your key in api_key, and call directly.
  2. Complex scenarios: use the official SDKs (Python / Node.js / Java / Go), which encapsulate auth / retry / streaming.
  3. Streaming needs: choose the SSE or WebSocket protocol; the frontend renders a "typewriter" effect.
  4. Async tasks: specify webhook_url on submission; the platform pushes results back when the task finishes.

Step 4: Monitoring & Operations

  1. In the Usage Statistics area, review each key's call volume, cost, and error rate.
  2. In the Quota Management area, adjust QPS / daily / monthly quota caps and set circuit-break alerts.
  3. Export bills to feed the finance system, and periodically audit sensitive operations via the audit log.

V. Best Practices​

  • Prefer protocol compatibility — for simple integrations, use the OpenAI SDK and change 2 parameters. Only fall back to native REST for edge cases the SDK doesn't cover (custom webhook signatures, mTLS mutual auth).
  • Isolate keys — use independent keys for different environments (dev / test / prod), different apps, and different teams. This enables permission isolation, usage traceability, and faster issue localization. Don't make one key do everything.
  • Safeguard keys — production keys must not be exposed in plaintext in frontend pages or code repos. Inject them via environment variables / KMS, and rotate them regularly.
  • Monitor quotas — set daily / monthly quota caps and alert thresholds (e.g., 80%) on production keys to prevent runaway consumption. Circuit-breaking beats overage shutdown every time.
  • Stream rather than poll — for user-facing chat, use streaming response; only fall back to synchronous wait for "user has left the page" background tasks.
  • Async via webhook — for batch tasks (> 100 items) or long-running tasks (> 5 seconds), prefer webhook callbacks to get results instead of polling. Signature verification + dead-letter queue guarantees no task loss.
  • Security & compliance — in production, enable mTLS mutual authentication, field-level masking for sensitive fields (phone / ID number), and audit logging for admin actions.
  • Error handling — clients must handle three error classes: 429 quota exhausted, 401 key invalid, 5xx platform error — and provide graceful degradation (queue / refresh prompt / fallback key).