Skip to content
SteveTechArcSteveTechArc Courses

Who's at the Door

Module 7 of 7 in the chapter Salesforce as an API Provider, chapter 8 of the Integration Architect course. Each module stands on its own. Previous: When Someone Calls You Back

The question this module answers: Every call into Salesforce runs as someone and costs something. How do you see who’s calling, how much is left, and try every door yourself?

This chapter has been about doors. This last module is about who’s standing at them, and the one allowance they all share. Then you’ll open the doors yourself.

Every Call Runs as Someone

Section titled “Every Call Runs as Someone”

Chapter 4 set up the gatekeeper: an External Client App for the program, an integration user it runs as, a permission set with API access and only the objects and fields its job needs. Every door in this chapter respects that user. A REST query, a composite graph, a GraphQL request, your own Apex REST door: each one sees only what the integration user may see.

So the user is how you know who’s at the door. Steve Trucking gives every partner and every system its own integration user; the crews’ app signs in as each crew member. When something odd shows up in the API Total Usage log from module 1, the user name tells you whose system it was, and a mistake or a compromise stays with that one partner.

Some Doors Change the Org Itself

Section titled “Some Doors Change the Org Itself”

Every door in this chapter so far works on records. A few doors work on the org itself. The Tooling API is the one to know. Salesforce describes it as the API for working with metadata and building development tools, and says you can “execute anonymous Apex, and access logging and code coverage information” through it (Which API Do I Use? (opens in a new tab), Salesforce Help, checked 2026-10-31). The Metadata API, its bigger sibling, moves whole sets of configuration from one org to another.

In my two videos on the Tooling API, I did from Postman what a developer does in the org: ran a test class, read the debug logs, ran a line of anonymous Apex, listed the custom objects and fields, then created a new field and a new Apex class. All from outside, all through a door. That’s how your development and deployment tools work, and it’s worth knowing they’re just API calls.

It’s also a warning. A door that can run code or create a class could do the job of a custom web service, with a lot more power than one. So an integration user never gets the permissions those doors need. Redrock’s user reads and writes deliveries; it doesn’t author Apex or change metadata. Those doors belong to developers and deployment pipelines, each with its own sign-in. Chapter 13 covers keeping them that way.

One Allowance for the Whole Org

Section titled “One Allowance for the Whole Org”

Here’s what surprises people. The daily API allowance doesn’t belong to the user. It belongs to the org. In Salesforce’s words: “Limits and allocations are not on a per-user basis” (API Request Limits and Allocations (opens in a new tab), Developer Limits and Allocations Quick Reference, Winter ‘27, checked 2026-10-31).

For an Enterprise Edition org, the total for 24 hours is “100,000 + (number of licenses x calls per license type) + purchased API Call Add-Ons”, with 1,000 calls for each Salesforce license; Unlimited and Performance Edition give 5,000 per license (same page). Every caller draws from that one number: Redrock, the crews’ app, the weekly export, a partner’s app on the UI API, and your own Apex REST doors.

So one partner’s runaway loop can use up the day for everyone. That’s why the earlier modules kept counting calls: one upsert by key instead of a lookup and an update (module 2), one composite graph instead of ten calls (module 3), and knowing that each GraphQL subquery counts (module 4). It’s also why chapter 6’s number of zeros is a constraint, not a curiosity.

If you go over, Salesforce doesn’t stop you at once. It “still lets the operations proceed by a certain amount, if possible”, but “a hard cap is in place” (same page). Plan for the allowance, not for the grace.

Ask the org, not a table. The guide’s table says a Developer Edition org gets 15,000 calls a day. When we asked a Developer Edition org on 2026-10-31, it said 50,000. Numbers move, editions differ, add-ons get bought. The org’s own answer is the one that counts, and you’ll ask for it in the lab below.

One allowance, many callers One allowance, many callers. On the left, four callers, each signing in as its own user: Redrock's system, as Redrock's integration user; the crews' mobile app, as each crew member; the weekly Snowflake export, as the export's integration user; and a Retail Partner's app, as that partner's user. All four arrows lead to one card in the middle, in navy: the org's daily API allowance, one number for the whole org, not per user, which you ask for with /limits. From there the calls go into Steve Trucking's org, where every call sees only what its user may see. Underneath: separate users tell you who is calling; one shared allowance means one runaway caller affects everyone. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-INT-SP-06", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} WHO'S CALLING, AS WHOM SHARED BY ALL INSIDE STEVE TRUCKING'S ORG Redrock's system as Redrock's integration user The crews' mobile app as each crew member The weekly Snowflake export as the export's integration user A Retail Partner's app as that partner's user The org's daily API allowance one number for the whole org, not per user; ask /limits shared Steve Trucking's org every call sees only what its user may see draws draws draws draws calls go in Separate users tell you who is calling. One shared allowance means one runaway caller affects everyone. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Separate users, one allowance.

The Limit That Catches People: Long Calls

Section titled “The Limit That Catches People: Long Calls”

The daily allowance counts calls. A second limit counts slow calls. Salesforce allows only so many inbound requests lasting 20 seconds or longer at the same time: 25 in production and sandboxes, 5 in Developer Edition and trial orgs. Go over, and new calls get REQUEST_LIMIT_EXCEEDED until some finish. There’s no limit on concurrent calls shorter than 20 seconds (same page).

That’s the one that bites in production. A slow query, a heavy trigger, a composite graph doing a lot of work, and under load the long calls pile up until fast, harmless calls start failing too. The cure is the same as everything in this chapter: ask for less, do less per call, and move big work to the bulk door (chapter 10). Separately, a REST or SOAP call times out after 10 minutes, except queries, which have their own limits; for composite, the 10 minutes apply to the whole request, not to each part. Apex inside Salesforce has long-running limits of its own, and chapter 9 names them apart.

Watching the Meter

Section titled “Watching the Meter”

Salesforce gives you four places to watch the allowance (same page):

  • The Sforce-Limit-Info header on every REST response, which shows how much of the day’s allowance is used. A well-built caller reads it and slows down before trouble.
  • /limits, a REST call that returns every limit with its maximum and what’s left.
  • System Overview in Setup, for a person to look at.
  • API Usage Notifications in Setup, which email someone when usage passes a percentage you set. Set one. It’s free, and it’s the difference between hearing at 80% and hearing when Redrock calls to say nothing works.

Your Lab Bench

Section titled “Your Lab Bench”

In chapter 2 you started a Steve Trucking collection in your API tool. Now you call Salesforce with it. You should all have an API tool. Postman is the one I use, and it’s the one Salesforce now points to: “Postman replaces the legacy Workbench tool as the recommended solution to explore and test Salesforce APIs” (Connect Postman to Salesforce (opens in a new tab), checked 2026-10-31). Salesforce publishes a ready-made collection of its APIs; the install steps are on GitHub (opens in a new tab).

Use a free Developer Edition org, never production. Then:

  1. Get a token. Use the External Client App and integration user from chapter 4, with the client credentials flow: your My Domain’s /services/oauth2/token, the client ID and secret, grant_type=client_credentials.
  2. Ask which doors there are. GET /services/data/, then GET /services/data/v68.0/ (module 1).
  3. Query. A SOQL query through /query, and look at the Sforce-Limit-Info header on the answer (module 2).
  4. Ask how much is left. GET /services/data/v68.0/limits, and find DailyApiRequests (this module).
  5. Ask for one record two ways. Through GraphQL with three fields, and through the UI API’s record-ui (module 4). Compare the sizes.
  6. Write one, by key. An upsert by an external ID, then the same upsert again, and check you still have one record (module 2).
  7. See who was at the door. Query the record’s LastModifiedBy.Username. It’s the integration user, not you.

Two habits, and they matter more now that there’s a real token:

  • A token on the screen is a key. When I recorded my videos with a live token, I’d go back afterwards and revoke it, because for hours anyone who could read the screen could use it. Revoke a token you’ve shown, and never paste one into a chat or an AI tool.
  • Keep the secret out of the collection you share. Postman environments and variables hold it on your machine; chapter 13 covers keeping secrets properly.

Watch it on video

Section titled “Watch it on video”

In early 2024 I made two videos on the Tooling API: what a program can do from outside the org, and creating metadata through it. The notes under the videos say what’s still right and what’s changed since.

STA 1.18 · Across APIs: Salesforce Tooling API Introduction to Automated Developer Control · 9:12 · published 2024-01-09 · plays from YouTube when you click it · Watch on YouTube · More videos: Salesforce Integration Architecture Videos
STA 1.19 · Across APIs: Salesforce Tooling API Viewing and Creating Metadata · 9:19 · published 2024-01-08 · plays from YouTube when you click it · Watch on YouTube · More videos: Salesforce Integration Architecture Videos

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • One integration user per caller. So the logs tell you who, and a problem stays with one partner.
  • The allowance, budgeted. The org’s daily total, from /limits, against every caller’s expected calls, with room to spare.
  • Integration users that can’t change the org. No permission to author Apex or change metadata; those doors are for developers and pipelines.
  • Calls kept short. Under 20 seconds under load, so the long-call limit never fills up; big work goes to bulk.
  • Somebody watching. API Usage Notifications set, and callers that read Sforce-Limit-Info.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.