Building custom REST APIs vs using prebuilt connectors for IoT integration

Our team is integrating Oracle IoT Cloud Platform with several enterprise systems (ERP, MES, warehouse management). We’re deciding between building custom REST APIs for each integration versus using Oracle’s prebuilt connectors where available. Custom APIs give us full control but require more development time. Prebuilt connectors are faster to deploy but may have limitations.

What’s the community’s experience with this trade-off? When does it make sense to invest in custom API development versus leveraging existing connectors? Looking for insights on maintenance burden, flexibility, and long-term scalability of each approach.

You can definitely hybrid it. Use prebuilt connectors for the standard data flows and build custom APIs for the edge cases. We use connectors for bulk data sync and custom APIs for real-time event processing that requires business logic. The key is having a clear integration architecture that defines which tool handles which use case.

Having implemented both approaches across 15+ enterprise IoT integrations, here’s my framework for making this decision:

Prebuilt Connector Evaluation:

Use prebuilt connectors when:

  • Integrating with standard enterprise systems (SAP, Oracle EBS, Salesforce, ServiceNow)
  • Data flow requirements match connector capabilities (>90% coverage)
  • You need rapid deployment (weeks vs months)
  • Team has limited API development expertise
  • Maintenance resources are constrained

Connector strengths: Built-in error handling, automatic retries, versioning support, Oracle-managed updates, pre-tested compatibility, standard monitoring, documented best practices

Connector limitations: Fixed data transformation logic, limited custom business rules, constrained field mapping, may not support all API endpoints, update cycles controlled by Oracle

Evaluation criteria: Document your integration requirements in detail, then test prebuilt connector against a representative sample (not just happy path). If connector handles >85% of scenarios and workarounds exist for gaps, use the connector.

Custom API Development:

Build custom APIs when:

  • Integrating with proprietary or niche systems without connectors
  • Complex business logic required in integration layer
  • Need real-time bidirectional sync with sub-second latency
  • Require custom data transformations or enrichment
  • Building competitive differentiation on integration capabilities

Custom API strengths: Complete control over logic, optimized for specific use case, can implement advanced patterns (event sourcing, CQRS), direct access to all system APIs, custom error handling

Custom API challenges: 3-6 month development timeline, requires API expertise, ongoing maintenance burden, must implement security/auth/logging/monitoring, version management complexity, testing overhead

Integration Patterns:

Hybrid approach (recommended for complex environments):

  • Use prebuilt connectors for bulk data synchronization (nightly/hourly batch jobs)
  • Build custom APIs for real-time event processing and complex workflows
  • Implement integration hub pattern with message queue between connector and custom logic
  • Use API gateway to provide unified interface regardless of backend implementation

Maintenance Strategy:

Prebuilt connectors: Plan for quarterly Oracle updates, test in non-prod first, monitor deprecation notices, maintain configuration documentation

Custom APIs: Implement comprehensive logging, set up API health monitoring, version APIs properly (v1, v2), maintain automated test suites, document integration patterns, plan for 20% time on maintenance

Our standard recommendation: Start with prebuilt connectors for 70% of integrations (standard enterprise systems), build custom APIs for 30% (specialized requirements). This balances development velocity with flexibility. Expect 60% faster time-to-production using connectors vs custom development, but accept 15-20% functional constraints. Use the time saved to build really solid custom APIs where they’re truly needed.

Interesting perspectives. How do you handle scenarios where prebuilt connectors cover 80% of requirements but need custom logic for the remaining 20%? Can you extend connectors with custom code or do you have to choose one approach entirely?