B24Phpsdk Laravel Package

Product Decisions This Supports

• Integration with Bitrix24: Accelerate development of custom applications or extensions that interact with Bitrix24's REST API. The 3.7.0 release materially widens the "out of the box" surface area — batch support now covers Landing (sites, pages, blocks, templates, roles, repos, demos) and Sale/e-commerce (baskets, payments, shipments, deliveries, cashboxes, properties, statuses, trade platforms), plus new Disk search/sharing, SonetGroup membership & roles, timeman, Voximplant callback, and legacy Pull channel/push services. That shifts several integrations from "we'll write a wrapper" to "we'll wire up typed services" — a direct time-to-market win.
• Build vs. Buy: Buy (adopt) for teams needing a maintained, feature-rich PHP SDK for Bitrix24. The 3.7.0 scope additions — especially the Sale and Landing batch layers — are exactly the kind of boilerplate no team should rebuild. Reinforces the recommendation to avoid custom REST wrappers for auth, tokens, pagination, and batch semantics.
• Roadmap Prioritization:
  • Phase 1 (stable, low risk): Ship CRM/user-profile syncs and e-commerce read/write flows on the now-typed methods, using the new Landing and Sale batch services for bulk operations. Low-risk because these are additive, non-breaking.
  • Phase 2 (new capability): Adopt REST v3 user history / field-change / metadata services with cursor-based incremental reads for delta-sync features (audit trails, "what changed since last sync", lightweight CDC pipelines). This is the single biggest product unlock in the release — incremental sync instead of full re-pulls.
  • Phase 3 (security hardening): Wire up PortalDomainUrlChangingEvent with its irreversible deny() and PortalDomainChangeRejectedException to veto portal redirects before credentials change or tokens are sent to the destination. This is a compliance/security feature, not a nice-to-have, for multi-tenant and marketplace apps.
  • Tech-debt watch: Legacy IMBot methods are now documented as deprecated with replacements. Any roadmap item depending on legacy bots should be re-scoped onto the replacement methods now rather than later.
  • Future: Continue to monitor the SDK's opportunity score (55.85) for contributions (e.g., offline queues, additional scopes like telephony/workflows). Note there are still unresolved undocumented endpoints explicitly excluded by the maintainers (e.g., log.comment.delete, Disk allowed-operation endpoints) — treat these as unsupported and don't build product features on them.
• Use Cases:
  • Marketplace Apps: Build Bitrix24 Marketplace applications using the provided contracts (Bitrix24Accounts, ApplicationInstallations) to manage auth tokens and installations — now with domain-change veto protection as a first-class safety net.
  • E-commerce / Storefront Ops: The expanded Sale batch coverage makes catalog-adjacent sync (orders, payments, shipments, delivery config) viable without per-call round-trips.
  • Sites & Landing Management: Bulk create/update/delete of landing sites, pages, blocks and templates — useful for agencies and template/vertical solution vendors.
  • Local Apps: Integrate via webhooks or local app placements (custom portals, third-party tools).
  • Data Migration: Batch process large datasets with low memory usage via PHP generators, now extended to Landing and Sale entities.
  • Event-Driven / Near-Real-Time Workflows: The new legacy Pull channel/configuration services with typed public channel results and a getPullScope() facade enable Bitrix24's long-polling push model — a practical middle ground for near-real-time UX, though still not WebSocket.
  • Audit & Change Tracking: Cursor-based v3 user history and field-change services enable incremental audit feeds and change-driven automations.

When to Consider This Package

• Adopt if:

  • Your project requires PHP 8.2+ and interacts with Bitrix24's REST API.
  • You need typed methods, auto-completion, and performance optimizations (batch queries, generator-based processing).
  • Your roadmap includes e-commerce/Sale, Landing/site management, Disk, group/collaboration, or telephony (Voximplant) — these are now covered with typed + batch services as of 3.7.0.
  • You need incremental/delta sync rather than full re-pulls (v3 user history, field-change, metadata with cursors).
  • You need near-real-time push via Bitrix24 Pull channels (long-polling; not WebSocket).
  • Your team lacks deep knowledge of Bitrix24's API endpoints or authentication flows.
  • You're building a marketplace app, local integration, or data-heavy sync.
  • You want MIT-licensed, actively maintained code with integration tests against real Bitrix24 portals.

• Look elsewhere if:

  • You need JavaScript/TypeScript support (use Bitrix24's official JS SDK).
  • Your project uses PHP < 8.2 (no support).
  • You require offline queueing (still not implemented; track GitHub issues).
  • You require true WebSocket streaming (Pull is long-polling, not WS).
  • Your feature depends on endpoints the maintainers explicitly exclude as undocumented (e.g., log.comment.delete, certain Disk allowed-operation endpoints) — these are unsupported and may never land.
  • You're integrating with non-REST Bitrix24 APIs (e.g., SOAP).
  • You prefer low-code/no-code solutions (e.g., Bitrix24's native UI tools).

How to Pitch It (Stakeholders)

For Executives:

"This SDK lets us rapidly build Bitrix24 integrations without custom API wrappers, cutting development time by 40%+ for CRM, task, or IM syncs. Release 3.7.0 significantly expands what we get for free: e-commerce (Sale) and Landing/site management now have batch support, we get incremental delta-sync for user history and field changes (cheaper, faster syncs), and a security control that vetoes portal domain changes before credentials leave — a real compliance requirement for multi-tenant apps. It's production-ready, MIT-licensed, actively maintained, and aligns with our PHP 8.2+ stack. For example, we could launch a Bitrix24 Marketplace app in 3 months instead of 6 by leveraging its pre-built auth contracts and typed methods — and now extend it into storefront or site-management features without new R&D."

For Engineering:

*"The Bitrix24 PHP SDK (3.7.0) gives us:

• Zero-boilerplate API calls: Typed methods with IDE autocompletion (e.g., $b24Service->crm()->leads()->add()).
• Batch coverage across more scopes: New batch properties on Landing services (sites, pages, blocks, templates, roles, repos, demos) and Sale services (basket, payment, shipment, delivery, cashbox, property, status, trade platform). Landing batch supports offset pagination via params.limit/params.offset.
• Incremental reads: REST v3 user history, field-change, and metadata services with cursor-based reads — build delta syncs instead of full scans.
• Security hook: PortalDomainUrlChangingEvent with irreversible deny() + PortalDomainChangeRejectedException lets us reject portal redirects before credentials/tokens are sent onward.
• Legacy Push: Pull channel/configuration services with typed public channel results and a getPullScope() facade, plus Pull application config, event, push and watch wrappers — near-real-time UX without WebSockets.
• Broader legacy parity: voximplant.callback.start, all nine remaining timeman methods (networkRange(), timeControl()), SonetGroup membership/roles, Disk file/folder search and folder sharing, and seven legacy log endpoints for feed posts/comments.
• Two tracks:
  • v1: Stable for PHP 8.2–8.4 (use for production).
  • v3 (3.7.0): Cutting-edge; verify PHP version requirement for your environment before adopting new methods.
• Tested: Unit + integration tests against real Bitrix24 portals.

Tradeoffs and watch items:

• Legacy IMBot methods are now documented as deprecated with replacements — audit any bot code now and plan migration; some public contracts remain unresolved.
• Undocumented endpoints are deliberately excluded (e.g., log.comment.delete, some Disk allowed-operation endpoints) — don't design features around them.
• Still no offline queueing — we'd own retry/backoff ourselves or contribute upstream.
• Pull is long-polling, not WebSocket — don't promise true streaming.

Next steps:

1. Pilot 3.7.0 on the CRM sync project (low risk); validate the batch paths for Sale/Landing if e-commerce is on the roadmap.
2. Prototype a delta-sync job using v3 user-history/field-change cursors and benchmark against our current full-pull approach.
3. Implement PortalDomainUrlChangingEvent::deny() in the marketplace app as a security gate.
4. Audit IMBot usage against the published deprecations.
5. Assess Pull channel services if we need near-real-time updates instead of polling."*