Developers

Regions and Endpoints

It is possible to set or restrict your integration based on geographical location. There are three methods to do this depending on your setup: One is the default, the other two are optional.

Regions

1. CDN deployment endpoint (default)

This is suitable for roughly 80% of integration types and use cases. If your server-side or programmatic integrations experience unexpected latency, try option 2 below. For SDK integrations with unexpected latency, try option 3. 

 
Note

Latency-based routing cannot guarantee that users in a given geographical area will be served from the same location for any compliance reason.

CDN entry point: https://api.inbenta.io/

This entry point uses CloudFront edge locations, and the request is routed via the geographically closest CDN edge location to the caller, up to the centralized API entry point.

Reference: https://aws.amazon.com/es/cloudfront/features/

2. Regional deployment endpoint (optional)

This is recommended for server-side and programmatic integration to API calls if your data center fits a near and low latency regional endpoint.

 
Note

This is not recommended for SDK integrations, unless all known callers are in a controlled environment near a regional endpoint.

Entry points:

Map: https://mapfling.com/qb68w8i

3. Latency-based by DNS resolver endpoint (optional)

This solution works best for SDK-only integrations, where all requests come from various client/browsers spread over the world. Use this if the main deployment (CDN, option 1 above) does not fit your requirements.

Entry point: https://api-smart-routing.inbenta.io/

The routing is based on the regional entry point that gives the user the fastest response with the lowest network latency.

 
Notes

• This is not a routing based on geolocation. It is based on lower latency (ms) evaluated at the DNS query to api-smart-routing.inbenta.io record.

• Latency between hosts on the Internet can change over time as a result of changes in network connectivity and routing. Latency-based routing is based on latency measurements performed over a period of time, and the measurements reflect these changes (e.g. if the latency from the user in (A) to (B) improves, the user can be routed to B).

• Latency-based routing cannot guarantee that users in a given geographical area will be served from the same location for any compliance reason.

Endpoints and SSL/TLS Terminations

API and SDK Terminations only work in browsers with SNI support. (ref: https://en.wikipedia.org/wiki/Server_Name_Indication)

SNI as extension of TLS Protocol RFC 6066 (https://tools.ietf.org/html/rfc6066)
(port 80 and http protocol not enabled)

Terminations

Port: 443
Protocol: HTTP 1.x / 2

DNS and Endpoints layout:

https://api-xyz{AB}.inbenta.io/{stage}/{endpoint}

*Where {AB} depends of your configuration as well as the {stage}.
** Note that these endpoints are dynamic and may change. You must obtain them as described in section "Authorization" / API Routes / default / GET /apis

SSL Terminations

PROTOCOLS AND CIPHER SUITES

Protocols: TLS1.2, TLS1.3 (some https terminations only)

Cipher Suites

# TLS 1.3

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

# TLS 1.2

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA256

CERTIFICATES

SERVER KEY AND CERTIFICATE

#1
CN: inbenta.com and inbenta.io
Subject: .inbenta.io, .inbenta.com
SAN: .inbenta.io, .inbenta.com
Certificate Type: DV
RSA 2048 bits (SHA256withRSA)
Key RSA 2048 bits
Signature algorithm SHA256withRSA
Certificate Transparency: Yes (http://www.certificate-transparency.org/)
Issuer Amazon (AIA: http://crt.sca1b.amazontrust.com/sca1b.crt)
Trust Store: Mozilla Apple Android Java Windows
SNI: YES