Skip to content
Last updated

Security and Scalability

The Firstup system is designed to be horizontally scalable allowing large numbers of concurrent users to use the platform with no impact on availability, consistency, or performance. The platform follows scalability best practices, ensuring that performance and availability adhere to system SLAs regardless of user load.

All customer data must be encrypted in transmission from and to customer-facing applications using industry standard AES-256-bit encryption.

Our security practices include:

  • End-to-end Data Encryption: Using the proven AES-256 standard, we encrypt every bit of data in transit and at rest.
  • Security Certifications & Compliance: SOC 1, Type I & SOC 2, Type II; CIS AWS Foundations Benchmark v1.0.0 compliant; AWS is ISO 27001, and SOC 1, 2, & 3.
  • Continuous Auditing: We regularly review and audit our security protocols to ensure data protection and monitoring 24/7/365.

A detailed overview of the Firstup security and operational policies is available in our Operational Excellence document (contact Firstup for a copy).

Resource Representation (Data Types)

Response properties of similar types use conventions in both their key and value formatting.

  • Boolean values are JSON booleans (true or false). Please avoid using strings to represent booleans.
  • Timestamp properties use the _at suffix (e.g., created_at). Their values follow the ISO 8601 format and are expressed in the UTC timezone. Example: "hireDate": "2024-04-08T00:00:00.000Z",.
  • Datestamp properties use the _on suffix (e.g., joined_on). Their values use ISO 8601 format and are expressed in the UTC timezone if the source includes time data.
  • URL properties use the _url suffix (e.g., image_url) and always include the full URL, including the host.
  • Derived Data, or properties that offer an alternative formatting of another property, indicate in their property name the added formatting. For example, a content response property called “body” may be accompanied by a second property that wraps the body in HTML. The two properties are then called body and body_html.

Requests

API endpoints are region-specific:

  • US1 region: https://auth.socialchorus.com
  • US2 region: https://auth.us2.onfirstup.com
  • EU region: https://auth.onfirstup.eu

All requests must use the HTTPS protocol. This ensures that all information transferred between client and server is encrypted and protected.

Up to 1,000 requests are allowed per minute per program.

Authentication Summary

All API requests must include an Authorization header using the OAuth 2.0 Bearer token format:

`Authorization: Bearer ACCESS_TOKEN`

Replace ACCESS_TOKEN with the valid access token for the acting user. Example:

curl -H "Authorization: Bearer ACCESS_TOKEN" \
     'https://partner.socialchorus.com/v2/content'

If authentication or permissions are incorrect:

  • 401 Unauthorized: Returned when the access token is missing, malformed, expired, or otherwise invalid.
  • 403 Forbidden: Returned when the token is valid, but the user does not have permission to access the requested resource or perform the action.

Refer to the Client Error codes section for more details on error handling.

Authorization Overview and Methods

Verbs and Routes

The Firstup Partner API follows RESTful design principles, which means it uses specific HTTP methods (also called “verbs”) along with structured URL paths (called “routes”) to perform actions. This makes the API easier to understand and work with.

Here’s a breakdown of the most common HTTP methods and how they’re used:

  • GET – Used to retrieve data, either a list of items or a single item.
  • POST – Used to create a new item.
  • PUT – Used to update an existing item, or to perform an action like "publish" or "archive."
  • PATCH – Used to make partial updates to an existing item, such as modifying a user's role or status. Refer to our SCIM Patching guide for more information.
  • DELETE – Used to remove an item.
  • PUT is idempotent, meaning that sending the same PUT request multiple times won’t change the result after the first one—it just keeps the item in the same state.
  • POST, on the other hand, is not idempotent—sending it twice could create two separate records.