Coding

Bitrix24 Skill

Build guarded Bitrix24 REST integrations with auth routing, method selection, and offline event processing.

What it does

Build Bitrix24 REST integrations with lean reference routing, method-pack selection, and guarded client scripts. It chooses webhook or OAuth auth, applies allowlists and write confirmations, and supports reliable offline event processing with retries and a dead-letter queue.

When to use it

  • Selecting auth for a Bitrix24 integration
  • Calling REST methods with guarded writes
  • Troubleshooting auth, scope, token, or query-limit errors
  • Processing events through an offline queue

The skill document

Bitrix24 Agent (Lean + Reliable)

Use this skill to deliver correct Bitrix24 integrations with minimal token usage.

Default Mode: Lean

Apply these limits unless the user asks for deep detail:

  • Load at most 2 reference files before first actionable step.
  • Start from references/packs.md.
  • Then open only one target file: references/catalog-.md.
  • Open references/chains-.md only if user asks for workflow/chain.
  • Open references/bitrix24.md only for auth architecture, limits, events reliability, or unknown errors.

Response format limits:

  • Use concise output (goal + next action + one command).
  • Do not retell documentation.
  • Do not dump large JSON unless explicitly requested.
  • Avoid repeating already provided guidance; return only delta.

Routing Workflow

  1. Determine intent:
  • method call,
  • troubleshooting,
  • architecture decision,
  • event/reliability setup.

Term normalization (product vocabulary):

  • "collabs", "workgroups", "projects", "social network groups" -> collab (and boards for scrum).
  • "Copilot", "CoPilot", "BitrixGPT", "AI prompts" -> platform (ai.*).
  • "open lines", "contact center connectors", "line connectors" -> comms (imopenlines.*, imconnector.*).
  • "feed", "live feed", "news feed" -> collab (log.*).
  • "sites", "landing pages", "landing" -> sites (landing.*).
  • "booking", "calendar", "work time", "time tracking" -> services (booking.*, calendar.*, timeman.*).
  • "orders", "payments", "catalog", "products" -> commerce (sale.*, catalog.*).
  • "consents", "consent", "e-signature", "sign" -> compliance (userconsent.*, sign.*).
  1. Choose auth quickly:
  • one portal/internal: incoming webhook.
  • app/multi-portal/lifecycle features: OAuth.
  1. Select minimal packs:
  • default core.
  • add only required packs: comms, automation, collab, content, boards, commerce, services, platform, sites, compliance, diagnostics.
  1. Execute with guardrails:
  • prefer scripts/bitrix24_client.py and scripts/offline_sync_worker.py,
  • enforce allowlist + --confirm-write / --confirm-destructive,
  • keep writes idempotent when possible.
  1. Escalate to deep reference only on trigger:
  • WRONG_AUTH_TYPE, insufficient_scope, QUERY_LIMIT_EXCEEDED, expired_token,
  • offline event loss concerns,
  • OAuth refresh race or tenant isolation issues.

Quality Guardrails

  • Never expose webhook/OAuth secrets.
  • Scope and permissions must be least-privilege.
  • No nested batch.
  • Online events are not guaranteed delivery; use offline flow for no-loss processing.
  • Prefer REST 3.0 where compatible; fallback to v2 where needed.

Reference Loading Map

  1. references/packs.md for pack and loading strategy.
  2. references/catalog-.md for method shortlist.
  3. references/chains-.md for implementation chains.
  4. references/bitrix24.md only when deeper protocol detail is required.

Useful search shortcuts:

rg -n "^# Catalog|^# Chains" references/catalog-*.md references/chains-*.md
rg -n "WRONG_AUTH_TYPE|insufficient_scope|QUERY_LIMIT_EXCEEDED|expired_token" references/bitrix24.md
rg -n "offline|event\\.bind|event\\.offline|application_token" references/bitrix24.md

Scripts

  • scripts/bitrix24_client.py: method calls, packs, allowlist, confirmations, audit.
  • scripts/offline_sync_worker.py: offline queue processing with retries and DLQ.

Questions people ask

How does it choose between webhooks and OAuth?
It recommends an incoming webhook for one internal portal, and OAuth for apps, multi-portal deployments, or lifecycle features.
What safeguards apply to write operations?
The client uses an allowlist plus explicit write or destructive confirmations. Guidance also calls for least-privilege permissions, secret protection, and idempotent writes where possible.
How are events handled when delivery cannot be lost?
Because online event delivery is not guaranteed, it directs no-loss use cases to an offline flow. The included worker processes the offline queue with retries and a dead-letter queue.

Related skills

Google Calendar

Check calendars, find open times, and manage Google Calendar events with confirmation before every change.

by Jay81 installs33 stars

得到大脑（Get笔记）

Save, search, organize, and manage Get Notes content and knowledge bases through explicit commands.

755 installs66 stars

Learn

Build and operate a testable learning plan with practice, spaced review, transfer checks, and durable local records.

by Iván93 installs3 stars

Learning

Learn a topic through level checks, adaptive explanations, retrieval practice, and review across sessions.

270 installs8 stars

Polymarket FastLoop Trader

Discover and trade Polymarket crypto fast markets using CEX momentum or a custom signal.

262 installs50 stars

Email To Calendar

Extract email dates, links, and deadlines for review, then create or update tracked Google Calendar events.

236 installs5 stars