We’re designing a subscription billing integration for OFC 23B that needs to handle recurring invoice generation, usage-based billing adjustments, and subscription lifecycle events. The integration will process 10K+ subscription records monthly with real-time updates from our external rating engine.
I’m evaluating REST vs SOAP APIs and finding conflicting information about capabilities. The REST API documentation shows limited subscription management endpoints compared to SOAP’s comprehensive WSDL. However, REST seems more aligned with Oracle’s strategic direction.
Specific scenarios we need to support:
Bulk subscription creation and updates
Real-time billing event processing
Complex pricing rule evaluation
Invoice generation with custom line-level details
Has anyone implemented large-scale subscription billing with either approach? What are the practical tradeoffs between REST and SOAP for this use case, especially regarding batch processing support and Oracle’s API roadmap?
REST vs SOAP for OFC Subscription Billing at Scale
Oracle’s strategic direction is unambiguously REST-first. SOAP/WSDL-based services in Fusion are in maintenance mode — functional parity gaps are unlikely to close, and new capabilities ship to REST first. That said, the current state has real limitations you need to design around.
Capability Reality Check (23B)
SOAP still leads on:
Complex AR Invoice API operations with multi-line custom attribute support
Mature Order Management web services for subscription lifecycle orchestration
Granular fault handling with structured SOAP faults vs. generic HTTP error codes
REST advantages:
FBDI + REST hybrid is the standard pattern for bulk ingestion at 10K+ volumes — don’t attempt 10K records via synchronous REST calls
Event-driven triggers via Oracle Integration Cloud (OIC) subscribe to Business Events natively over REST
Subscription Management REST APIs (/fscmRestApi/resources/11.13.18.05/subscriptions) cover lifecycle events, but pricing rule evaluation depth is thinner than SOAP equivalents (verify in your version)
Recommended Architecture for Your Scenarios
Requirement
Recommended Approach
Bulk subscription create/update
FBDI file-based load via REST upload endpoint (/fscmRestApi/resources/11.13.18.05/erpintegrations)
Real-time billing events from rating engine
REST webhooks → OIC → Subscription Management API
Complex pricing rule evaluation
Push to Pricing Administration REST API or keep rule execution in external engine, pass resolved amounts
Custom line-level invoice details
AR Invoice REST API with lines payload, or SOAP createInvoices if attribute coverage is insufficient
Practical Tradeoffs
Error handling at scale: SOAP gives structured fault codes per transaction. REST batch endpoints return partial success arrays — build idempotency keys and a retry/reconciliation layer from day one.
Session management: SOAP services use WSSE tokens; REST uses OAuth 2.0. At 10K monthly volume with real-time events, OAuth token refresh logic matters.
Roadmap risk: Investing heavily in SOAP service customization creates technical debt. The hybrid FBDI + REST pattern absorbs bulk volume without betting entirely on REST endpoint maturity.
For licensing implications of OIC consumption, API call volume tiers, and Subscription Management module entitlements — verify with vendor for current pricing.
This draft is based on general Oracle Fusion Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
We implemented subscription billing last year using SOAP APIs exclusively. The main advantage is completeness - SOAP exposes operations that aren’t available in REST yet, particularly around complex pricing calculations and subscription amendments. Performance was acceptable for our 5K monthly volume. REST is cleaner but missing critical subscription lifecycle operations in 23B.
I’d challenge the SOAP recommendation. While SOAP has more operations today, Oracle explicitly stated at CloudWorld that REST is the strategic API layer. New features are REST-first, and SOAP is maintenance mode. For 10K+ records, you should consider FBDI for bulk operations anyway, not synchronous API calls. Use REST for real-time events and FBDI for batch subscription loads.
The FBDI suggestion is interesting but our business requires near-real-time billing updates when usage events occur. We can’t wait for batch processing windows. Has anyone used REST API for subscription updates at scale? I’m concerned about rate limiting and the lack of batch endpoints in the REST API compared to SOAP’s bulk operations.
From a product perspective, REST API rate limits in 23B are 500 requests/minute per user, which should handle your 10K monthly volume easily. However, SOAP doesn’t have published rate limits and tends to be more forgiving for burst traffic. For subscription management specifically, SOAP has SubscriptionService with batch operations that process arrays of subscriptions in a single call. REST requires individual calls per subscription.
Consider a hybrid approach. We use REST for single subscription operations and real-time events because of better error handling and JSON responses. For bulk operations, we still use SOAP’s batch methods. The integration complexity is manageable with a good middleware layer. This gives you the best of both worlds while staying aligned with Oracle’s direction.
Subscription amendment workflows with approval routing
Better transaction control with explicit commit/rollback
REST advantages:
Modern authentication (OAuth 2.0 vs WS-Security)
Simpler error handling with HTTP status codes
Better documentation and testing tools (Postman collections)
Webhook support for event-driven architecture
Faster response times (JSON parsing vs XML)
Critical gap in REST for 23B: No native subscription amendment API. You have to delete and recreate.
Batch Processing Support:
SOAP is superior for bulk operations:
<processSubscriptions>
<subscription>...</subscription>
<subscription>...</subscription>
<!-- Up to 100 per call -->
</processSubscriptions>
REST requires individual calls, but you can parallelize with async patterns. For 10K records:
SOAP: ~100 API calls with batching
REST: 10K API calls (but can run 50 concurrent threads)
Actual processing time is comparable if you architect REST properly with connection pooling and parallel execution.
Oracle API Roadmap:
Based on Oracle’s public statements and 24A preview:
REST API parity for subscription management expected in 24C
SOAP APIs will remain supported but no new features after 25A
GraphQL API in early access for complex queries
Event-driven architecture (REST webhooks) is the strategic direction
My Recommendation:
For your requirements, use a hybrid approach:
REST for real-time usage events and single subscription updates (aligns with strategy)
SOAP for bulk subscription creation and complex amendments (practical necessity in 23B)
Plan migration path to full REST by 24C when feature parity arrives
Implement adapter pattern in your middleware so you can swap implementations without changing business logic
This balances immediate functionality needs with long-term strategic alignment. The hybrid complexity is worth it to avoid a complete rewrite in 18-24 months when REST catches up.