Integration

Salesforce, where your API budget belongs to the whole org

A Salesforce integration lets a Telegram bot create and update Leads, Contacts and Opportunities in an existing org. The constraint that shapes everything is the daily API allocation, which is shared across every integration on the org — a chatty bot can exhaust it and break unrelated systems.

Salesforce integration: auth, limits and availability

Auth model: OAuth 2.0
API allocation: Daily, per organisation — not per integration
GCC availability: No regional restriction; edition determines API access
Data flow: 5 hops, worker-mediated

As of 2025-10-01, Telegram Bot API 13.4

Why this integration exists

Salesforce is where these integrations get expensive, and not because the API is difficult. It is because a Salesforce org is almost never a clean slate. There are validation rules nobody remembers writing, required custom fields, Apex triggers that fire on insert, and an existing set of integrations quietly consuming the same daily allocation your bot is about to draw on.

The allocation is the sharpest constraint. It is granted per organisation per rolling day, not per integration, so your bot competes with the nightly ERP sync and the marketing automation. A polling design that seemed reasonable in isolation can consume a meaningful share of it, and the failure is not that your bot stops — it is that something else does, and the person diagnosing it has no reason to suspect a Telegram bot.

The second constraint is that writes trigger Apex. A Lead insert can fire triggers, flows and validation rules whose combined behaviour nobody has fully mapped, and a bot writing at volume will find combinations that a human entering records one at a time never reaches. Discovery of the existing automation is a real work item, and pricing this integration as though it were a REST client is how the estimate gets doubled mid-project.

How the data actually moves

Writes are queued and paced against the org-wide allocation rather than issued as they arrive, and inbound changes arrive as platform events rather than by polling.

A connected app using the OAuth JWT bearer flow, which suits server-to-server integration because it needs no interactive login and no stored user password. The signing key is a Worker secret. The integration authenticates as a dedicated integration user with a permission set scoped to exactly the objects in the mapping — using a named salesperson's access works until they leave and corrupts the audit trail meanwhile.

Auth model: OAuth 2.0

Their limits, and what they mean for you

The daily API request allocation is granted per organisation, not per integration.

Your bot shares it with every other system. Sync frequency is a budgeting decision, and exhausting it breaks integrations that have nothing to do with you.

Apex governor limits constrain what can happen inside a single transaction triggered by your write.

A bulk write can trip a limit inside someone else's trigger. Writes are batched conservatively, because the error surfaces as your integration failing for reasons in code you did not write.

Validation rules and required custom fields are enforced on API writes exactly as in the UI.

A field a salesperson fills from context must be supplied or defaulted by the bot. Discovering the full set is part of scoping and is frequently the largest surprise in the project.

Platform events and Change Data Capture are the supported push mechanisms, with their own delivery allocations.

Push is strongly preferable to polling on allocation grounds, but it is not unlimited either. The event budget is planned alongside the request budget.

How it fails, and what happens when it does

The org exhausts its daily API allocation.

Every integration on the org starts failing, including yours. The bot monitors remaining allocation from response headers and backs off before contributing to the exhaustion.

A write fails a validation rule the bot did not know about.

The lead is already durable locally, so nothing is lost. The failure is routed to a human with the rule name attached rather than retried, since retrying a validation failure never succeeds.

An Apex trigger throws under a batched write.

The batch is rejected as a unit. Batch sizes are conservative and the failure identifies which records were involved, because the default behaviour hides that.

A duplicate Lead is created for an existing Contact.

Salesforce's duplicate rules are respected rather than bypassed, and an ambiguous match escalates for review. Bypassing duplicate rules to make an integration work is a decision with a long tail.

Availability in the UAE and the wider GCC

Global

No regional restriction. What varies is your edition, which determines API access and allocation.

Essentials and lower editions

API access is limited or absent depending on edition. Confirm before scoping, because it is a hard gate rather than a limit to design around.

Orgs with heavy customisation

The common case in established GCC businesses, and the main cost driver here. Discovery of existing triggers and validation rules is a real work item.

Sandboxes

A full or partial sandbox that reflects production customisation is close to essential. A developer sandbox without the triggers will pass tests that production fails.

When not to use this integration

Your edition does not include API access. A hard gate, and worth checking in the first conversation rather than the third.
Nobody can tell you what the existing triggers and validation rules do. That discovery is the project, and pretending otherwise doubles the estimate mid-flight.
Your org is already close to its daily allocation. Adding a bot to a saturated org breaks other people's systems and you will be blamed correctly.
You need a lightweight lead capture. HubSpot or Pipedrive will do it in a fraction of the time and cost.

What it runs on

Component	Version	Why
Cloudflare Workers	current	JWT bearer auth, paced writes and platform event handling.
Cloudflare D1	current	Write queue, allocation tracking and the human-review queue.
Cloudflare KV	current	Access token cache and remaining-allocation counter.
Zod	4.4	Validation of API responses and event payloads.

Questions that come up during scoping

Why is this the most expensive CRM integration to build?

Because the org is never a clean slate. Existing triggers, flows and validation rules have to be discovered and worked with, and the daily API allocation has to be budgeted against everything else already using it. The REST client is the easy part.

What happens if we exhaust the daily API allocation?

Every integration on the org starts failing, not just yours, and the person diagnosing it has no reason to suspect a Telegram bot. The bot reads remaining allocation from response headers and backs off before it contributes to that.

Should we poll or use platform events?

Events, almost always, because polling consumes the shared allocation continuously. Events have their own delivery budget, so both are planned rather than one being treated as free.

Can the bot bypass duplicate rules to make writes succeed?

It can, and it should not. Bypassing duplicate rules makes the integration look reliable while quietly degrading the data everyone else depends on, and the consequences arrive months later as a data quality project.

Do we need a sandbox that mirrors production?

Close to essential. A developer sandbox without your triggers and validation rules will pass every test and then fail in production, which is the most expensive possible ordering.

Which user should the integration authenticate as?

A dedicated integration user with a scoped permission set. Using a salesperson's access works until they leave, at which point every automated write stops — and until then the audit trail attributes bot activity to a person.