API reference

The SC//Reliant™ platform provides a RESTful API which provides a way for customers to manage their SC//Reliant Platform Manager features, including the following.

Integrations with Estate Management
Integrations with nodes and node groups
Integrations with virtual nodes (Linux Containers and KVM virtual machines)

This API reference provides endpoints, expected request and response parameters with JSON payloads, and examples. We provide a Ruby script that can be used as a working example for interacting with our API. For more information, see API examples using Ruby.

API security model

The SC//Reliant platform API and its integration endpoints are protected by layered controls: federated identity for human access to the management console, per-request HMAC signing for machine-to-machine API calls, rate limiting and a managed Web Application Firewall (WAF) for public endpoints, and OWASP-aligned validation on every inbound payload.

Authentication

Human access to the SC//Reliant Platform Manager console is delivered through Security Assertion Markup Language (SAML) 2.0 federation to customer-managed identity providers, including Okta, JumpCloud, Google, OneLogin, and Microsoft Entra. Cisco Duo is available as a turnkey Multi-Factor Authentication (MFA) provider where federation is not used.

API and service integrations to the SC//Reliant Platform Manager use HTTPS over TLS 1.2+ with Hash-based Message Authentication Code (HMAC)-signed per-request authentication tied to a customer-provisioned authentication token and secret key. Signed timestamps are used to prevent replay, and the HMAC token expiration is 15 minutes. For the request header contract and worked Ruby example, see API Access Requirements.

OAuth 2.0 / OpenID Connect (OIDC) for machine-to-machine API access is not currently the standard authentication path for the SC//Reliant platform API. OAuth 2.0 / OIDC support is on the platform roadmap. Where customer integrations require OAuth 2.0 / OIDC at the identity provider layer (for example, for upstream identity flows), this is supported through the customer's IdP.

Rate limiting and bot defense

Public web endpoints sit behind AWS WAF deployed on CloudFront, ALB, or API Gateway. The deployment applies the AWS Managed Rules Common Rule Set, the AWS Managed Rules Known Bad Inputs, and the AWS Managed Rules SQL Database. Rate-limiting rules cap aggressive client behavior, and bot and data-scraping prevention is provided by the managed rule sets in alignment with PCI DSS 4.0.1 §6.4.2.

The SC//Reliant platform API publishes per-request rate limits in the x-rate-limit response header, allowing integrating clients to implement back-off behavior. When a client exceeds its limit, the API returns HTTP 429 with a Retry-After header. For the request/response contract and examples, see Rate limiting.

Audit trail and anomaly detection

Blocked-request events at the WAF are forwarded to the centralized Security Information and Event Management (SIEM) platform and alerted via Sensu. Anomaly detection on API activity is performed through SIEM-based correlation of authentication events, access patterns, and rate-limit events, giving the security team a single view of activity across human and machine principals.

Payload validation

Inbound data is validated and sanitized at multiple layers. Application code follows the Secure Development Policy and Software Development Lifecycle (SDLC) standards aligned to the OWASP Top 10: input validation, parameterized queries, output encoding, and secure HTTP headers. The SC//Reliant Platform Manager sits behind AWS WAF with Managed Rules that detect and block SQL injection, cross-site scripting (XSS), malformed payloads, and command-injection patterns, in alignment with PCI DSS §6.4.2.

Quarterly web-application vulnerability testing and biannual external penetration testing exercise these controls with explicit injection, traversal, and XSS cases. Findings are tracked to remediation in Jira.

Edge integration surface

At the edge, the SC//Reliant platform Edge Device runs a hardened, minimal Debian baseline with default-deny IPTables and no listening application accepting arbitrary user input. Payment traffic is routed between PIN pads and the customer's payment processor without the platform interpreting payment payloads, keeping the cardholder data path narrow and out of the platform's interpretation surface.