Oracle Siebel · Rate Limits

Oracle Siebel Rate Limits

Oracle publishes exactly ONE hard numeric limit for the Siebel REST API: a query returns at most 100 records per call (PageSize, default 10). There is no published requests-per-second or requests-per-minute table, and there are no rate-limit response headers of any kind. Siebel is customer-deployed, so throughput is bound by the customer's own Application Object Manager (AOM), Application Server, Web Server and Database tier capacity. Where throttling is enforced at all it is enforced by the surrounding web/application server (WebLogic, IIS, Apache) or by a customer-fronted API gateway — neither of which Oracle documents on Siebel's behalf.

Oracle Siebel Rate Limits is the machine-readable rate-limit profile for Oracle Siebel on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring records and varies.

The profile also includes 4 backoff/retry policies defined and response codes documented for unauthorized, forbidden, notFound, serverError, and serviceUnavailable.

Tagged areas include CRM, Enterprise Software, Oracle Cloud, and Rate Limiting.

4 Limits
CRMEnterprise SoftwareOracle CloudRate Limiting

Limits

Records per query per-request
records
100
"The PageSize parameter is the integer that tells the Siebel Server how many records to return. The default value is 10... The maximum number of records cannot exceed 100." Page through larger sets by incrementing StartRowNum. This is the only numeric limit Oracle publishes for the REST API, and it is a payload cap rather than a rate cap.
REST API Throughput deployment
varies
bound by Siebel AOM / Application Server capacity
Throughput is governed by the deployed Siebel Application Object Manager and Application Server sizing rather than a public per-tenancy rate.
SOAP Web Services Throughput deployment
varies
bound by Siebel AOM / Application Server capacity
As with REST, SOAP web service throughput is bound by the deployed Siebel server tier.
EAI Inbound / Outbound Throughput deployment
varies
bound by deployed EAI configuration
EAI throughput depends on the configured business-service component pools and underlying transport (HTTP, JMS, MQ).

Policies

Capacity-Bound Throttling
Throughput limits are determined by the deployed Siebel Application Object Manager, Application Server, Web Server and Database tier sizing rather than a published per-tenancy rate-limit table.
Backoff Strategy
Clients should implement exponential backoff with jitter on 5xx responses. Honor any Retry-After header if a fronting gateway emits one; Siebel itself does not.
AOM Tuning
Siebel administrators tune AOM component thread pools, MaxTasks and MaxMTServers to match observed load rather than relying on a centrally-imposed rate.
API Gateway Pattern
Customers exposing Siebel APIs to third parties should front them with an API gateway (Oracle API Platform, Apigee, etc.) and apply rate limits there. This is also where JWT signature validation must happen, since Siebel supports introspection only.

Sources